My introduction to engineering management was the same as most: six months into a new job–after a series of layoffs and talent departure–I
somehow became the longest tenured software engineer and so wise in my endless naivete, I became the engineering manager of a
rocketship careening towards a ravenous blackhole. From that ignominious start, I’ve composed a long enough track record of screwups and misfires to get a rough sense
of the field, which I’ll endeavour to share here before I change my mind about all of it.
The most common failure mode for new engineering managers is spending too much of their time
on technical work. There are some tricks you can use to help with this–try scheduling one day a week
only working on management work–but I think the real issue here is that many managers don’t
believe that managers can really contribute much of value to their team. Most engineering managers
were engineers, and most of their exposure to engineering management was probably pretty mediocre,
so it’s easy to understand where that perspective comes from, but managers can absolutely be useful.
(My thoughts to follow, but also take a look at Slack for another perspective.)
An engineering manager’s most valuable contributions are:
working on the system (rather than in the system),
nurturing the team,
The rest of this rambling mess will delve into each of these.
Working on the System, Not in the System
The core lesson of The E-Myth Revisisted is as a business owner you need to always
ensure you’re working on the business rather than in the business. I think this is also the
fundamental tenent of being an effective manager.
Success as a manager is knowing you can walk away tomorrow and feel confident that your team
will remain effective without you personally running it (more on this thread in Good to Great),
which means day to day operation can’t rely on your personal judgement. Does this mean you shouldn’t
work hard as a manager? Absolutely not–there are periods of change when you will need to overhaul
your team or organization to adapt it to new circumstances and constraints–but if you are always
working extremely hard, then your organization is probably too dependent on you.
Working on the system is a fairly simple iterative loop:
Measure what your team is spending most of your time on,
Identify the place you’re spending the majority of your time,
Experiment with a way to reduce the time you’re spending in that area,
The hard parts are measuring where your team is spending time, and
picking good experiments for reducing the time you’re spending on it.
You get better at both as you make repeated attempts, but a few
Automated instrumentation and measure is almost always the best choice (since you have to pick either
complete dirty data or incomplete clean data, you might as well pick the one which takes up less of your team’s time),
Approaches to measurement which require more work by your team usually fail (“too busy to think”),
Manual measurement can work as long as there is a fixed period measured in days rather than weeks,
You can reduce the cost of experimentation by creating a better interface to your team
(this can be an API which other teams call, a UI which guides requesters, or
moving people into filing tickets instead of walkup requests),
Experiments which require other teams to change their behavior are very slow to generate feedback,
it’s much easier to iterate on experiments internally.
This simple iteration process is the fundamental act of management, and as you get good at
it, it will allow you to accomplish truly amazing things through series of incremental improvements.
(Off all the types of experiments you’ll conduct, organizational changes are one of the most
painful and disruptive. On the other hand, they are probably the highest impact,
alongside adding/changing/removing managers. I won’t do them justice here, but in general I think
organizational changes are underutilized.)
Nurturing the Team
When you are maintaining the system you’re in the process of building,
the highest leverage activity is ensuring your team is composed of the
right people who work well together.
There are three parts to this:
hiring new members into your team,
creating opporunities for your current team to grow,
ensuring that everyone on your team is a good fit.
Hiring is hard, and can’t be covered indepth here, but nothing will transform
your team more dramatically than an amazing new hire. (The inverse is also true.)
Growing your existing team is important as well, for both retention as well as ensuring
that your team is growing behind you to make sure you’re never indispensible to its continued
success. Philosophically, I believe much more in growing a team than in training a team:
you can plant some ideas in people (most often through being an example of those values
or ideas), but I believe great people are sufficiently skeptical of ideas that they have
to learn from their own experience and can only benefit from a fraction of your experience
(a coworker once likened management to having children, where you tell them the right way
to do something, and then they do it their way anyway…). In this world of self-guided learning,
the best thing you can do to grow your team is to give them ever-increasing stretch assignments
with more latitude, and room for creativity.
I have to admit I’m pretty far off the norm on this one, and many others feel that more
traditional training sessions (internal or external), conferences, pair programming and
project days (hackathons, etc) are extremely valuable. Ultimately, I think it’s about
matching the learning opportunity with the learning style of the learner.
Finally, the other major contribution you can make to nurturing your team
is to make sure that everyone on your team should be on your team, this is also
sometimes called performance management.
Having the wrong people on your team will cause more damage than anything else, and
defining who is “right” is entirely situational. As a company grows, often you’ll have
to kill your heroes, who were recently
valuable contributors on your team but who can’t give up control and allow the
team to scale.
Letting people go is always painful, but at least in my small sample, I’ve never seen
anyone who was less happy after leaving, being let go or letting someone go. The situation
is generally toxic by that time. However, mastery here is identifying when a situation
isn’t working before it gets toxic, and then trying something different: someone who is
struggling may flourish with a different manager, a different role or even working on
a different project. You have to draw the line somewhere, but barring a deep fundamental
performance problem or an ethical violation, that line should probably be after two or
three failed attempts.
Ultimately you and your team are being judged on your contribution to the company,
and you generate that value by successfully executing on useful projects. There are
two major requirements for success here:
Your team is working on something that is both valuable and perceived to be valuable,
Your team is making significant progress, relative to expectations, on their projects.
When you begin leading a team–and periodically afterwards–you need to go over your team’s
portfolio of projects and think about which of them are no longer pursuing. It’s extremely
common for teams to be working on projects which used to make sense but no longer do, or projects which
make sense to the team but have no possible customers, or projects which are competing with
other internal teams to solve a problem where only one solution will “win”.
Pruning projects which your organization will never appreciate is the quickest way to add value.
Some projects are extremely valuable, but are misaligned because the team designing and building
them doesn’t understand the broader social or technical context of the company. Realigning these
projects to fit into the organization’s other projects, teams and value structure is also extremely
high impact. A good example would be a company which doesn’t value operational or system administration
work, but where you can repackage a handful of scripts into a service with a UI, and then reframe the
contribution as building automation software instead of “administration.” The work hasn’t changed
meaningfully, but you have reframed the contribution into something the company values.
Once you’ve established that your projects are infact valuable, the next endeavour is to help
guide those projects to success without making yourself the bottleneck on your team’s execution.
Over time, I’ve come to think of this in terms of introducing the appropriate controls to prevent
your over-involvement in details while also ensuring you are aware of problems earlier enough to
What is appropriate depends heavily on your team size and structure, but here are some of the controls
which I use or have used in the past, ordered by those appropriate for smaller teams through those
appropriate for larger organizations:
code reviews: reviewing code diffs is a great way to get a sense of who is doing what and how the
members of your team interact with each other. Most appropriate for a team lead or a line manager.
daily standups: having your entire team give brief status updates on what they are working on is
helpful to identify projects spinning in place or team members who need more direction. One of the
signs to watch for is teams which have no mutual awareness of what others are working on.
1:1s: meeting with each member of your team weekly or bi-weekly is a great opportunity to get feedback
from your team, if they trust you. Otherwise they tend to turn into status update sessions.
product requirements: a clear set of product requirements, and frequent checking to see if the
requirements are being met, is a great abstraction between the team and management, giving both
sides freedom to contribute without stepping on each others toes too frequently.
status reports: as your organization grows larger, having team leads create weekly status reports
for broad consumption across your organization is a useful mechanism to ensure that teams become aware
of each other’s work, and also to identify teams or projects which are not making much progress
(the smell here is teams which can’t identify work to report on each week, or which say the same
thing every week).
skip level 1:1s: as your team gets larger, you’ll increasingly lose touch with the members of your team who
are not your direct reports. You have to trust your line managers to run their teams, but you also owe it
to those teams to have a safety mechanism to detect a manager or project which has gone of the rails, and
that safety mechanism is skip level 1:1s, where you meet with your report’s reports. These will allow you
to develop an honest relationship deeper into your extended team.
quarterly roadmaps: if no plan survives engagement with the enemy, then certainly no roadmap survives
first contact with reality. However, they’re still a great alignment tool to make sure both you and your
team have the same priorities and share an understand of a project’s value.
While there are no silver bullets,
some composition of these techniques should give you enough visibility into your team’s execution, while
also giving your team enough room to also innovate and lead beyond your contribution.
One of the hardest parts of management is establishing effective communication
from your team to the larger organization, and from the larger organization back
down to your team. Almost no one does this well, not because they don’t try, but
there is some sort of fundamental barriers to successful communication which defy
both good intention and valiant effort.
However, even making an honest attempt will set you and your team apart.
To get started, my approach is:
Figure out your team’s identity and how you want others to perceive that identity.
Are you a software engineering team doing infrastructure?
Are you a systems engineering team? Are you a product team? Are you mastering a few things or are you
a broad team which is integration contributions from other teams into a cohesive package?
Identify the three ways your team is adding the most value to the organization, and a way to
frame your contributions
to be consistent with your team’s identity.
Talk with your team about what contributions you are focused on communicating, and why you are
focused on those areas of contribution.
Create a consistent cadence for your communication. Send out weekly or biweekly updates with
what your team is working on, framed to be consistent with your identity, and focusing on what
your readers are interested in (not focused on what you are interested in).
Have periodic 1:1s with other leaders across the organization and talk about your major areas
you are focused on, as well as learning about the major areas they are focused on.
Gather the initiatives from other teams into a tracking document somewhere, and talk through
those projects with your team to create more awareness of what other teams are working on.
If you spend about twenty percent of your time working on communication, then you’ll probably
hit diminishing returns, but most people who are willing to listen will have heard you, and
most people who aren’t willing won’t, which is probably about the best you can ask for unless
you’re able to engage 1:1 with everyone in your the company.
This is really just the beginning of ways that you can add value as an engineering
manager–you have to find the management style which suits
you, personally–but hopefully it gives you a few ideas to think on. If I had written this
three years ago, I would have written something very different, and I’m certain if I were to
write this three years from now, I would write something entirely different again, but for
now this seems about right.