No Country for Young Engineers 2

Part 2: Rockets go BRRR

In Part 1 of our series, we critically examined the commonly cited benefits of mixed seniority engineering teams and debunked these claims.

Now, in Part 2, we shift our focus to the diverging career trajectories of junior engineers and their impact on engineering teams. We will also introduce the characteristics of AI tools and how they relate to engineering.

In Part 3, we will explore in-depth how AI is transforming engineering roles and affecting career outcomes across all levels.

Finally, in Part 4, we will offer strategic considerations for hiring and assembling robust engineering teams for the future.

Let's dive into the career trajectories of junior engineers in our baseline, pre-AI model.

Outcomes

Having explored the individual benefits and costs associated with junior engineers, let's now pull our view outward, and look at the overall impact of junior engineers as they develop over their careers.

We will rework a term from the Gartner hype cycle, the “Plateau of Productivity” to frame this discussion.

An engineer above this plateau is a net positive asset to the team and organization. They provide positive net value in the form of features, bug fixes, tests, documentation, architecture, and other software engineering outputs that are in excess of their costs.

An engineer is below the Plateau of Productivity if that engineer’s net value to the engineering team and the organization is negative. Whatever positive value they create is less than the costs they incur in the form of compensation, other developers’ time, bugs, unintended technical debt, throwaway solutions, etc.

Note that the plateau is constant while an engineer’s growth is not. Nearly all engineers start off below the plateau, as some time and money went into the process of recruiting, hiring processes, and training. Even after that, more is needed to onboard, gain familiarity in the company code and processes, hone their engineering acumen, and develop the ability to independently design and deliver solutions of increasing complexity as they progressively increase their value.

It is also worth noting as we will discuss subsequently this view is over the career of an individual engineer. If a junior engineer starts out below the plateau and remains there for most of their tenure before leaving your company for another one, the net value of that engineer to your organization is still a net negative even if they end up a net positive to their next employer.

In our model, developers fall into one of four categories. The estimates for the prevalence of each group in the overall pool of junior engineer hires are rough buckets based on my experience and discussions with peers.

Net Losses (70%)

These engineers fail to reach the Plateau of Productivity within an acceptable time frame. The return on investment is negative, as they do not attain the productivity levels necessary to justify their costs, ultimately costing the organization more than they contribute over their tenure. This category constitutes the majority of new hires, where the resource allocation does not yield the desired results.

Overall, these engineers never reach the level of productivity necessary to provide value, so whether you hire them as their first job or a later job, it is always a losing proposition, albeit slightly less so if you acquire them later.

Grinders (20%)

Grinders surpass the initial Plateau of Productivity but encounter a subsequent plateau in their career growth. As journeymen or mid-level engineers, they deliver reliable and competent work commensurate with their compensation, capable of handling tasks of moderate complexity. However, their potential for further development and advancement is notably capped.

Overall, depending on where in their career you acquire individuals and the exact value they provide you will be looking at a small nominal gain or loss but will more or less be getting what you pay for.

Continuous Learners (10%)

Continuous Learners make up a diverse segment who are the powerhouse of your team. Whether they are versatile product engineers, deep specialists, technical polymaths, or simply individuals with exceptional clarity and consistency in their work, their career trajectory is characterized by steady or exponential growth.

Overall, this is the sweet spot in terms of engineers who you want to acquire. They epitomize the Pareto Principle upside, delivering value that far exceeds their cost, and significantly enhancing the enterprise's capabilities. They will greatly exceed the Plateau of Productivity and continue growing from there, meaning that if you have one of these engineers early in their career you will generate a positive return, and even if you get them later at a higher cost they will continue to grow and increase the value you derive from them.

🚀 The Sir Not-appearing-in-this-film (<1%)

Pick your superlative. This rarefied group forms the pinnacle of the talent pyramid. While we won’t dwell too much on this group, it’s important to note that the distribution of talent in software engineering has a long tail and just as there is a top 10% of engineers with disproportionate value, there’s a top 1% and a top 0.1% who provide even more outsized value.

