There is a point in the career of every up and coming engineer at which they will be writing more code than they ever have, and more than they ever will again. Turning this corner is an important milestone in the career of an engineer and facilitating this transition is a key skill for any manager who has a junior engineer on their team.
The initial phase of a new engineers career is one of incremental, and largely linear improvement. The expectations of a new developer, fresh out of college, are low. I expect that an intern, or a brand new developer will have their work picked apart in their first code review. They will need to spend a lot of time under the mentorship of more senior engineers to deliver their work. I expect that they will get the work done, but only if it was well scoped and well understood beforehand. At the very beginning, a new developer is probably a net drag on the team. For a few months, they don’t add so much value through the code they deliver that it outweighs the loss of productivity in code reviews and preprocessing the work to ensure it is tractable for a beginner.
Over time, this improves. The developer learns the conventions of the codebase. They understand the structure of the code and learn to make modifications that live within this structure, rather than cutting against it. They learn the design patterns that solve commonly encountered issues, and through this whole process they stop being a drag, and begin acting as an asset for the team. They no longer look to their more senior peers to break work down for them. Eventually this new developer will reach a point where they are the master of their own work. Their time is entirely allocated to writing code, or figuring out the code that they personally will write. This is the moment of maximum code output – it’s all downhill from here.
To be clear, this is not the moment of maximum value output. There are several ways for this engineer to increase the amount of value they bring to their team, but all of them come at the cost of the time spent coding, and as a result, their sheer volume of output. One approach is to focus on harder problems. Leave the simple data plumbing, or scripting, or dialog box authoring to someone more junior, and start focusing on problems that are harder but more impactful. Build the core algorithm, or the frameworks that make all of that rote work go just a little bit faster. Another approach is to become that senior engineer who is breaking apart the work for the interns and college grads. Do the planning and design so that everyone on the team can execute at their maximum rate of output.
All of these additions of value come at the cost of time spent writing code, and this is a challenging transition for developers who, until this point, have been able to progress by simply doing what they had been doing, but better.
The exact level where a failure to make this turn becomes a blocker for advancement depends on the company. I’ve worked at a few, and in each case, there was one promotion that tended to mark this shift, but the title of that level varied. I’ve found that identifying that level is a key benchmark in developing my understanding for a new companies leveling system. At many companies, there is a handful of promotions that a new engineer can expect as they prove their competence and master the mechanics of development, before hitting a wall when that incremental improvement no longer yield the same result. At others, especially those with relatively few levels, the hurdle comes with the very first promotion.
Helping engineers get through this transition is an important job for management. It, of course, lets your team deliver more value, as the output of each member increases; it allows the members of your team to continue growing, improving and avoiding stagnation, which helps with morale and retention; it lets your team support further growth which helps you grow your own scope of impact. Still, there are some real obstacles to helping someone turn this corner.
The first obstacle is the fear or anxiety that taking time away from writing code will lead to negative consequences. After all, the advancement up to this point has come from devoting an ever increasing amount of energy towards closing tickets, and pushing code to source control. Reclaiming this time feels like a step back. This often sounds like a complaint, that doing code reviews, or attending a design meeting, or diving into the framework is taking time away from work. Helping someone through this is helping them understand that these activities do not stand in the way of work, they are the work.
The second obstacle is that this is a whole new set of skills that your engineer needs to build. Just like it was an investment to bring a new developer into the team, it will be an investment in letting them build the skills that will make them effective at the next level. I’ve never been one to tell people how to manage their own time, but I do find that I need to tell members of my team that I support them in managing their own – that I will not punish them for scaling back their output somewhat, in order to add even more value in another way.
The third obstacle is inertia. Up until this point, your engineer has had a single, well defined path that leads to increased success. After this shift, continuing to double down on increasing the volume of output not only stops leading to improvement, it takes time away from the activities that could. On several occasions, I have found that reviews are a good venue for this conversation. Giving someone a review that says they are exceeding expectations, without an accompanying promotion, sends the message very clearly: “you have arrived, but what got you here will not get you there”
There are a couple of traps I’ve seen in this process, that are worth calling out. The first is when someone wants to turn this corner too quickly. I’m not a fan of “Butt in Seat” time as a measurement for promotion, but a new engineer does need to have a breadth of experiences in order to operate at a higher level, whether as a leader on their team, or as an expert in a particular domain. It’s hard to mentor someone else through shipping a feature if you haven’t worked long enough to see a project land in production. I’ve also seen this be an issue when someone is struggling with their own throughput, but want to take on managing a summer intern, or step up as scrum master. An important part of this progression is that the engineer become sufficiently proficient that they can take on additional responsibility without entirely losing the ability to develop on their own.
Another stumbling block I’ve seen in this process is if the engineer is not motivated by the work that lies beyond cranking out code. Here, I’ve found the best approach is candor. If someone understands the requirements of the next level, and is not interested in striving for those, it is their choice to make, but it should be a choice made with a full understanding of the consequences. Some companies have an “up or out” policy – have they reached a level where coasting is considered acceptable, or will the clock eventually run out? Even without that particular Sword of Damocles hanging above, continual improvement is an expectation of the job – if someone has stagnated in their role, they shouldn’t expect to continue “exceeding expectations,” are they okay with a mediocre review? All of this said, I have also seen many engineers warm up to the concept of continuing to advance if given some time and space – it can also happen over time without a conscious effort. A good engineer will have a hard time avoiding more interesting work as their skill develops.
This career inflection point is certainly not the only twist many of us will find in our careers. The pivot to management is another that is incredibly fraught, but for many who pursue software development this transition towards writing a lower volume of code is one of the first, and least avoidable career pivots they will encounter, and so it can require the most help to navigate.
Leave a Reply