Engineering Career Trajectory
I was talking to a good friend of mine about career paths, and where their focus generally falls as they grow in their career - as I did, I thought about my own experiences and the companies with which I've interviewed. In particular, there have been some that I avoided purely because their expectations didn't align with my own for the role I was pursuing.
That lead me to make the above graph - it's not necessarily to capture where all our time is spent, but more about the types of problems that align to our career goals. This isn't prescriptive scientific fact - but an approach to explaining the differences in responsibilities as one grows in their career. The time spent in each role may be accelerated, it may not be linear - and depending on the size of the organization they are with, the exact percentage breakdowns may shift up or down.
As the first few years of our career is really about learning coding as a skilled trade. We're refining our skills and becoming better at designing solutions. We're also maturing in our real-world understanding of the problem space. We learn good and bad habits - we learn about the pressures the cause us to cut corners and take on Technical Debt (a symptom of a larger problem I call Systems Debt).
As we grow beyond the Junior level, and mature into Intermediates we naturally become more interested in deeper questions - not just around architecture and software design, but the overall maintainability and sustainability of our codebase. We gain a fundamental understanding of why the "best practices" we had as Juniors are actually best practices, and we learn more about when it's acceptable to deviate from them.
We also start seeing the Team and the general process as Software Development as a system. We grow more critical of things that create challenges for us to deliver effectively, and we look for solutions to improving the overall delivery pipeline. This leads us to not only mature as coders but shifts our thinking towards Team Leads/Manager roles. The change doesn't happen over-night - but fundamentally we start to see how Managing a team wrestles with a lot of similar problems that Coding can (more on this in a moment...).
As Seniors, we are not only interested in coding - but the broader architectural questions: Software Architecture, Infrastructure Architecture, 3rd Party Dependencies, Automations. We're writing much less code - and, sadly, the time we do have to write code goes by faster because we've generally mastered the domain. So, while we don't write code, we continue to broaden our perspective of what "Engineering" is. How is the system fault-tolerant, how does it scale? How do the technologies, hardware, and even the team play a role in our SDLC?
As we start asking these questions, we (may) find ourselves on the Manager's path. It's not for everyone, but I'd also argue many Senior Engineers think like managers even if they don't execute like one. They'll certainly have opinions on the overall team - including questions around the Junior team member's career paths and growth opportunities. While we don't code anymore (and we should not code anymore) we still exercise it by asking important questions: How do we best allocate resources, and design the team for growth? What work do we prioritize? Where do we cut corners and how do we make up for them? How do we pay down the technical debt?
Importantly: Managers should not code, and their own Managers should not expect them to. If a manager is coding, this means something is fundamentally wrong with the team's structure: they are under-allocated, they are under-skilled, or the Manager has trust issues. If a manager is coding, then no one is Managing, and that begins to ignore some fundamental questions that lead to an unsustainable buildup of Systems Debt. Managers who code is a red flag - and you should keep an eye out for attrition, burnout, or - at the very least - growing frustrations.
Finally, as Managers grow into Sr. Managers, Directors and on - the focus shifts to the broadest views: The business objectives and the budgetary constraints. The people, processes and policies are all important factors, but just like the Junior coder seeks to understand the how and the what behind the codebase, the Director not only drives the how and the what of the Engineering teams, but must also understand the why behind the business, and the who behind the budget ("Who" as in "who is paying for this...")
The thing to keep in mind is the theme to all these questions is a fundamental desire to tackle problems with well-engineered solutions. A lot of coders mourn the loss of writing code, which is understandable. It's rewarding to produce something tangible. And while a CTO or Director may not operate at the delivery/working level and won't directly produce a tangible product, they are building systems. If they're good at it, they're building functioning systems.
At the end of the day, whether it's Software, a Team, or a System - they're all about taking inputs and transforming them to outputs.
