Manager of managers — Outcomes over output
This post is part of a new series I’m working on called “Manager of managers”, the first post of which started with “What changes?”. Over the coming weeks I’ll share more deep dives from my learnings and observations, and would love to hear from you in the comments!
As you grow senior in your role as an engineering leader a shift starts occurring. You start being measured on the ‘outcomes’ you deliver, rather than the ‘output’.
At this level “there’s no A for effort” (Henry Ward; CEO of Carta), and rightly so since you are now responsible for a squad of people, whose work needs to solve business problems. In turn, these folks depend on your leadership to drive impact and keep receiving executive sponsorship.
Here’s what I mean by ‘outcomes’:
- More customers used the reports that were generated last month.
- Customers can now place bulk orders themselves instead of calling support.
- Revenue increased by 20% last quarter.
- Customers are happy and NPS is >90.
Notice how there’s no reference to how these outcomes are achieved. The “how” falls in the camp of “output”. As a senior engineering leader, you are expected to be proficient at that, and is part of why you were selected to be a senior leader.
Of course, output does matter as it ladders up to the outcome you’re trying to achieve. Interestingly, now that you manage people running teams, what changes is how you monitor that output.
Keeping pulse
Previously, you were in the room where the sausage was being made, and you had a tight feedback loop. You could decide when to cut corners and take on tech debt, when to skip adding tests, when to shuffle people around to support a struggling area.
While managing indirectly you have to keep pulse on output in a totally different way. You may not directly hear about roadblocks, you may not know that engineering started development without designs, you may not know that the KTLO cost has been steadily climbing over the last few sprints.
You have lost direct touch.
I have found a few techniques helpful in keeping me plugged in: participating in demos, architecture reviews, product reviews, etc. Other ways I’ve kept up are through PR reviews, metric dashboards, sprint reports, 1:1s, release notes, etc.
Doing the above, you will inevitably find a deficiency. What you don’t want to do is undercut the people running your teams. You want to help, but not fix things yourself. Doing so, would certainly steal away coaching opportunities from those managers.
So why aren’t you measured on output?
You deliver X features every sprint. You have high velocity and can tackle Y story points each sprint. You get done before the target date. Sounds great, right?
Well, what if you’re not pushing towards the right objective? What if the objective hasn’t been vetted by business? What if the GTM plan is missing and a target audience hasn’t been clearly defined?
Even when you have high output, it only counts if you achieve the outcome, which you, as a senior leader, have influence on.
I learned this the hard way…
While building helloaura.com (“Aura” was later shut down) my team produced a lot, but didn’t achieve the outcome of building a sticky social/commerce experience. We built an iOS app that allowed users to drop media on a map (like Snap Maps). Then we pivoted to building an augmented reality experience (similar to Facebook spaces). Finally, we built a scrolly-list social media product (a cross of Reddit x Instagram) — I will someday write more about lessons learned from building Aura.
The next time you reflect on how you’re doing, keep in mind that your stakeholders need you to deliver “outcomes”, not “output”. Cheers!
The learning continues in…
- All chapters — The Engineering Manager’s Pocket Guide
- Chapter 12 — Defining “done” in software projects
- Chapter 13 — Continuous Team Advocacy
- Chapter 14 — Cadences — engineering manager time horizons
- Chapter 15 — Beyond the Feature Factory
- 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
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.
