How to Be Promoted Quickly as a Junior Software Developer
So, You Want to Be Promoted Quickly
Who doesn’t want to be promoted quickly? While I don’t think you’ll find anyone who would say no to levelling up there are a lot of developers saying no in a different way through lack of engagement with the promotion process. This is a career killer in software development which is a competitive field where the top technology companies like Amazon and Google have well defined meritocratic promotion systems.
Having worked at some household name companies on the software side I have first hand experience in seeing what doesn’t work and more importantly what does work when it comes to securing a promotion. As I heard more and more advice from friends as well as colleagues and senior developers on how to improve my chances of promotion, I developed a distilled list of strategies that I will share with you today. This list of strategies helped me become the fastest promoted junior developer in my organisation at a top tech company, beating the average tenure before promotion of 18 months by 7 months.
However, I would like to temper expectations as these strategies are not the silver bullet for getting a promotion; they will not work unless you do! This means you should know your company’s software development levels well, for example is there a clear set of criteria you must demonstrate before going from junior to mid-level developer? If it isn’t written down extrapolate from your colleagues what qualities mid-level developers have that juniors don’t.
Once you know or have an intuition as to what you need to demonstrate to get promoted you can start moulding your work and approach to promotion around showing off those qualities as well as building a rock-solid foundation with the strategies I lay out in this article.
I will dive in to the strategies later in the article, but to introduce them they are:
- Strong Ownership
- Customer Focus
- Management Engagement
- Maximise Visibility
- Data Driven
This is one I learned from a friend who worked at Amazon and Apple and at both he excelled. He explained that ownership doesn’t just mean you say “I came up with this idea” it means you drive the idea forward, championing it in design meetings as well as taking on the responsibility of making sure the project is making good progress whether it is an individual effort of a team effort.
As a strong owner you should be the subject matter expert for the project you own, if anyone wants to know the status of the project you know it or if they want to know why certain technical decision are being made you can explain to them. As a junior developer this really stands out as a quality that more senior developers have but there is no reason you can’t ask your manager or senior developer to expand your influence by allowing you to take ownership of a project.
As an anecdote when I joined my first company out of university, I asked to be the owner of a piece of legacy code nobody else wanted. To some of my friends this seemed like career suicide, after all who wants to be working on legacy code? However, there was a method to my madness, and I spent the time required to become the expert on this legacy system. From there I started paying down more and more of the technical debt until suddenly my colleagues were no longer running into bugs that previously plagued the system. This earned a lot of trust for me within the team and showed that I could own a reasonably large piece of code and drive it to a better place.
Ownership seems like a double-edged sword because it means you need to own up to your mistakes. If you introduce a bug its up to you to admit to it and fix it, however this isn’t a bad thing. Many developers try and hide their mistakes, their thinking is that if they admit to mistakes then they will look less competent because everyone else will know they made the mistake. This logic is flawed however, especially in a development environment, all someone has to do to figure out who introduced a bug is to look at the version control (e.g. git) history of the code. So, there is really no reason to try and hide your shortcomings, owning up to them and taking ownership of fixing them will earn a lot more trust within the team. I have introduced countless bugs into various projects throughout my career, but I always fixed them when they became known to me. Ownership IS a double-edged sword, but both edges will help you towards your promotion.
Much of Amazon’s success has been attributed to it’s mission to be “earth's most customer-centric company” (source) and you can leverage the same customer focus in your development work. For example, a colleague of mine was recently weighing up two big fixes to add to our next release, he knew he only had time to do one and couldn’t decide. Our manager, who is excellent at focusing on the customer, proposed he query our database of customer bug reports. My colleague did exactly that, coming in the next day with a new found focus and telling our manager: “The first bug appears in 67% of bug reports, the second in only 17%, I am going to prioritise the first to help the larger block of customers.”
Now it won’t always be so easy to dive into a database of customer bug reports and derive prioritisation from it. Sometimes you will have to search through tickets you receive or surveys the customers have done regarding your product. If your team has no mechanism for engaging your customers (be they external members of the public or internal teams, both are still customers) then be the one to propose such a mechanism such as a feedback form or monthly survey.
Once you have the customer data (the importance of data is discussed in the ‘data driven’ strategy section) you can make informed decisions about what to prioritise. Furthermore when it comes time to write your promotion document or deliver your promotion case verbally you should be able to cite some statistic that are customer centric, for example: “While working on this project I identified our customers were being given incorrect HTTP response codes for certain actions, I corrected the response codes which correlated with an increase in customer satisfaction scores from 4.2 out of 5 to 4.4 out of 5.”
Another powerful tool in your promotion toolbox is direct quotes from customers, and this was cited as one of the biggest reasons I was promoted quickly as a junior developer. I actively engaged customers my changes had helped and asked them for a quick quote on how the work impacted them. Lot’s of times I got no response, that’s fine because I was contacting enough customers that even if only a few gave me quotes it would significantly bolster my case for promotion. Internal customers such as other teams within your company generally respond very well to this kind of request because they understand the promotion process and understand that you have helped them so if they reciprocate you are more likely to help again in future. My requests were always worded to the effect of this: “Hi X, I am writing my promotion document and would like some customer quotes around the work I did to help you on product Y, would you be able to provide a few lines on how my work impacted your experience with product Y?”
It should come as no surprise that part of helping yourself towards your promotion is a bit of marketing. No false advertising though, this marketing is just to help boost your influence within the team and keep yourself at the forefront of your colleagues’ minds when they are asking themselves who influences the team’s technical direction. There are several mediums common to the vast majority of software development roles you can leverage towards maximising your visibility so I will dive into and describe them each in turn:
- Code Reviews: Most software developers see code reviews as a necessary evil, something you must get through to deliver work. Some other more toxic developers see it as an opportunity to point out flaws in their colleague’s code with no consequences. However, code reviews are one of the best ways to make your knowledge visible. Instead of just pointing out mistakes in another developer’s code you should offer alternative solutions and link to helpful resources. This approach is particularly impactful when reviewing a newer developers code as everyone who sees the code review will be able to see you sharing knowledge effectively. This technique also applies when it is your code under review, be prepared to answer questions about why you coded your solution the way you did and back it up with data or resources such as best practices documents. An example of this approach would be: “Instead of explicitly closing the resource you created you can use the new try-with-resources statement which will handle automatically closing the resources for you as long as they implement the Closeable interface. The Javadoc for try-with-resources is worth a read.”
- Design Meetings: There are three types of developers in design meetings; those who say nothing, those who say things only to be heard and those who give valuable feedback. You want to be in the last category. In my experience other developers have a more negative reaction to someone saying something for the sake of being heard than someone who said nothing. Much like the advice for code reviews you should see design meetings as a time to show your knowledge by giving specific and helpful feedback. On key difference is that often in design meetings you will be able to give feedback at higher levels of abstraction such as the system architecture, this is the perfect time to show your ability to consider some key aspects of system design; scalability, operational workload (i.e. will this cause us pain in future) and extensibility. As always be constructive in your feedback, it is perfectly fine to just say “I really like this architecture for X reasons, awesome work”, this will buy a lot of good faith with the developer proposing the design. If you are giving feedback or constructive criticism then follow a template similar to the following: “I think this design is great and there are only a few improvements I think could be made, for example the need for our own in-house workflow coordinator could be removed if we use AWS Step Functions which will likely be cheaper when we factor in development time.”
- Tech Talks: Allow me to once again use an anecdote to demonstrate the point I want to make. When I was only 6 months into my first job out of university, I was put on a project that required integrating with multiple AWS services and the developers on the project were painstakingly writing their own libraries to abstract away those integrations. It took me only a few hours to find perfectly acceptable open source libraries that did what they wanted and more, one meeting later and we had shifted to using the libraries we found. The senior developer on the project thanked me and suggested I do a 30-minute tech talk on using the libraries. So, I spent the next few days reading the code, frantically taking notes and making a PowerPoint presentation. The presentation went well, I obviously couldn’t cover everything about multiple libraries in 30 minutes, but I gave a quick introduction to each. Afterwards the senior developer expressed that everyone was impressed with my ability to find the libraries and quickly figure out how they would benefit us and that giving a tech talk was the most efficient way of demonstrating knowledge to wide audience. The lesson here is that if you feel you have a topic you are the most knowledgeable in the team on then you should throw together a quick tech talk and demonstrate that knowledge, not only does it massively bolster your case for promotion but it also helps your team deliver faster and more effective products. You don’t need to be an expert in the topic either, as shown by my story I was no expert in the libraries I found, but I was the most knowledgeable on that topic (remember it is relative to your colleagues).
When writing a case for promotion or just verbally communicating it you don’t want to leave room for subjectivity and bias to come into it. Let’s be realistic, you’re dealing with other humans who are biased from their life experiences and as well as their own opinions on all sorts of topics. You want to eliminate subjectivity and only leave room for objectivity and fortunately there is one rock solid way to do this: data.
Let’s dive into another anecdote from my own promotion case. I had to quantify my impact on the legacy project we discussed earlier and initially I simply wrote something along the lines of “improved data accuracy significantly” and was happy enough with that. You can imagine my shock when the trusted colleague I got to review the document came back and said: “How significantly was the data accuracy improved? You’re trying to claim you improved data accuracy with no data to back it up.”
Of course, she was correct because I had made a subjective statement, significance is completely subjective. So, I dove into the data, making queries specifically designed to show the difference in accuracy before I worked on the project versus after I improved it.
I replaced my subjective statement with a concrete and objective statement: “In 2 months on the project I improved the accuracy of our engagement statistic which previously reported an erroneous value of 87% and which now shows the true value of 91%.”
See how much stronger the objective statement is? It’s more specific as to what was improved and more importantly by how much. This is how you should approach any presentations you need to present, interviews you need to do or documents you must submit regarding your promotion. With data on your side you eliminate biases in your reviewers and give yourself the best chance of promotion.
This strategy seeks to maximise your visibility specifically with your manager, after all they will likely have a significant impact on whether you are promoted or not. There are two main tools for keeping your manager in the loop as to what you are working on and how you are progressing:
- Regular one-to-one meetings: If you don’t already have regular meetings with your manager in a one-to-one setting then try to get them set up, they could be weekly, fortnightly or monthly as long as they are semi-regular. Use these meetings to update your manager on your progress using the previous strategies, particularly through being ‘data driven’ and ‘customer focused’. You can also use this time to ask your managers opinion on your progress as well as asking if any of your colleagues have given any feedback on you (a good manager should anonymise any feedback). These meetings will allow you to ensure your manager knows where you as well as allowing you to gauge how your progressing relative to where you want to be. It’s also advisable to be honest with your manager in saying you are pursuing promotion and are looking for opportunities to get to the next level, often your manager will open doors for you then to engage at that next level.
- Progress emails: This is the asynchronous version of the one-to-one meeting and should be done at a cadence of roughly weekly. Keep the email short and to the point, all you’re doing here is saying what you’re doing and what you intend to do before the next progress email as well as including anything that is blocking your progress. If your team has regular stand-up meetings or your one-to-ones are regular enough you may not even need to send these emails. The only purpose of these emails is to report progress and flag any potential blockers you have.
Which strategy do you feel will be most useful for you?
We have covered a few strategies to get any junior developer started on their way to an early promotion, these strategies can also be used by current developers who feel their chance of promotion has stagnated to reinvigorate their career and accelerate growth. My hope is you now feel you have the tools to write the best promotion document you can or deliver the best verbal case for promotion possible. I wish you all the best in your careers in software development and if you have any questions or further strategies you would like to share please comment them on the article.