Manager of managers — health checks
This post is part of a series I’m working on called “Manager of managers”, the previous post of which was “Outcomes over output”. In this series, I share my learnings as a manager of managers. Hope to hear from you in the comments! To get all the posts, subscribe here.
I was recently asked whether I follow a framework or a set of metrics to validate how my engineering teams are doing, especially when I’m not managing them directly.
Not having a concise answer was the motivation of this post. So, here’s a first attempt at articulating my internal mental model — we’ll call it the Health Checks (HC) framework.
Similar to how engineers create Datadog monitors for service health alerts, I rely on HCs to know how my teams are doing.
Here’s what my process looks like today:
1. Collect signals from various dashboards, from the ICs and EMs running my teams (EMs), from stakeholders, etc into a single spreadsheet.
2. Update the sheet and review the trajectory of each data point every month.
3. Refocus attention to unhealthy areas.
So far, the spreadsheet has been sufficient, and I’ve been able to use it to make course-corrections along the way (e.g. time-to-merge was ballooning for one of my teams; the diagnosis was inconsistent PR hygiene amongst team members and reviewer bottlenecking).
The up-front effort on piecing this information together has been minimal, and up-keep has costed me ~30–45 minutes per month — a worthwhile investment. I now have a clear picture of how my teams are doing, and can support the EMs running them even better.
In an ideal world, the above process would be fully automated and require minimal effort to collect and synthesize signals (maybe letting LLMs loose into communication products like zoom, slack, gsuite, etc could solve this 🤷🏻♂️). This data would be collected in a dashboard, which would come with alert notifications whenever an area required my attention.
Here’s an example of what such a dashboard would show:
In the above example, the team has an accountability problem. Project delivery has been delayed lately, and will likely impact revenue or NPS next.
Time to roll up your sleeves and start diagnosing the health check.
The learning continues in…
- All chapters — The Engineering Manager’s Pocket Guide
- Chapter 16 — Empowering independent thinking
- Chapter 17 — Managing managers — what changes?
- Chapter 18 — Manager of managers — Leverage is a double-edged sword
- Chapter 19 — Manager of managers — Outcomes over output
- Chapter 20 — Code ownership in flux
- Chapter 21 — Tech debt days
- Chapter 22 — Dumped into the fire — now what?
- Chapter 23 — Manager of managers — health checks
If you have any thoughts or experiences to add, let me know! Respond to this post or let me know on LinkedIn. I’m happy to talk about anything software engineering related.