Overall, you can’t really target or build your team around these outliers, but if you have one, don’t lose them!

Analysis

We have thoroughly evaluated the prevailing arguments for mixed-experience engineering teams and found them wanting. The addition of junior engineers to a team will, more often than not, be detrimental draining resources and productivity rather than providing the anticipated infusion of vitality and innovation. Adding junior engineers is a losing proposition in terms of productivity, team dynamics, and business outcomes.

Junior engineers, much like the glittering facades of Vegas, promise quick wins and big rewards. However, the reality is a more pedestrian, with most punters leaving empty-handed, disillusioned after exhausting their resources.

This raises a critical question: given the challenges discussed, why do companies continue to hire junior engineers? Reflecting on our previous metaphor, it seems we are an inherently optimistic species, quick to blame bad luck and eager for another roll of the dice. There's a commendable, albeit idealistic, impulse within engineering leadership to nurture and develop the next generation. More cynically, in many organizations, transitioning into management is the only viable path for career advancement for individual contributors (ICs). Thus, expanding one’s team, increasing headcount and direct reports can become a strategy for climbing the corporate ladder and empire building. Adding more peers doesn’t feather one’s own nest.

Classic organizational dynamics often exacerbate this issue, with senior leadership detached from engineering realities and perpetually in search of a magic formula to maximize output with minimal cost; hope springs eternal for “young, hungry, scrappy, go-getters”.

On the flip side, overburdened engineers may grasp at any support, however insufficient. When you’re on fire, a glass of water won’t help much, but you’re unlikely to turn it down.

Characteristics of AI Tools

Now that we’ve established our baseline scenario, let’s briefly introduce some characteristics of AI tools so that in the next part of our series we can discuss the impact of these tools as they relate to developer outcomes and explore how the integration of LLMs and other AI tools may alter our perspective on this issue. While I don’t consider LLMs or AI agents as replacements for developers today, I believe their influence distinctly sharpens the diverging career outcomes engineers face, based on the attributes of these technologies.

• Summarizing Novel Domains: LLMs are adept at synthesizing and summarizing information from new and diverse fields, making them ideal when baseline user knowledge is limited.

• Style Transfer: LLMs excel in adapting and transferring styles across different domains, demonstrating flexibility in handling diverse content forms.

• Automating Repetitive Tasks: LLMs perform well in automating numerous mundane and repetitive tasks, streamlining processes that previously required significant manual input.

• Optimizing for Known Problems: The effectiveness of LLMs is maximized when dealing with common scenarios, particularly those well-represented in the training datasets or easily extrapolated from existing data.

• Input/Output Quality Correlation: The quality of LLM output is directly correlated with the quality of input, underscoring the importance of precise and thorough user input.

• “Chasing your Tail” Risk: Engaging with LLMs without independent domain expertise can end up with you participating in the Dodo's caucus race¹, running in circles, achieving nothing, and merely having the illusion of progress while being misled by the AI’s confabulations and stochastic parroting.

• Need for Critical Oversight: Effective use of LLMs demands fastidious review and assertive editorial intervention, ensuring that outputs meet standards for accuracy, quality, and are sufficiently refined for practical application and subsequent iteration.

Our next piece will look into how AI technologies might intensify or alleviate the challenges we’ve outlined facing engineers at different stages of growth. And, to end on a more positive note, the final part of this series will discuss recommendations for effective hiring in this evolving landscape.

Stay tuned!

Believe I am too pessimistic (or optimistic) in my assessment of engineering outcomes? Do you have a different value metric that you believe I overlooked? Did I miss some inherent characteristic of current LLMs or AI? Your feedback is valued and appreciated!

1. https://www.alice-in-wonderland.net/resources/chapters-script/alices-adventures-in-wonderland/chapter-3/