All right — you are an engineering manager, and that is exciting. You have built a great team, you are accomplishing business goals, and you’re driving technical initiatives. Great success! Wash, rinse, repeat, ad infinitum. Good?
Nope, that’s not enough – not if you or anyone on your team wants their career to grow. The fact that you’re a manager suggests you do. And I’d bet that most (all?) of your team members want to grow too. What should they do for growth in their career? One option: they can wait for you to get hit by a bus, so your role opens up.
The Technical Track
Nearly everyone wants to grow in their career. But of course, not every engineer wants to be a manager — most don’t — for all the right reasons! (It’s a completely different kind of job; It’s super stressful; Ugh! All those meetings!) They want to stay on the technical track. Thus, it is your job, and your company’s responsibility, to ensure there is a path for them to grow their technical career.
This technical track needs to have a job ladder — a series of steps that articulate career, impact, and skills growth. It is imperative that the steps of the ladder aren’t just “do the same thing for longer to earn the next level.” These different steps of the technical ladder are different jobs with different requirements. This last point is critical — otherwise, it is not growth — it is aging.
Here is an example role ladder that I have used, and the material difference between the roles:
- Engineer: Contributes to the team’s delivery
- Senior Engineer: Owns projects and their outcomes
- Lead Engineer: Drives a group of engineers to deliver business value
- Principal Engineer: Works across the business to define and deliver large-scale initiatives
- Distinguished Engineer: Applies deep business understanding and technical expertise to predict and address major future business needs
I’ve further articulated different axes of skills that are required by these levels — see the spreadsheet linked here:
Here is the current state of this ladder:
Feel free to copy/use/evolve the above technical track job ladder if it is helpful to you.
Side note: that bottom row of the ladder is a delicate one. I am very opposed to using “years of experience” to dictate the role a person is in, since we all know that impact and age are not correlated. But there are two reasons to have that row: A) If you are introducing a ladder like this to your org, this content might help your HR department to calibrate your ladder to their global levels system; B) This helps enunciate the point that moving through the levels takes time.
At the end of the day, you need to articulate to your team exactly what the levels of growth are, and what the differences/requirements are for each of them. Different companies of various sizes use all sorts of different schemes — some larger companies have dozens of levels. But whatever ladder you use, there are consistent aspects that support an engineer’s growth: increased technical breadth, increased ownership and accountability, increased business interactions and impact.
One corollary to a technical track ladder is that the farther you go up the ladder, the less percentage of time you are writing code. Perhaps this is obvious, but it is worth mentioning. Lead Engineers need to do more code reviews, Principal Engineers are in a lot of meetings, etc. All this takes time away from directly creating software. However: I don’t like a world where the folks towards the top of the technical ladder are doing zero coding. Over time that can yield a divergence between your org’s high-level architectures and the actual software that is being written to implement them.
Once you have your ladder established, it becomes much more clear to yourself, to your leadership, and to your team how engineers can progress along the ladder. This ensures that promotions aren’t a subjective thing — it is based on an objective, multi-faceted assessment of impact and potential.
The important part of a promotion is that it changes the expectations on the engineer. When Sally, a great high-velocity Senior Engineer, becomes a Lead Engineer, the expectation is that she leads her team to deliver that same high velocity across multiple people. The skills to be a great Lead Engineer are not the same as the skills to be a great Senior Engineer (often a superset, but certainly not the same). Therein lies the growth opportunity for Sally — she needs to develop those new skills.
This kind of skills growth is represented in the job ladder linked above. See the example to the left — this is the Communication axis, and you can see the difference in expectations between a Senior and Lead roles. In that Lead box are a bunch of quick summary statements, but each of these is an area of skills that deserves in-depth evaluation, assessment, and growth. And it is a much higher bar than for a Senior Engineer.
Now a key axiom in life is “you get the job when you’re already doing the job.” In other words, you get the promotion to a new role when you are already doing (at least some aspects of) that role. So Sally needs to already have shown some fluencies and aspirations toward the Lead Engineer role — this demonstrates to her manager and to the org that she is ready for that promotion. So, you, as the manager, need to help foster opportunities for each of your direct reports to explore the fluencies of their next role.
What does that mean? It means you need to routinely think about each of your team members, and where they are in their career. You need to identify what role is next for them, and align with them on what skills they need to grow to achieve that role. You need to convey to them that this process is not one of days and weeks — it takes time to learn a new skill, and even more time to put it in to practice successfully enough to demonstrate its consistently high business value.
There is a natural reaction to presenting a detailed job ladder like the above: people will look at a particular role and say “I’m already doing that. Can I be promoted now?” As we discussed above, it’s not that easy. Doing something once or twice or across a few projects is not the intent here. Learning a new skill is the process of becoming sufficiently adept at it, such that it becomes ingrained in how you operate. This can take years to develop. Meanwhile, ambitious folks like us want this stuff to happen quickly. Certainly, there are some skills that are quick to learn and put into practice. But to build the full arsenal of competencies you need for the next role is not an overnight process. It takes effort and practice and focus — it takes time.
And your job as a manager is to walk that path with your team member. To encourage them, guide them, assess them, and critique them. You need to be strict — since you must maintain a high bar of success — and you need to motivate the team member to help them see the positive outcomes of all this work.
The best way to curate this evolution is to write down a plan: to create a Growth Plan for your team member. I typically commit these as a document that the team member and I can align on. Usually the plan articulates a list of objectives — business goals that need to be met, technical goals and their success criteria, and personal growth goals and the impact that we want to see as they are achieved. Then, the Growth Plan enunciates the payoff for all these successes: new title, new role, comp changes, etc.
By committing this to paper, it becomes very clear to the team member what they need to do to achieve the career growth they want. As their manager, you are there to support and guide them — but all of the effort and growth and commitment needs to come from them. Promotions are not something that just happens after a certain amount of time elapses — they are achieved through the focus, hard work, and growth of the team member.
What does all this mean for me as a manager?
You need your team to grow in skills and impact — because that is the only way you can grow as a manager. If your team was stagnant, you would never be able to demonstrate to the business that you are ready for the next stage of your own career. Conversely, as you and your team demonstrate that you are successfully delivering an ever-increasing scope, it becomes easy for you to level up.
But for you to be able to handle more, the same premise applies — you need your team to take on more, to consequently allow you to take on more. For example, if you personally are authoring all the technical designs for your team, then you won’t have the time to expand your impact in some other area. You need to grow Senior Engineers under you to drive those projects. Later on as your team expands, you’ll need to grow Lead Engineers to lead subteams within your group. And so on — supporting and empowering growth of your team members yields opportunities for your own growth.
Good luck, and happy growing!
Eng Mgmt series by Matthew Vanderzee
- eng mgmt ep1: Should I become an Engineering Manager?
- eng mgmt ep2: What should I do today?
- eng mgmt ep3: Making tech things happen
- eng mgmt ep4: Goal-driven development
- eng mgmt ep5: Recruit great engineers or die tryin’
- eng mgmt ep6: Growth-oriented leadership
- eng mgmt ep7: Am I a good manager?
- eng mgmt ep8: So you want to be a Director (Quiz Show edition)