The four areas I consider when building a software engineering carreer ladder

When I worked as an Engineering Manager at Doris – now i am working as technical leader – I noticed that every time I had a one-on-one with someone, the feedback notes seemed to solve the problem in the moment — but by the end of each meeting, it felt like something was missing or off.

From that point on, I started shifting the balance of what I did day to day to make more space for actually acting as a manager and coding less. In many companies, depending on their size, leadership roles like CTOs, CIOs, and EMs often spend a lot of time performing engineering tasks — which means they’re constantly relying on the present instead of paving a path toward the future. So I began researching more about the position I held, what the responsibilities were, and so on.

After diving into blogs, newsletters, books, and YouTube channels — you can check out some on my suggestions page — I realized that the first step to organizing a team was to define a career path. And that the best starting point wasn’t hard skills alone (as most job listings focus on), but rather a broader set of characteristics.

Through this research, I arrived at four key areas:

Responsibility e capability
Hard skills
Soft skills
Culture

Within these areas, I can map all the requirements someone needs to move up levels, shift roles, or understand how they fit during hiring. To make this clearer, I’ll dive deeper into each one with guiding questions — already paving the way for my next post, which will present a proposed career path for software engineers.

Responsibility and capability

What should this person expect in their day-to-day, and how should they engage with their teammates?

What kind of work will they do? Will they work on small features and fixes, or be a reference and technical supervisor on a large project or product?
Do they work solo? Are they supervised by someone with more experience/context? Do they act as a second or third arm to some leadership figure? Do they lead or supervise projects, products, features, or teams?
Are they expected to organize things that usually fall outside the team’s scope — like a tech lead keeping track of whether delivery estimates match the current progress?
Are they expected to dive into highly ambiguous scopes or work only with more closed, well-defined tasks?
How do they deal with knowledge and context? Are they more focused on learning or teaching — or maybe both?

Hard skills

General technical knowledge or experience with common use cases in the company’s projects and products.

Experience with micro frontends
Experience handling camera, audio, and video through browser native APIs
Experience with multi-tenant systems
Experience with queue systems
Experience with CI/CD
Experience with testing
Experience with specific programming languages and frameworks

Soft skills

Communicating clearly, objectively, and asynchronously — as exemplified by nohello.net
Keeping documents, research, and documentation alive and up to date
Asking questions until they have all the information they need to act
Giving visibility to the team about their own work and sometimes even the team’s work as a whole
Frequently giving and seeking feedback, both vertically and horizontally

Culture

Everything that’s part of the company’s culture and helps someone fit in. These are usually elements that don’t quite fit under soft skills but complement the items in responsibility and capability.

Always putting themselves in the end user's shoes
Boy scout rule: leave everything better than they found it
Constantly looking to help other team members
Able to learn with yours and others mistakes aswell
Seeks and proposes solutions that tackle the root of a problem, not symptoms

This content is part of a series of articles I’ll be writing on software enginering career paths — from internship to ICs and senior management. It’ll also be available in my future Zettelkasten.