The two-year rule
Junior developers on average have a reputation for leaving their first role after about two years, and this reputation is…somewhat unfair.
There is a kernel of truth to it: the digital tech industry is crowded at the bottom, and landing that first role is so important that it’s usually worth it to take an “accept first, ask questions later” approach to job offers.
However….
I mentor many software engineers throughout their careers, and when I talk to junior and intermediate developers who are thinking of moving on from their first employer, far and away the two most common reasons they cite are:
Their learning has plateaued.
Their career progression is unclear or stalled.
In third place, we have values misalignment and culture conflicts – i.e., they had to take what they could get for their first role – but it’s almost always accompanied by one of the above two points.
This is good news because it means that if your junior developers aren’t sticking around, it is absolutely within your power to fix this problem.
In this post, we’re going to tackle this problem from three angles:
Start with a learning plan for each developer that balances their interests, your goals for them, and the organisation’s needs.
Take notes and look for trends, so that you can provide strategic guidance, not just tactical feedback.
Continually adapt as reality asserts itself, so that the developer always has high-level goals to work toward.
Mentoring junior developers means creating structure
Junior developers are every bit as good at (and as hungry for) learning and growth as their more senior teammates. However, because they are so new to their discipline, they don’t yet have sufficient context to plan out their learning over the medium-to-long-term. Without guidance, they will soon run out of low-hanging fruit…and that’s when they start looking around for juicier opportunities at other organisations.
This is where you come in. You can provide that structure and direction for their learning, so that they are continually growing, they are aware of the progress they are making, and most importantly, they can see even more challenges and opportunities waiting in their future.
Start with a learning plan
To kick things off, during your next one-to-one with each of your junior developers, design the first iteration of their learning plan by discussing and balancing these three factors:
What do they want to learn? Even if they might not initially have a strong understanding of what they want to learn, it will help you get a general idea of where their interests lie, and it will plant the seed that managing their professional development is a shared responsibility.
What do you want them to learn? This will be based on how you want their career progression to go. It could involve mapping a path towards intermediate status, or it might include specialisations such as devops, cybersecurity, test automation, etc.
What do the team and the organisation need them to learn? This will be based on the tech stack, cross-functionality gaps, upcoming migrations, etc.
You’ve likely clocked that all of this changes over time, so don’t worry about getting the learning plan perfect at this point. Just focus on putting together a first iteration that feels about right, knowing that you’ll be adapting it as the developer makes progress and as circumstances change.
Take notes and look for trends
For most managers and mentors, supporting a junior developer in achieving their learning goals takes the form of weekly or fortnightly one-to-one meetings, sometimes accompanied by pair programming and code review.
These are excellent tactical tools. Checking in week-to-week gives you opportunities to make observations and provide immediate feedback, but these need to be supplemented with a month-to-month view, so that you can also give the developer strategic guidance.
How is the developer tracking overall? Are there specific challenges or concepts that they tend to struggle with? Are they gaining momentum, or are they getting stuck? Are they still on-track, or do they need to pivot?
To answer these questions, you need to be able to retain and compare your observations over many weeks and months. For a busy manager with an entire team to look after, this is simply too much information to keep mental track of.
Which is why you should absolutely delegate that task to a notepad or digital file:
During each mentoring session with a developer (one-to-one, pair programming, etc.), keep a physical or digital notepad handy, and take high-level notes about their progress, habits, and obstacles.
Once a month, take a moment before each one-to-one to go back over the past month or two of notes for that developer, and look for trends. Use your discoveries to inform the agenda for the one-to-one meeting.
Your developers will notice and begin to anticipate these monthly “strategic one-to-ones”, and they will quickly become the most valuable conversations you have with them.
Continually adapt as reality asserts itself
Just like software, learning plans are never finished.1 During your monthly strategic one-to-ones with each developer, revisit the learning plan, recognise their progress, and see if a new iteration is needed. This helps you ensure they always have high-level goals that they’re working towards.
Remember that an effective learning plan strikes the right balance between:
What the developer wants to learn.
What you want them to learn.
What the team and organisation need them to learn.
And don’t forget that keeping track of things is just as important a skill for you as it is for your developers. Make sure that you’re taking notes and looking for trends so that you can provide strategic guidance, not just tactical feedback.
Before you know it, you’ll have a hard time keeping junior developers…because you’ll be regularly promoting them into intermediate developers!
And they always have bugs.