How to get promoted as a software engineer

Let me guess. You

• are a software engineer who knows your company's IT in and out
• you are pretty good at coding
• you want to get promoted (senior or lead engineer)

but somehow things are not moving forward and you don't know why. Somehow this entire process seems intransparent to you and you just don't understand why your manager does not seem to recognize your contributions.

In this article we will discuss quite a few (surprising) insights when it comes to promotions.

Getting promoted is all about your manager's interests

All right, so who decides whether you get promoted?

Yes, it is your manager and your manager's manager.

So let's put ourselves in their shoes and try to understand how they decide who will get promoted and who won't.

To get promoted you need to understand your manager

Have you ever wondered what managers are doing all day? Most of the time it is sitting in meetings where they are either forced to commit to deliver a certain product or feature on a certain date or where they need to commit to hit certain revenue / sales milestones.

Middle managers are typically held accountable for whether a product or feature is delivered in time with the right quality. From vice president or head of engineering onwards it is more about the numbers.

For managers it is typically hard to tell whether a specific goal is even possible to reach because they are hands-off. A (hands-off) manager has to completely rely on his team to deliver what was promised while he still carries the end-to-end responsibility.

In addition managers typically worry about:

• how to avoid looking like a fool if something does not work
• their understaffed team
• their (sometimes) unmotivated team
• team members arguing with each other
• Jonathan's recent divorce which negatively affects his performance
• Joe who is on sick leave and noone is doing his work
• how the project can still be shipped on time
• how to communicate to his boss that the project's timeline is too optimistic
• how to push the responsibility of a failed project to someone else

Failing to deliver on time with the expected quality is very problematic for a manager because people will start questioning his management skills. This is of course not beneficial for the manager's career trajectory.

What your manager really wants but what he does not tell you

All right, at this point we can say:

• your manager's performance depends on the timely delivery of artefacts that he does not fully understand
• your manager is hands-off and needs to completely rely on others to deliver in time with the correct quality
• every time a manager commits to a deadline or to a milestone, his reputation is on the line. Failure will be very visible and will harm the manager's career goals.
• your manager and your manager's boss decide whether you get promoted
• your manager will try everything he can to make sure that if something went wrong it does not look as if it is his responsibility
• your manager will reward you to the extent that your input is useful for him to move up

At this point it is fairly trivial to identify a couple of goals your manager has.

Manager interest #1: shine in front of his boss

Your manager wants to demonstrate that he uses the company's resources (the budget) effectively and that he is accomplishing the goals and milestones that he committed to. That is of course in order to advance his own career.

By the way, if the company's goal and the manager's goals are not congruent, the manager will pretty much always prefer his own personal goals over the ones of the company.

This is also the reason why managers sometimes insist to deliver things on a completely unrealistic timeline - simply because it would be a pity to lose his bonus. So if the manager has the choice between listening to his team who wants to build a stable, resilient system without much technical debt and getting his bonus, the bonus will most probably be preferred.

Your manager competes with several other managers for a higher position. That's why just doing "good" work is probably not sufficient to move the needle. The best possible scenario for a manager is if he (meaning his developers) are able to reach something really exceptional. Or if it just looks exceptional, that will do as well.

Manager interest #2: peace of mind regarding deadlines

Committing to deadlines is kind of tough.

That's why your manager needs a sparring partner with which he can talk openly about estimations, possible issues, architecture and so on. And this is going to be you.

He needs someone who can do initial investigations and someone who can give realistic estimations. Like so the manager is relatively certain that he can deliver what he is committing to. For a manager's career it is quite bad if he has to admit late in the project that something cannot be shipped in time because it looks as if he "messed it up".

Manager interest #3: stable and resilient product

Have you ever done a demo and then the demo failed? If yes, I bet this was probably a very embarassing experience. Now just imagine a manager communicates that the product has been successfully shipped and just afterwards the incidents are coming in.

This means angry customers, bad reviews on the web and less sales. In nearly all cases a failed launch - or maybe to be more precise: a launch that is considered a failure - is one of the worst things that can happen to a manager.

Oftentimes your manager is walking a fine line here.

On the one hand, he does not want to admit that the deadline is unrealistic because that would make him incompetent. On the other hand if he pushes the team to the limit and the team barely makes it in time but ships an unstable product, then his management failure can even be quantified by the amount of lost sales or by the amount of bad customer reviews.

Because in your manager's boss' head, your manager should just have said no.

That means your manager needs to make sure that the product is properly QAed and he also needs code that takes into account edge cases from the start so that less incidents on production will happen.

How concretely can you advance your manager's interests (and get promoted)?

Now that you understand your manager's interest, you can act accordingly to increase his perceived value of you. The following ideas have one thing in common: they create visibility for you: both in your team and towards your manager and his boss.

The key thing here is to understand that you should strive for demonstrating that you are able to advance your manager's and your manager's boss' interests - with high visibility.

Your manager's boss will probably even care less about code than your manager. While getting even better at coding is intellectually very interesting, it typically has a very low visibility and it will not help you that much with demonstrating that you can advance your manager's and your manager's boss' interests.

