A manager's take on engineering promotion

Why engineers should be mindful about their level of autonomy and not only the impact they create.

The rules around getting promoted can be confusing for engineers. A person who puts in significant effort into the job might think they'll get the promotion they want if they're really good. They might think, “I just finished a big project. My impact was significant. Of course, I should be promoted!” They are only focusing on one side of the story, and their manager may see things differently.

I've seen many engineers struggling with promotions for various reasons. One common pitfall that people fall into, is that they use a recent success to justify being promoted. Yes, contribution is important, it's crucial to have a track record that demonstrates impact. However, there is another dimension that engineers often overlook — the level of autonomy. Ignoring its significance could cost years of being stuck in the current role.

Here I use the dictionary definition of autonomy:

The quality or state of being self-governing.

It means that, by knowing what is important to the organization, individuals will take action to achieve those outcomes.

To understand why autonomy is critical, let's consider how individual contributors and managers contribute to the success of the organization.

The main job of an engineer is to build and maintain software systems that support the business.

That's why companies hire engineers. That's what engineers get paid for. Of course, there are more details to the role, but they are not relevant for this discussion.

Companies hire managers for different reasons:

The main job of a manager is to build an organization capable of delivering complex projects.

The manager's primary role is to ensure continuity. Which means growing people capable of leading complex projects, people who shape the cultural norms within the team. Importantly, these people must require little supervision. Otherwise, it is not possible to scale the organization. What senior engineers bring to the company is autonomy and impact.

That's the reason why gaining autonomy is so essential. This often ignored by individual contributors when they think about their career. While pursuing a promotion, many engineers focus too much on the impact they've made. They search for stretch opportunities: “Oh, I signed up for project X where I will be working with a principal engineer. I'll learn a lot on this project. I think that it’s a great career opportunity for me.”

It might be. Or not.

Engineers are eager to learn new things, they typically like a challenge. However, taking stretch opportunities can hinder your ability to demonstrate your level of autonomy. When you're taking on new learning opportunities, someone must keep an eye on what you're doing and correct your mistakes. Chasing only the impact part might be dangerous to your career. Because:

You deliver maximum value when you act within the area of your competence.

Managers greatly value a high degree of autonomy. It means that they can trust engineers with running initiatives. They need people who can lead. One's ability to work on impactful projects with little to no supervision sends a strong message.

I am autonomous, am I not?

One reason why individual contributors might lack autonomy is when they believe that doing a specific task is not part of their job. A developer might think that it's not their job to resolve cross-team dependencies. In which case, they push that work back to their manager — “Hey, we have a dependency on that team for project X. Can you align with them on timelines?”

There is nothing wrong with asking for support. It is crucial to resolve issues before they become blockers. However, if you were supposed to lead this project, you probably should have handled this discussion yourself. Alternatively, you can agree with the manager in advance to step-in when support might be needed — “Hey, I think I can handle the dependencies for this project. However, things can go faster, if you step in at certain moments. I'll let you know and will get you up to speed if such a situation happens. Is that OK?”

The common issue with the “not-my-job” mentality is that engineers might think, “If we had properly defined requirements/design/product, I wouldn't have had this issue.” If it were possible to get the requirements straight, that would make sense. I doubt it’s realistic to expect everything to run smoothly. In a perfect world, none would need to solve small bumps and everyone would be efficient.

What makes you stand out is that you're effective in imperfect conditions.

If everything had gone well, there wouldn't have been any difference between you and any other engineer in the organization working on a specific project. Your ability to handle problems and get things back on track is what makes you special. You might think of these bumps in the road as annoying things. Alternatively, you can frame them as opportunities for yourself to stand out. I think the latter is a much better way to go about your career.

How do I grow my autonomy?

Understand your area of competence

Start by defining the area of your competence: what is it you can accomplish, 100% independently, that's needed for your job? It might be knowing the nuts and bolts of the build system your company uses, the inner workings of the framework used for automated testing, or improving the overall observability of the systems. These are the things you can improve in the team, regardless of which area you're working on. But only if you know them really well.

Build knowledge in adjacent areas of expertise

I like the idea of T-shape model of knowledge. If you're working on the frontend, it might be valuable to learn more about UX, and how designers work, which tools they use. You're not expected to be a designer. Yet, understanding how they work, will make your collaboration with UX smoother since you will be able to handle imperfections that might arise from the UX side with much more ease. I believe that learning more about project management is always a good investment for engineers. It helps you work better with product/project/program managers. If you're focused on the backend, learning a bit about machine learning or data engineering might open new ways of solving problems that are difficult to solve in your current tech stack.

Look for signals to improve

It's rare that you receive feedback about your autonomy, unless you really screwed something up.

It often comes in the form of suggestions:

• Hey, do you think it's a good idea to review this design document with the team?

• Have you considered adding this section into your proposal?

• It might be worth checking with another team if this assumption is valid.

These “suggestions” point out to things other people expected you to do, but you didn't. They phrased nicely, but they indicate that something is missing.

I believe that developing your own autonomy should come before focusing on the impact. Your manager sees your readiness in your consistency of demonstrating skills and behaviors. The manager needs to see that you’ve acquired these skills, and you demonstrate them consistently. Yes, it was a tough work to deliver the last project, you went an extra mile there and did a great job. However, would you be able to take the next one with less supervision, and deliver it with less friction?

More thoughts on engineering promotions: