I'm Brett Slatkin and this is where I write about programming and related topics. You can contact me here or view my projects.

11 June 2014

Cats and dogs living together

My current project is first time I've managed other people directly. But I'm still a software engineer, so my responsibilities are:

  1. Write code
  2. Design systems
  3. Lead our engineering team to get things done

#3 is the "engineering management" part of my job. The gist of engineering management:

  • Ask the right questions
  • Identify risks
  • Prioritize the team's efforts to address these risks
  • Escalate issues beyond your control

It's meetings with your team, meetings with other managers, and planning.

There is another type of engineering manager at Google that only does #3. These folks are pure managers, not software engineers. They are not responsible for direct technical contributions (even though many still write code and participate in design). Their only goal is leading their team. Most Directors and VPs have this role. Many large teams are led by pure engineering managers because building software at scale is primarily a social problem, not a technical one.

What's interesting is what happens in an emergency.

When something goes wrong I want to write code to solve the problem because that's what I do. Engineering managers want to schedule meetings because communication is what they do. There's nothing wrong with this, but it causes a conflict like cats and dogs. Dogs bow when they want to play. Cats think dogs are posturing to pounce and are being aggressive. So cats and dogs often have trouble getting along. Similarly, engineering managers schedule meetings with programmers when there's something wrong. Programmers want to be writing code, etc, so they see these meetings as a waste of precious time, interrupting progress towards a solution.

Neither group is "right", it's just the difference between the roles. You need both roles to create the healthy, constructive tension that makes an engineering organization function properly at scale. But I hadn't really appreciated how much this difference in priorities matters until I experienced the friction first-hand in a recent episode.

Here are some suggestions I've come up with to make it easier going forward.


  • Be clear about why you want to avoid meetings (i.e., you're debugging)
  • Have more meetings with pure managers to enable them do their jobs


  • Maximize engineers' time by having scalable meetings instead of one-on-ones
  • Minimize interruptions by preferring asynchronous channels like bug trackers and mailing lists
© 2009-2024 Brett Slatkin