The only exception here is if you are so smart that you can solve a stability or technical problem nobody was able to solve but which is causing a lot of trouble for the company. But this is rather rare.

So overall I don't want to say that your coding skills don't matter. They actually do matter - but probably less than you might expect.

You want to stand out by taking end-to-end responsibility for the product itself in various ways e.g. by doing architecture planning, by organizing meetings or by communicating with stakeholders.

Because after all leadership is about transitioning from a hands-on maker towards a multiplier which enables the whole team to deliver better results.

Now let's talk about what you can do concretely:

Help your manager by creating architecture drafts and estimations

Before a project is officially started, there is typically some business impact analysis by management. The goal is to assess how much time a particular functionality would take and whether the potential benefits are worth it. Typically the (middle) managers are asked to give some kind of estimation to quantify opportunity costs.

Since your manager is hands-off, he needs someone to look into it by create architecture drafts or by analyze third party documentation and so on.

The big advantage is that these type of activities have a very high visibility. Your manager is going to see it and your manager's boss as well because he probably ask your manager to "take care of this".

Help your manager and your team by writing documentation

Coding is always the last step and your manager most probably does not see or care about the code. However for him it is beneficial to at least know roughly how the system works. Documentation / Confluence pages are a very useful way of helping your manager to gain knowledge about a system. He can then use this knowledge in todye meetings to make better ad-hoc estimations whether a deadline seems feasible.

Help your manager and your team by organizing internal or cross-team meetings

In a project there are often a lot of things that need to be clarified. For one, some things need to be clarified internally but oftentimes nobd feels the urge to do so. The product manager will argue that this is a technical kind of thing and that the developers should do it. And the devs will argue that they are already taking care of their Jira tickets.

You can oftentimes just unblock the team by organizing meetings. The important thing here is that you should not come empty-handed to the meeting, but you should make a proposal.

This can be an a proposal on what new microservices the team will need and how they are going to communicate with each other. The meeting can also be about cross-cutting concerns like logging and monitoring.

If you bring a proposal to the meeting, then it is oftentimes very easy to come to a conclusion because the discussion is not completely open.

I found creating Confluence pages with architecture drafts quite useful.

You probably have the vote of your manager, but by also helping other teams your promotion will probably be met with less skepticism from other team's managers.

Help your manager by raising potential issues and challenges to business

Today email ist still considered the main / official communication channel. I'm not asking you to spend the whole day writing emails because otherwise you would not get "real work" done.

However if you see a main impediment for a project, e.g. something has been forgotten in the planning or requirements are not clear for a particular functionality, it is a good idea to write an email to business stakeholders and cc your manager.

Like so you demonstrate that you think ahead and that you try to remove obstacles wherever possible so that the entire team can work. This of course helps your manager with his career goals because he will be responsible if something is not working.

Other things you can do

• do some boring work for your manager (like creating powerpoint presentations, Confluence pages) because your manager can use them to report to his manager. You still remember who makes the decision on the promotion, right?
• coordinate deployments: if you have a bigger deployment then oftentimes noone documenting how to actually carry out the deployment (bumping docker images, changing environment variables)
• actively participate in the hiring process by interviewing people and by showing empathy. Hiring is an essential activity once you are part of the leadership team.

A promotion is never a favour, but a strategic move

If you can convince your manager through your actions that you are crucial for his career ambitions, then he will promote you. Also bear in mind that this does not happen out of the goodness of his heart but rather for strategic reasons.

For one, he wants you to stay entertained. After all you proved very useful when he was pursuing his career ambitions. On the other hand your manager knows that if he moves up, he will get even more responsibility and even harder tasks.

So he will be even more dependent on his team and particularly on you who can support him. In addition, promoting someone is a way to bind someone to a company. Once you get a better title, you cannot immediately leave the company - at least not without indirectly harming your career trajectory. If a hiring manager sees that you have been promoted and then you immediately left, he will think that you were probably not qualified for the task and that this is the reason why you took your hat. Whether this assessment is actually correct, is a completely different story.

Welcome to the world of "alternative facts" - what people believe to be true is more important than what is actually true.

Anyway, you will probably have a very hard time convincing the hiring manager that were actually doing well in your last job.

Conclusion

Your manager and your manager's boss make the decision whether you get promoted or not.

Your manager is accountable for the successful delivery of the project and always needs to commit to deadlines.

You can help you manager by investigating the scope of a project (e.g. with architecture drafts, creating some presentation). It is also helpful if you take over the tasks that noone is clearly responsible for (e.g. cross cutting concerns like logging or monitoring, alignment meetings with other teams, hiring).

You might have noticed that completing more tickets was not on the list because it usually does not have that much visibility - especially towards your manager's boss.

Just completing more tickets is probably not enough to stand out by a large margin compared to the remaining engineers.

The strategy described in here is more about organizing the tech team and taking end-to-end responsibility for the delivery. Because ultimately a successful and timely launch is what brings your manager (and you) forward.