Engineering Leadership, Scaling Yourself, and Building Bench
The most important skill a leader must learn is how to scale themselves.
In a growing company, a team always starts at a reasonable size.
We can assume the team performs well and ships impactful work in a necessary part of the company! But as I always say, “the reward for doing a good job is always more work.”
The team receives more headcount. Everyone is happy! A bigger team means more people at lunch! Now the team looks like this, which is still reasonable.
But… as happens in startups or growth companies… business conditions have a positive change: the company closes a raise, increases in paying customers, etc. As a result, more headcount opens on the team, and now the team looks like this.
This situation is not sustainable. Either the team will slow down, or the team will not be able to grow its mandate any further. Therefore, the engineering leader must pull themselves out of this trap by building bench.
Building Bench
Building bench involves understanding the strengths and weaknesses on the team, investing in team member growth intentionally, and building out your own replacement.
Let’s walk through an example.
Manager (Mgr) A has a team with 10 engineers. I subscribe to the Amazon Two-Pizza Rule, and 10 engineers are effectively two teams. The team size is fundamentally too big. Mgr A is overwhelmed. They have no time to think, build strategy, invest in growth, collaborate with other teams, or plan because he spends their day keeping the team moving. As a result, the team begins to glitch out, and the team’s performance becomes a little soggy bottom.
Mgr A must figure out a way out of this situation or die. Mgr A must build their bench.
Eisenhower Squares
How does Mgr A figure out where to start? First, Mgr A performs a fun little to-do and prioritizing technique on their time called an Eisenhower Square (or Eisenhower Matrix).
The process is simple:
- Write down everything you do in a month: shipping blog posts, attending meetings, holding 1:1s, attending architectural reviews, etc.
- Figure out every task specific to your skillset — work only you can do.
- List up to 10 items from the generated list in each box.
- Start cutting tasks and prioritizing.
- Important/Urgent tasks only Mgr A can do — writing multi-team strategy, discussing with high-level stakeholders, informing leadership, etc.
- Important/Not Urgent tasks are typically collaboration, stakeholder, or project status meetings. They’re important! These meetings should happen! They’re not urgent because they can occur on a planned schedule.
- Not-Important/Urgent tasks are typically important for the team to complete but don’t require Mgr A’s specific skill set. Anyone can do them — status reporting, transcribing meeting notes, updating blog posts, etc.
- Not-Important/Not-Urgent tasks are likely cluttering Mgr A’s entire schedule and should stop immediately.
Mgr A can delegate everything in the “Important” but “Not Urgent” or the “Urgent” but “Not Important’ square to someone in training!
Growth Opportunities
Mgr A starts with tech lead B because that’s the obvious place to start. Tech Lead B is already leading people on the team. B is a deep expert in a technical topic. They have about as much interest in leading people as a full-time job as a potato sack and have informed Mgr A of this inclination at least a dozen times. Mgr A acknowledges this and has to look for other places to grow people. Let the tech lead lead! Usually, this is where managers get stuck, but that’s because managers aren’t being creative.
Engineer C always stands up to schedule meetings, organize projects, and drive work to completion. Acknowledging this tendency, Mgr A offers C to take on all the “Important”/”Not Urgent” and “Urgent”/”Not Important” tasks.
- Important/Not Urgent C can drive these meetings and collaborations. It’s a growth opportunity for C and a way for Mgr A to clear their calendar.
- Not-Important/Urgent These are great for a manager-in-training, but Mgr A doesn’t need to do them. Neither can C! C delegate them, but C should be responsible for their completion.
Once C is running well with these tasks, understanding that C must trade off these tasks for engineering and code tasks, and C is comfortable, then it is time to discuss C’s conversion to leadership. This process may take up to a year until C is proficient in operating the team before C can take on people successfully — but preferably, if C is willing, this takes only a few months.
Note: Taking on people is always the last step and the most important. Screwing up a meeting is one thing. Screwing up humans is another. The team’s integrity always comes first. And, If after a year, C isn’t operating the team naturally, consider hiring. See below.
If C accepts, the team now looks like this. Of course, C will need mentoring and support for up to a year before becoming 100% independent. But that’s ok! We’re investing in scale, C’s career, and the team’s overall health.
Also, during this process, Mgr A must make a concerted effort to keep Team Lead B looped into the process so they aren’t hit with surprises! Mgr A wants Team Lead B’s full support with C’s growth since soon they’ll be partners.
If C is successful, Mgr A can repeat this process with Engineer D.
Reminder!
Engineering management is a different fundamental job than pure engineering which requires different skills! Growing bench will not work without an intentional investment in developing new skills and an investment in training! Don’t think it will happen with no effort on your own. Be prepared to put all your time into this project.
Another Caveat!
When splitting two teams, ensure both have sufficient roles and responsibilities or scope to keep all those engineers productive and the new manager successful! For example, if the team already has 10 engineers, then the team has a scope for 10 engineers. It is up to Mgr A to split that scope when splitting the team and ensure the two new teams have clear mandates and no cross-cutting concerns.
Growth vs. Hiring
If time is of the essence, or as we grow the team, we find no suitable successor, we can always split the team and hire from the outside to fill these new manager roles. We often do hire from the outside if no options materialize! But, that does involve bringing in someone from the outside who needs to onboard onto the space to lead the team successfully and gives up on the investment and growth of the team, which is a miss. It also injects risk into the team by bringing in an unknown quantity.
Remember: every new hire is a risk.
We grow bench if:
- The talent exists on the team, and…
- The desire exists on the team, and…
- We have time to invest in team member growth and can invest in mentoring.
We hire from the outside if:
- The talent does not exist on the team, or..
- No one on the team has desire, or…
- We need to close a role quickly and cannot invest in team member growth (aka, 2 weeks).
If we can invest in our people, we always should invest in our people. Investing in someone else’s career is always an excellent use of time and effort and pays significant dividends. Do eet.
Fun Fact
My whole “thing” is I don’t believe in technology unless I’ve built it myself, by hand, going uphill, both ways, in driving snow. I wanted to learn how cryptography worked, so I taught myself how to build streaming ciphers using Crypto++. I wanted to learn how the LXC/Docker containerization worked, so I built containers myself from namespaces and control groups.
Thus I am embarking on the insane journey of working my way through ~700 pages of basic deep learning techniques with Keras and become extremely dangerous but probably not useful.
I’ve worked ~halfway through Deep Learning in Python 2nd Edition so far. I’ve gotten 100% up to speed on everything I knew from 3 years ago, and now I’m starting to dig into time series predictions and transformers and very much “new stuff.” My brain is, as they say, melting.
