How to get promoted
Everyone wants to get promoted quickly. It was certainly what I cared about most when choosing where to work after college. Job hopping works, but it’s a pain – most people would prefer to advance in their career while staying at the same company.
There are five consistent ways a software engineer can level up within a meritocratic organization.
- Increase quantity of output
- Increase quality of output
- Develop domain-relevant technical expertise
- Develop a complementary non-technical skill
- Develop productive personality traits
(Selecting the right organization in the first place is a different challenge worthy of its own discussion. Suffice it to say that promotions are more difficult to come by in a company whose headcount and revenue are stagnant or declining. And it goes without saying that not all companies are equally good at recognizing individual impact. I will put that aside for now, and focus on what you can do if you are at a company where rapid advancement is possible.)
Quantity
This is the easiest and most straightforward way to become a top performer. Just do more. Take the work you are doing right now and try to increase it by 50-100%. Then increase it by that amount again. Write more code, ship more features, build more functionality, merge more pull requests, review more code, write more technical docs, complete more tickets, fix more bugs.
To accomplish this, you can either increase your efficiency, work more hours, or both. For most people I recommend working more hours, and efficiency gains will happen naturally over time.
Everyone’s life situation demands different things from them, but for an ambitious young engineer who is trying to advance more quickly than the industry average, I would recommend trying to work 45-50 hours a week on at least a semi-regular basis. Get to work early, work through lunch, stay late, work a little over the weekend or before/after standard hours on weekdays to boost your output – whatever works best with your schedule.
Of course, you don’t have to do any of this, but if you work the same way everyone else works, you will get the results everyone else gets. If you are trying to do things differently, there is no substitute for hard work.
Quality
This is a more difficult but higher leverage way to improve your work performance. Quality can be thought of as three different things:
- Quantity/severity of bugs that you ship
- How closely your work adheres to product and design specifications
- How good your code is
Shipping bugs is very easy to do, but not always easy to notice. In many cases, senior team members will catch your bugs in production and fix them before you can get to them. In addition to testing your own code thoroughly before merging it, you should learn to identify, communicate about, and fix bugs in production, especially the ones you cause. Learn from the bugs you ship, and take steps to avoid doing it again.
Adhering to design and product specifications is dependent on having them in the first place, but assuming you do, it’s a good idea to pay close attention to the spec and implement things correctly the first time, rather than waiting for feedback to come up during testing. Most engineers don’t take specs very seriously, so if you do it will make you stand out in a favorable way.
Lastly, the overall quality of your code itself does matter, independent of any particular result. This is too complex to give a comprehensive definition here, but at a high level, good code is code that is pleasant to work with, easy to maintain, simple rather than complex, easily testable, meticulously thought through, and straightforward to understand. Writing good code and improving old code is another good way to advance yourself within a technical organization.
Technical Expertise
Most engineers, especially those who are early in their career, should focus solely on improving the quality and quantity of their output. Generalists are usually more valuable than specialists at this stage. However, there are circumstances where developing a particular technical expertise can be beneficial.
This depends primarily on the type of company you are working for. For instance, if you work in crypto, learn smart contracts; if you work for an AI startup, study machine learning; if you work for a company with massive scale, learn about distributed systems and databases.
Most people in the beginning should just focus on becoming a really good software engineer (high quantity + high quality), but as you get closer to the senior/staff level, having a deep technical expertise in a domain relevant to the company you are working for can be beneficial.
Complementary Non-Technical Skill
Software engineers aren’t expected to know about anything more than writing code, but if they happen to be good at other things too, they may have an easier time advancing within the organization.
The highest impact non-technical skill that an engineer can develop is the ability to communicate well. Take classes in writing and public speaking, and notice how much more seriously people take your work – even if the work itself is no different. Invest in writing really good pull request descriptions, product announcements, and technical documents, and that effort will come back to you in a major way.
There are other beneficial skills for an engineer to develop, particularly product and design skills. An engineer who can open up Figma or develop a comprehensive product plan is a rare and useful individual.
Experience in other domains such as marketing, business operations, sales, finance, or even legal/compliance can be useful as well, though less obviously so.
There may be something specific to your company too. For instance, Remi makes software for the roofing industry; there are employees in our organization who have expertise in roofing, and it’s like a cheat code for knowing what the highest impact projects are to work on.
Personality Traits
This is the last category because a truly meritocratic organization will evaluate you based on what you do, not who you are. With that said, personality traits have a huge impact on everything in your life, and a little bit of development here goes a long way.
Most of the impact here is eliminating bad traits from your personality. The most common errors I see in young developers are ego, insecurity, and complaining. There are many, many more but fixing these is a good place to start
Ego manifests mainly in defensiveness and the inability to take feedback, especially performance-related feedback. If you think you already have everything figured out and you just need to convince other people to see it, you’re going to be frustrated and ineffective. Try to get outside of your own head and see where the feedback is coming from.
Insecurity is closely related to ego, and may have the same root cause. It’s common to see people focus more on their perception than their performance. The irony is that other people can see that you are operating from a place of insecurity, and if you just stopped worrying about that and focused on your work, you wouldn’t have perception issues at all.
Complaining can come from a lot of different places – ideology and pain avoidance being the most common – but ultimately it doesn’t matter. Never, ever complain. Just don’t do it. It will make you look bad, it will make you unpleasant to work with, and it will make you unhappy. It’s not worth it.
What about positive attributes? In my opinion, the highest leverage traits for outperformance at work are ambition, ownership, and empathy.
Ambition goes without saying. If you don’t want to be great, you won’t be. I don’t believe in the concept of “accidental greatness”. It is a fantasy. You should have a goal in mind at all times, and be willing to work very hard to achieve it.
From a manager’s perspective, and managers are usually the ones determining who gets a promotion, ownership is the most valuable trait an employee can have. The whole point of hiring someone is so that you have one less thing to worry about. Software engineers are not paid to write code, they are paid to solve problems. Try to figure out what problem your code is supposed to be solving, and focus on solving that problem end to end.
Empathy is related to ownership, because I am talking about having empathy for your leaders. Try to find something your manager is concerned about and take it off of his plate without being asked. Use empathy to figure out what the CEO cares about most and identify how that trickles down to your work. Of course, empathy for the customer and for your company’s business partners is also extremely useful.
Summary
Most software engineers should focus on improving the quality and quantity of their output – work harder and write better code. If you think you are already doing that, raise the bar, then raise it again. Set as high a standard for your work as you can sustain. Unless your organization is dysfunctional, you will get ahead.
There’s value in developing expertise in a particular technical area if your company does something innovative or unique in that area. For most engineers at most companies, I wouldn’t worry about this until you start getting closer to the senior or staff level, and even then it’s not necessarily a requirement.
There’s also significant value in learning how to communicate effectively. Spend some time on this every now and then – maybe a few hours every month reading a book, or writing a blog, or giving a presentation, or doing something to improve your soft skills.
Lastly, make sure that the personality traits you are either consciously or subconsciously developing are helping you reach your goals. There are a million ways for an otherwise good engineer to self-sabotage. Help yourself get out of your own way by spending some time developing internal and external leadership qualities.
Trying to speedrun career progression is not for everyone, but for those who are beginning to walk this path, this guide should help you make progress towards your goals.