Better Programming

Advice for programmers.

Follow publication

The Engineering Career Ladder Trap

Jose Huerta
Better Programming
Published in
5 min readAug 16, 2022
Photo from Mitchel Lensink

I’ve been more and more interested in career ladders in recent years. I was a main contributor to the engineering career ladder in my previous company, and I was happy when knowing that my current company was also using one. Every day, I see more and more colleagues using them in their companies. I must say that I love this tool.

The career ladder is usually matched with a competency matrix or a description of expectations at each level. With those expectations, we can create a framework where engineers know the expectations and together we can outline a growth path. Used correctly, it’s a very powerful tool for managers.

On the other hand, as with any other tool, when not used correctly it can be very dangerous. After three years of using them, I’ve seen some misbehaviours that instead of motivating and helping the engineers to grow, were frustrating them, and I’d to share what I learned with you.

The first red flag I noticed was around a year and a half ago. I hired a very good developer — very young but technically skilled. After some one-on-ones, we started to work around the career ladder. I liked to start with them analysing and self-evaluating themselves.

In the next one-on-one, he came to me and expressed a concern that blew my mind. He felt that he was about to be stocked with limited options to improve because moving to the next step implied developing a lot of soft skills and getting involved with the product. He wanted to be better technically, improve his operations skills, profiling, memory management, and other high-level hard skills. He was also interested in improving in clean code, patterns, testing, etc. But he was not ready to face conversations directly with the customer, take the lead in some epics, or have a business mindset.

Later I noticed how, because of applying this career ladder, we were pushing some good developers out of their comfort zone. For most of them, this was a very good step — making them improve. For others, it was perceived by them that they were not as good as they thought, and suddenly an impostor syndrome appeared. Probably the syndrome was already there. But I have the feeling that maybe this set of expected behaviours was highlighting their gaps and fears, increasing the impostor feeling.

I’ve heard other people talking about those things that could be summarised in the next sentence: “You are forcing me to be someone I don’t want or that I’m not prepared to be.” I must say this happens in a few cases, far less than 10% of the people. But if it happens, it is likely to happen with high performers. These people have fallen into the engineering career ladder trap.

The root of the problem resides in the idealized version we have of the perfect engineer. This perfect engineer is someone technically excellent, who evangelises best practices and is a helper and a mentor in our community. They are someone with a very strong feeling of ownership and business acumen. Someone capable of leading initiatives, people, and inspiring others.

In summary, they are the full package of soft and hard skills! With this idealised version, we all have designed one path to reach this super-engineer status. One path to reach one specific role: the career ladder. Can one path fit every engineer? Of course, it can’t.

Most companies have seen that one path is not enough, and they have designed others, like the management path, architecture, or devops. But those are for a completely different job description and set of expectations. In the end, almost all of us have designed only one career ladder and competency matrix for the developers.

I’ve thought about designing more career ladders depending on the internal role in the team. That way we could have one for the amazing individual contributor, the problem solver, the tech leader, the analyst, and a lot of others. The number of possible roles is almost equal to the number of engineers; it’s impractical to try to fit them in some predefined roles.

In our willingness to put order and structure, we sometimes forget about the first line of the agile manifesto: People and interactions over processes and tools. We are trying to have a tool and a process in place for our people. We forget about their individuality, and that it’s impossible to cover it completely in a process.

Now we know the problem, How do we solve it? By making better use of the tool. The career ladder is amazing and has a proper competency matrix that describes all dimensions where an engineer can develop their career. There are some areas that we can consider a must, tied to our culture. Those should be highlighted, so everybody is aware of them. Not developing those traits and behaviours is not only a blocker for their career but an indication that maybe they don’t believe in the company’s culture.

For instance, I can understand that “not believing in testing” could be a reason to consider an engineer out of our culture. Some soft skills and hard skills will be covered by this “mandatory path.”

The rest of the skills will be also important, but we must realise that we don’t need everybody willing to develop them. Analytical skills and domain knowledge could be an example. A team can function perfectly with half of the team not having the skills, and even not willing to develop them. Communication skills, like doing presentations or addressing customers, are another set of skills that can make an engineer more valuable but shouldn’t be considered a requirement.

That way when presenting the career ladder to our engineers, we make clear that this is the complete set of skills they can choose to develop. It’s a tool we can use to define the next goals and challenges, but not necessarily a scoring system. A competency matrix that ties abilities and behaviours to the different levels in the career ladder can be used also, but we need to make it explicitly clear that this is just an orientation. People can progress without developing or paying interest in some particular areas, but they will need to compensate for that with strong advancements in others.

As managers, we need to boost the capacities that make our people the most valuable as possible. We need to push them to discover new traits when we see the option. We need to see when this pushing is healthy and can result in a much better professional and when is it going to be perceived as forcing them to do what they don’t like and trigger frustration.

As engineer managers, only when we master this skill we will be able to extract the full potential of career ladders avoiding the engineering career ladder trap.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Jose Huerta
Jose Huerta

Written by Jose Huerta

Mallorca (Spain), I like all management and technical areas of IT. Operations, Development or Support. Currently I work as Head of Engineering at TUI Musement.

Responses (1)

Write a response