September 26, 2015.
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:
The rest of this rambling mess will delve into each of these.
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:
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 guidelines are:
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.)
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 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:
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 course correct.
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:
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:
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.