Mailbag: Resources for Engineering Directors.

management (221), mailbag (12)

Recently I got an interesting question from someone looking for resources for Engineering Directors, as distinct from general engineering management:

I was wondering if you’ve written any posts geared towards engineering directors or have any recs for posts others have written I’m mainly looking for advice on how to manage projects from two layers away. How do I give managers creative freedom to manage however they like while also stressing the importance of deadlines?

A few books that initially came to mind on the more general topic of “stuff written for Directors rather than line managers” were Team Topologies, the later sections of The Manager’s Path, and my own An Elegant Puzzle.

However, none of those books are particularly focused on the second, more specific part of the question: how do you foster execution on teams you indirectly manage?

There are three interesting pieces to think about here:

  1. Understand what’s happening on indirectly managed teams
  2. Adding things necessary for execution
  3. Remove things getting in the way of execution

What’s actually happening?

Tools I’ve found useful here:

  • Business Review Template – these templates are great, and force folks to really analyze what’s happening on their team. They set you up, as a Director, to actually diagnose what’s happening on a team. They also give you a great chance to realign a team that’s going a bit sideways in their execution or interpretation of what really matters
  • Monthly or quarterly roadmap review – what’s actually happening y’all, and what are the delivery dates? (This is tricky, easy to end up in The Build Trap.)
  • Skip-levels – this matters even more as your organization grows beyond managing one layer of managers, but even with just one layer you’ll often find that individual contributors and managers have a very different perspective on things

Adding missing pieces

Necessary pieces that are often missing:

  • Strategy can be unclear, unstated, or unknown. If folks don’t know why a project matters and how it connects to other projects, it’s hard to move it forward. Some resources on strategy: Writing engineering strategy from Staff Engineer, links in Engineering Strategy section of StaffEng’s reading materials, Richard Rumelt’s Good Strategy/Bad Strategy
  • Urgency to complete the project. The one sentence version of driving urgency is: folks work urgently in areas that leadership says are important, connect to the strategy, and pay active attention to. This goes wrong a lot, though, whether it’s micromanagement or the forever unpopular, “do it because the CEO said so.” Probably worth a dedicated article of its own
  • Cross-functional priority to complete the project. Particularly, the cross-functional priority to bypass permission gates, e.g. someone on Legal team to navigate contract language on a new feature.
  • Capacity to sustain execution over the course of many projects, specifically adding headcount budget or equivalently reducing expectations of work volume. Importantly, this is looking at getting the team to a steady state of staffing for its ongoing workload, not trying to change staffing strategy for a single, specific project. Teams are more durable than projects, inverting the two leaves you, and your team, with a mess

Remove things getting in the way

Things that sometimes need to get removed:

  • Excessive visibility / misaligned priorities – sometimes there are simply too many leaders providing direction to a team, e.g. three or four lightly misaligned executives driving a focal project, and you can help clean that up by being a trusted intermediate
  • Thrashing priorities – if a team is shifting back and forth on focus or approach, figure out what’s causing that thrash and work to remove it. This is more often than not too many, somewhat misaligned, strategies, rather than the total absence of any strategy
  • Fixation on resources – sometimes a team has convinced itself that it will be given permission to blamelessly fail as long as they say that they want more headcount staffing. This is a judgment call for you to make, but personally I’ve seen a good number of teams spend more time convincing themselves they need headcount without spending time trying to find a faster, shorter path to solve the problem with the team they have. Even if you’re evaluating increasing headcount, get the team out of the perspective of “waiting for staffing”
  • Weak or negative cross-team or cross-functional relationships – sometimes a team isn’t working well with necessary partner teams for a given project, and you can debug and start the process of cleaning that up

Anyway, lots more to think about here, but these are the first key points from my perspective!