My Groundwork to Ask for a Promotion
The transition from junior developer to senior developer at work entails several bits of groundwork to be laid out far in advance. Much in the same way that the best time to plant a tree was twenty years ago.
This year I was passed over for promotion, through no fault of my own. It is simply the cold welcome to the corporate world. There are arbitrary quotas on promotions, raises, and bonuses.
My manager agrees that it's ridiculous for me to continue being considered a junior when my competency outstrips the role, but for the next year I have to grin and carry on as I wait on his assurances that he will promote me as soon as possible.
Have I mentioned lately how little I trust other people? I enjoy holding power, and I coldly object to being ensnared within the grasp of others. As they say, "trust but verify."
Yet the only way to verify my manager's promise is in its execution, a year from now.
Thus I must continue as I have, working towards a promotion on the individual contributor track that I'm told is certain.
Individual Contributors are Awesome
Before going much further, it may help to understand what individual contributors are:
In brief, individual contributors are skilled workers without direct reports. They are often like self-sufficient one-person teams.
Individual contributors are awesome, and they're valuable for the vaunted "impact factor" they bring with their work. They're responsible for a good portion of the work that gets done within a company. The more there are, the better off the company is.
I look up to the individual contributors I've worked with. They run a wide range of personalities and skill sets, but they all are great at what they do.
The Next Steps to get a Promotion
During my one-on-one with my manager, I asked what the next steps look like for promotion. He explained to me the several factors leading to the much vaunted individual contributor role. I think it's worthwhile to examine each of them in detail.
Interact with other teams
It's not enough to keep my head down within my team, plodding along on projects that get assigned to me.
If I keep that going for too long, when the time comes for promotion my manager would go around and ask important developers "Do you think she's ready for promotion?" and they'll respond "Who?"
No, instead what gets you promoted is working with other teams, and collaborating. You need to demonstrate the ability to work with different people.
Plan and architect
It's also not enough to wait for projects to land in my lap fully formed. The path to seniority requires me to become proactive.
Whilst my manager might give me the initial idea – or he might not – I'm the one who needs to plan out the solution and architect everything. With time and experience that gets faster and more accurate.
Right now though, as a junior? It can take a lot of work for me to figure out the approach to take. I've done it for two projects already, and now I'm looking at a third large standalone project. In truth it's a lot of fun to play around with new languages and frameworks, evaluating which is the best.
Then once there's an architecture in place, I'm also responsible for breaking the design down into chunks for working on.
Self-direct work and managing up
Those workable chunks of design need to be self-directed. I should be keeping myself on schedule, making progress so that I'm never "stuck," and tracking how things go. That way I can simply report to my manager what the overall status is, and go to him when I have problems I need solved.
Self-direction is a key component of managing up: make things easier for your manager, so they don't need to spend their time managing you in tedious ways. You get more results when you handle the tedious for them, and instead use their constrained resources on just the important problems.
Another aspect of self-direction is knowing what order to do work in. Sometimes I prefer doing a minimum-viable product and iterating over it, other times it makes sense to split it up into parallel tracks that I can get assistance with completing.
Drive work to completion
Of course the biggest, most crucial factor to anything is completing the work.
Some projects will flat out fail, or be made redundant. It happens.
What's not acceptable are projects that stall out mostly done, dragging on and wasting time.
That's why one of the biggest factors towards getting my promotion will be how many projects I can drive to completion. A lot of engineering and software work is following up and relentlessly pushing projects onward when they get mired down in the bog.
I've seen where one individual contributor I look up to struggles to drive projects to completion – everything takes months, and seemingly short projects drag out far longer than expected.
Contrast that with the rockstar dev who churns out new projects on the regular. They ended up with a "senior" in their title, whereas the IC who struggled to complete projects lacks that embellishment.
This promotion factor isn't just limited to breaking into the ranks of individual contributorhood – it's important for staying there and progressing further too.
Getting a promotion isn't an overnight occurrence. It's a campaign where you build your case with well-documented actions months in advance.
If I intend to achieve any of my big plans, then I'll need to work on getting promoted. Not just this first promotion out of a junior role, but every subsequent role afterwards too.
That said, promotions aren't for everyone – at a certain inflection point, promotions might just mean more stress and responsibility with too few rewards to counterbalance them.
That aforementioned individual contributor who struggles to complete projects? They're suited to their current position. They don't need to move upwards, because they already enjoy their life and taking on more responsibility would take away from their time to live.
Really, isn't that what financial independence is all about? Finding the sweet spot between time abundance and work?