Manager of managers — Outcomes over output

AAKF...utwG

15 Feb 2024

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 point “there’s no A for effort” (credit: 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’:

Business delivered 30% more reports to customers last month.
Customers can now place bulks 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.

Output does matter though, because it’s cumulative 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 so you had a direct and 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 receiving designs, you may not know that KTLO cost is starting to climb.
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 reviewing PRs, metric dashboards, sprint reports, etc.

And when you 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?

What if you’re not pushing towards the right objective? What if there hasn’t been enough business discovery done? What if the GTM plan is missing and no target audience has been defined?

A slight tangent…
I learned this lesson 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 (like crossing Reddit x Instagram) — I will someday write more about lessons learned from building Aura.

See? Even when you have high output, it only counts if you achieve the outcome. We didn’t when we built Aura. And you should keep that in mind the next time you reflect on how you’re doing. Your stakeholders need you to deliver “outcomes”, not “output”.