Becoming A Manager of Engineering Managers: What You Need To Know

Culture Teams & Collaboration
Kelly Gallamore

By: Kelly Gallamore |

Culture Teams & Collaboration

2 Min. Read

Try now

In October Charity Majors joined Ian Nowland [VP | Eng | Datadog] and Rich Archibold [Sr Dir | Eng | Intercom] in a live panel discussion for Gitprime. Hosted by Marcus Blankenship, Becoming a Manager of Engineering Managers covers key points about the differences between managing engineers and managing people who manage engineers. Each panelist describes how they got into this mess in the first place made it to this point in their careers (SPOILER – it wasn’t the stereotypical direct, smooth path depicted on TV, for any of them.)

“You sort of learn this tap dance of like giving people freedom, giving people feedback, but no one tells you how to do this.” - Ian Nowland, Datadog

After each panelist shares how they became mangers of managers, Marcus walks them through:

  • what it’s like to manage people who are most definitely more experienced
  • how it differs from managing just one team
  • how to give managers effective feedback
  • and if it’s so goshdarn hard, why are you doing it in the first place?

Charity, Ian, and Rich give accessible points of view about ending up where they did not expect. In the webinar, Ian highlights into the importance of relationship capital in his role, how to earn it and how to use it wisely. Rich gifts us several actionable pointers and a magic formula for successfully managing managers. Charity offers a few twists on usual thinking that can pinpoint who will be a successful manager and who will fall flat.

“They’re thoughtful and they can unpack it from first principles and... explore. People who pattern match and jump to conclusions, and then get very upset when that doesn’t work out are not going to do well in [the] role.” - Charity Majors, Honeycomb

Register to get Becoming a Manager of Engineering Managers on-demand. It’s a great commute listen for folks who are actively working their way up, and for folks who want to know if the people they report to are actually good managers. Thanks to Marcus for being an excellent host, and thanks to GitPrime for inviting us to participate with such knowledgeable guests.

Looking to level up your ability to manage production? Sign up for a free Honeycomb trial!

x icon linkedin icon youtube icon facebook icon
Don’t forget to share!
Kelly Gallamore

Kelly Gallamore

Related posts

Determining a CoPE’s Efficacy—and Everything After

Nick Travaglini |

Determining a CoPE’s Efficacy—and Everything After

As discussed in the first article in this series, a Center of Production Excellence (CoPE) is a more or less formal, provisional subsystem within an organization. Its purpose is to act from within to change that organization so that it’s more capable of achieving production excellence. The series has, to date, focused mainly on how best to construct such a subsystem and what activities it should pursue. In this concluding post, however, I want to return to the point of a CoPE, discuss signs of success, and evaluate the impacts it’s having.

Culture Teams & Collaboration
A CoPE’s Duty: Indexing on Prod

Nick Travaglini |

A CoPE’s Duty: Indexing on Prod

Building a center of production excellence (CoPE) starts with indexing on production. Here’s why. Odds are that a software engineer today is really focused on one place: pre-prod. Short for “pre-production,” this is slang for an environment where software code operates in a prototype phase of its development lifecycle. Common sense would have one believe that this is a safe space, a workbench of sorts, where problems can be found and remediated. Then, once engineers are reasonably certain everything’s working properly, they advance it to a matching environment called production, where the code behaves like it did in pre-prod and it merely needs to be managed by an operations team. That story is a comforting lie.

Culture Software Engineering
A CoPE’s Guide to Alert Management

Nick Travaglini |

A CoPE’s Guide to Alert Management

Alerts are a perennial topic, and a CoPE will need to engage with them. The bounds of this problem space are formed by two types of alerts:  Reactive alerts (in Honeycomb, we call these Triggers): They are alerts that fire after some event, like crossing a pre-determined boundary.  Proactive alerts (Burn Alerts based on Honeycomb’s SLO feature): These give notice before crossing a threshold; in the case of SLOs, that means before failing to meet the stated objective.

Culture Software Engineering