No Country for Young Engineers 1
Part 1: With apologies to Cormac McCarthy
My hesitance to write this piece stems from a fervent wish to avoid creating another typical hyperbolic, bad-natured, punching down Medium article. Yet, despite my reservations, the raincloud must come before the rainbow, a positive companion piece awaits.
The debate about how to build and structure modern engineering teams is long-running, dating back to at least 1975 with the publication of Fred Brooks’ The Mythical Man Month. We will review the current and evolving state of the conversation and provide our own analysis, focusing on the effects and outcomes of junior engineers. Starting with the present landscape, we will expand our discussion to address how recent advances in Language Learning Models (LLMs) and Artificial Intelligence (AI) are reshaping these debates. These advancements add substantial weight to the arguments we’ll explore. To conclude our contributions to this topic we’ll close with recommendations on hiring and building teams. With this technical context in mind, let's outline the series:
Part 1: We'll review the commonly-claimed benefits of mixed engineering teams, refine our terminology, and critique these purported benefits.
Part 2: Our focus will shift to the career trajectories of junior engineers in our baseline model and we’ll introduce the characteristics of AI tools.
Part 3: We’ll dig into how AI is transforming engineering roles and affecting career outcomes across all levels.
Part 4: We conclude with strategic considerations for hiring and assembling robust engineering teams for the future.
Join me as we dive into this exploration and analysis of engineering teams— and don’t hesitate to share your thoughts and experiences along the way.
Review of Purported Benefits
The mixing of junior and senior engineers is frequently championed within companies and online, with numerous articles extolling the purported benefits. To summarize these benefits1234:
Fresh Blood, Fresh Ideas: Junior engineers can offer new insights and challenge established norms, leading to innovative solutions.
Incentive for Simplicity: Simplifying code for juniors can improve code quality for everyone.
Growth Opportunities: Seniors can develop leadership skills through mentoring, while juniors can rapidly upskill.
Diversity of Thought: A mix of experience levels promotes a more dynamic problem-solving environment.
Cost-Effectiveness: Hiring juniors can be more cost-efficient while investing in future talent.
Action-Oriented: Juniors often bring a "just do it" attitude that can complement the cautious planning of senior engineers.
Faster Hiring: Expanding the candidate pool to include juniors can speed up the recruitment process.
Refine Terminology
Before diving into each argument, let's clarify the terminology used.
Junior Engineers: Typically these are newcomers to the field, emerging from academic backgrounds, bootcamps, or self-teaching, with limited industry experience. A more precise definition focuses on their work's scope: juniors engage in tasks that are less ambiguous and require mentorship, oversight and guidance from more senior engineers.
Senior Engineers: This term encompasses a broader spectrum of abilities. It is only loosely correlated with the traditional metric of years of experience, instead focusing on depth in knowledge, insight, and skill; qualities not strictly tied to duration of employment in the field. As a fine engineer I know would often say, “🥔 is 🥔” (potato is potato). Experience does not always equate to talent. Seniority here signifies more than longevity; it's about the breadth and depth of engineering acumen and ability to independently design and deliver solutions.
You might wonder about the whereabouts of the true Scottish engineers. This is a fair critique, seniority, as defined here, hinges on capability rather than years. It's an oversimplification to agglomerate all senior engineers into a single category, one we will eventually rectify, but, for now, let’s focus on the broad junior / senior divide.
Caveats and mea culpas complete, let’s go ahead and dismiss these claims of mixed-experience engineering teams one by one.
Critiques of Benefits
Fresh Blood, Fresh Ideas
Today's new graduates often arrive with identikit tools and skill sets. True innovation, barring the rare work of staggering genius, emerges from seasoned experience and the iterative evolution through adaptation of ideas.
This is evident in the realm of art; Picasso’s extensive period of active work, while not the sole factor, was a significant contributor to the variety of styles he could explore, develop, and refine. Similarly, in software engineering, groundbreaking libraries, architectures, and approaches are typically the domain of seasoned engineers and "greybeards". Innovation is the result of experience, knowledge, and repeated experimentation.
Incentive for Simplicity
Watching Gordon Ramsay filet a fish or construct the elements of a complex dish with superhuman speed and quality vividly illustrates that simplicity and economy are fruits of experience, not youth. Similarly, in software engineering, achieving simplicity is often the result of years spent refining the relevant skills. These include reading and writing code, developing, and building complex systems, and iterating on these systems while receiving empirical feedback.
Setting aside the disingenuous seniors who manufacture complexity to feather their own nests or proclaim their usefulness into the void, true simplicity in software emerges directly from experience. Simplicity is the winnowing of the essential from the superfluous, a nigh impossible task without the benefit of experience to aid in discernment.
Experience cultivates parsimony; the knowledge of where to cut scope and complexity, how to identify what can be changed, and understand the options at hand. It's the ability to see the forest for the trees. Young engineers often struggle with this because they haven't yet traversed the forest themselves.
Reflecting on my own career, over-engineering and an inability to develop and recognize parsimonious solutions was a continual struggle as a young engineer, and remains an eternal nemesis especially when facing a novel domain.
Growth Opportunities
This topic invariably prompts a wry smile. I hold, perhaps with a measure of bias, that promoting a standout engineer to oversee less experienced engineers usually results in a negative return on investment. The ideal scenario, where a senior engineer excels in both their original and new managerial roles, is typically a product of sheer luck or Herculean effort.
I've found that mentorship is most potent as "primus inter pares," devoid of the satrapal trappings of management. Managers, burdened by the necessity of tending those engineers who are below or slightly above the plateau of productivity, find themselves mired in either remedial oversight or buried beneath a mountain of administrative tasks. Conversely, the most capable engineers thrive under strategic guidance, needing only occasional nudges towards pragmatism to balance their ambitions and idealism, rather than constant managerial oversight.
The peril for engineers transitioning into management is the gradual erosion of their coding and design skills, which wither without the nurture of continual practice and engagement. Aspiring managers risk becoming the very archetypes they intended to avoid: a non-coding architect or a manager veiled in the "fog of war," struggling to make informed decisions without the requisite understanding.
On the other hand, a team of experienced engineers is an ideal composition. All members can bring strategic thinking, tactical technical skills, and can form an effective and flexible unit where the best ideas can thrive and all members can carry their own weight.
Diversity of Thought
My experience has shown that the most profound diversity of thought is contributed by experienced engineers, whose varied career trajectories and personal histories endow them with an expansive range of perspectives. Whereas young engineers often exhibit the narrow dogmatism of their training, their senior counterparts possess an intuitive sense, a nose, for when it’s necessary to pivot or reassess their approach, the smell.
Juniors adhere too closely too received wisdom, putting their nose to the grindstone pushing forward on tasks impervious to the warning signs. Some of the worst outcomes of my career came from juniors’ unquestioning acceptance of my proposed solutions from a distance or my own failure to be sufficiently close to the junior’s problem, code, or proposal to be able to guide their efforts towards a parsimonious solution.
This speaks as well to the difficult jump to management previously mentioned. Seniors, equipped with both the depth of experience and the confidence it breeds, are adept at scrutinizing proposals, adapting to the protean landscape, assimilating new information, and making informed decisions to navigate engineering efforts to successful outcomes.
Cost-Effectiveness
The dearth of engineers championing this view speaks volumes. Like the mythical man month, this construct becomes an undying legend of El Dorado, kept alive by the enthusiasm and wishful thinking of business leaders seeking cost-cutting panaceas.
Right out of the gate, the investment in hiring and training are substantial, incurring significant, variable upfront costs in anticipation of future savings. The concept of a “golden goose” junior engineer who can be paid $100k instead of the $250k a senior would command is enticing but rests on fundamentally flawed logic.
Interview Time Sink: Utilizing senior engineers to vet, interview, and train junior engineers diminishes their productivity and diverts them away from productive engineering work.
Training Demands: Once hired, junior engineers, like fledglings not yet ready to leave the nest and fend for themselves, require continuous guidance, training, and oversight from senior staff. This not only strains seniors’ ability to contribute effectively but also impairs overall team velocity.
Uncertainty in Talent Acquisition: Identifying high-potential junior engineers is notoriously challenging. Even the largest tech companies, with access to top candidate pipelines and extensive hiring resources, often fail to accurately assess potential despite their rigorous and refined hiring processes. Smaller firms face even greater hurdles: they contend with limited, picked-over talent pools, fewer resources, and inconsistent hiring practices. Even if you can spot a needle in a haystack, you still have to sift through a lot of chaff.
Transient Upside: The junior engineers worth retaining often swiftly outgrow their initial roles. As they become more skilled, they seek higher salaries or new opportunities, quickly eroding the initial cost benefits of their hire. This rapid advancement means that any financial gains from their lower starting salaries are soon negated by the need to raise their compensation or risk losing them, and your investment in their growth, to the market. The worm has turned on the era of exploiting junior engineers' initial enthusiasm and lack of experience; today's young engineers are increasingly adept at navigating the job market and hopping ship to maximize their value.
Action-Oriented
Another topic to raise a wistful smile. My personal mantra “speed through quality” reflects my philosophy. While a “Bias for Action” to use Amazon’s terminology is a valuable mindset to cultivate, the impetuous endeavors of juniors often result in pitfalls such as developing footguns, misunderstanding how to balance speed with quality, skipping essential testing for speed, or introducing unintended technical debt.
For complex and sizable tasks, I concur with the author of How Big Things Get Done that a more measured approach is more effective. Senior engineers typically exhibit a ravenous bias for action when the consequences of their actions are clear, yet they also demonstrate hard-earned caution when the outcome is uncertain. If anything, senior engineers may need to temper their impulse to dive straight into crafting solutions.
It’s hard to know when you should navigate swiftly through the familiar, well-trod paths and when you should step gingerly through an unknown landscape, senses alert to hidden dangers. Discernment in when to bias towards action often comes only through experience.
Faster Hiring
There's an old saw that you should always date before you marry, a principle that applies aptly to hiring as well. In rare cases, such as during periods of explosive growth, you might feel compelled to simply add warm bodies. However, unless you’re Russia in 1942, this is rarely advisable.
We've previously discussed the inefficiencies of rapidly hiring junior staff under Cost Effectiveness. Rapid hiring is not a goal in itself; indeed, trying to increase hiring velocity is like throwing gasoline on the fire devouring your team’s productivity.
The Mythical Man Month famously notes that adding additional engineers reduces short-term velocity and increases churn. The harm compounds as hiring accelerates. The blind lead the blind, with inexperienced, recent hires left to train and acclimate new hires, causing both groups to flounder. Meanwhile, senior engineers suffer death by a thousand cuts due to the demands of rapid training, hiring, and managing an increasingly unbalanced team.
Rapid hiring is like a slot junkie’s solution to money troubles, constantly feeding the beast, watching your hard-earned resources dwindle, all while hoping against hope that the next pull will hit the jackpot and solve everything.
Conclusion
We have critically examined the commonly cited benefits of mixed seniority engineering teams and debunked these claims. We will now turn our attention to the impact of these dynamics on the career trajectories of junior engineers. Subsequently, we will explore the impact of AI on the engineering profession with a particular focus on outcomes and career trajectories. Before finally turning to strategies for hiring and assembling strong engineering teams.
Have you had a different experience with junior engineers? Do you think I have spent my time tilting at straw men? Do you have insights on how junior engineers add value that are not captured here? Your feedback is valued and appreciated!
Among all the definitions and theories around what constitutes professional expertise, the ones that I find most persuasive note that proficiencies, knowledge, and/or years of experience are neither sufficient or predictive, though all are required. (The importance of both talent and cultural conditioning remain an open question, perhaps dependent upon field and/or project.)
What's also essential is deliberately reflective practice. That's the expertise that you're both manifesting and cultivating through these serial observations. It will be interesting to see what best practices they lead you to recommend.