Adding Value as an Engineering Manager

management (207)

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:

  1. working on the system (rather than in the system),
  2. nurturing the team,
  3. guiding execution,
  4. managing communication.

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:

  1. Measure what your team is spending most of your time on,
  2. Identify the place you’re spending the majority of your time,
  3. Experiment with a way to reduce the time you’re spending in that area,
  4. Goto 1.

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:

  1. 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),
  2. Approaches to measurement which require more work by your team usually fail (“too busy to think”),
  3. Manual measurement can work as long as there is a fixed period measured in days rather than weeks,
  4. 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),
  5. 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:

  1. hiring new members into your team,
  2. creating opporunities for your current team to grow,
  3. 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.

Guiding Execution

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:

  1. Your team is working on something that is both valuable and perceived to be valuable,
  2. 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 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.
  7. 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.

Managing Communication

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:

  1. 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?
  2. 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.
  3. Talk with your team about what contributions you are focused on communicating, and why you are focused on those areas of contribution.
  4. 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).
  5. 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.
  6. 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.

Ending Thoughts

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.