The Beautiful Mess · Product & Work
TIER 4 Wed, 15 Apr 2026 12:12:42 +0000
I made this little skill if anyone is up for giving it a try.
͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏
| |
---|---|---
| | | Forwarded this email? Subscribe here for more
---
# TBM 416: Investment Stewardship (As Habit)
| | John Cutler
---
| Apr 15
---
|
---
---
| | |
---
| |
---
| |
---
| |
---
| | READ IN APP
---
_I madethis little skill if anyone is up for giving it a try. It is based on some prior posts including TBM 320: From Fluffy Concepts to Concrete Outcomes & Behaviors. I'd love your feedback._
* * *
Every company eventually asks the question: "What are we getting from our engineering investment?" And it almost always goes sideways. There's finger-pointing. There's fear. There's weird math that nobody believes.
People retreat to flow metrics because the real question is terrifying. Or they fixate on near-term revenue contributions and vanity metrics. They reach for benchmarks like "revenue per engineer" without any sense of whether the business models being compared are even remotely similar. They latch onto growth rates and efficiency ratios that obscure the real issue (and are almost certainly lagging). They track time allocation with exact precision on the cost side while hand-waving wildly around the return side. Teams throw up their hands and settle on terrible proxies, or avoid the question entirely.
**The hardest thing to accept is that the rigor is in the care and stewardship, not in the calculation. Yes, there 's math (sometimes) and stats (sometimes). Yes, there's probably some modeling. And a whole lot of qualitative data. But when you actually care about the thing, you answer the question from a very different perspective.**
Understanding the return on your product and engineering investments isn't a calculation you perform. It's a set of behaviors you practice, continuously, over time, that _happen_ to involve some measurement. It shapes where you allocate resources, which teams you invest in and nurture, how you support the people doing the work, what you build, and when to change approaches. Get it wrong and you over-hire into dysfunction, under-invest in the things that compound, and lose the teams worth keeping. Get it _really_ wrong and you lose years.
Here's the problem: by the time most teams finally ask the hard questions, they're standing in the aftermath of years of not asking. And they're expecting an easy answer. Understanding engineering ROI is a habit you had to have been building all along. You can't reverse-engineer it. If you're struggling to answer the question right now, you're almost certainly asking too late.
## You Can't Cold-Start This
Say you wake up one morning with 2,000 engineers at your company, and you try to cold-start answering the question: "So what are all these engineers _worth_? How do they contribute to revenue?"
You've never discussed outcomes. Never tracked leading indicators. Celebrated velocity and throughput as if shipping faster were the same as shipping the right thing. Obsessed over time allocation and cost tracking while hand-waving the value side. Used "revenue per engineer" benchmarks ripped from companies with completely different business models. Celebrated "cooked" business cases. Spreadsheet theatrics. Hired your way around problems instead of solving them. Played dumb games with finance around projects completed and near-term revenue contributions.
**And** _**now**_**you want to cold-start the question of what all of these engineers are "worth"?**
An engineering leader I know had a couple great lines
> 1. Money is generally the easiest part of the equation when it comes to building software. It's very hard to turn $$$ into valuable software and adding people rarely "fixes" a team, and can make things worse by obscuring the actual issue
>
> 2. Any investment requires confidence in the leadership to be a good steward of capital
>
> 3. Asking for more people for an initiative implies everything else on your roadmap is more important and that you can't find other efficiency gains to get the initiative done with the existing team.
>
>
The real issue they point out is increasing the size of the team without fully exploring all potential paths to achieving the mission with the existing team. The same goes with the product: achieving the same effect with less code, less complexity.
Very few companies address "what is the ROI of our team" from a position of diligence, curiosity, and being proactive. They face the question _after_ hiring their way around problems, a weird strategy, a toxic leader, a self-inflicted revenue pinch. And then they're left with a team that's too big, navigating an inefficient system.
**By the time the finger-pointing starts, you rarely get any admission of responsibility.**
There's an idea in economics called the Lucas Critique: when you change the regime, all the historical relationships you estimated under the old regime break down.
> Given that the structure of an econometric model consists of optimal decision rules of economic agents, and that optimal decision rules vary systematically with changes in the structure of series relevant to the decision maker, it follows that any change in policy will systematically alter the structure of econometric models.
You built an entire organization around one set of rules (feature factory, hiring around problems, story points as currency). Now you want to flip to a new regime of fiscal stewardship. But all the relationships, incentives, and data you accumulated were products of the old regime. They don't carry over.
| |
---|---|---
An executive once asked me, "Why can't we be like Amazon?" I responded: you can, if you rewind 20+ years, make operational efficiency a core trait, and keep growing consistently by re-investing profits. You haven't proven that. If your business is literally _built_ on a lack of operational effectiveness and unsustainable growth, you can't decide one day to talk that language. If you've run a feature factory forever without trying to build proof around the causal chain, you're in no position to say "measuring ROI is hard."
_An aside on private equity. Leaders who've been through a PE acquisition often report something surprising: a moment of clarity. For the first time, someone made the model explicit. Here's how much cash the business generates. Here's what we're spending. Here's what we're cutting. Here's the EBITDA target, and here's exactly how every dollar of investment is expected to contribute to it. Reduce costs, optimize margins, eliminate anything that doesn't directly serve the number. It's blunt. It's focused almost entirely on extraction. And many leaders don't agree with it, or think it sells the company's potential short. But they'll also admit: at least someone finally had a clear model. At least the math was honest, even if it was reductive. That should give you pause. If it takes a PE firm showing up with a spreadsheet and a 100-day plan for your organization to experience that kind of clarity, something was deeply broken long before they arrived._
## Why It's Hard (And Why That's the Point)
Part of the reason companies delay this work is that it's genuinely difficult. Most product work is several causal hops away from dollars and cents. You can progressively increase your confidence in the causal chain, but you can never fully eliminate uncertainty. Near-term, tangible outcomes always have a gravitational advantage over things with multiple hops to value.
And people get trapped in a false binary: either you have something overly precise, or nothing at all. A bad proxy (story points as investment theory) is worse than no proxy at all, because it gives you false confidence in a wrong answer. But a good-enough proxy, one that is directionally correct and honestly held, is genuinely valuable. The goal isn't perfect measurement. It's continuously increasing confidence in the core underlying hypotheses.
The difficulty isn't an excuse. It's the reason you need to build the habit early. If you wait until the question is urgent, you have no foundation to stand on.
## What the Habit Actually Looks Like
This is Bayesian updating applied to product. Start with a prior. Collect signals. Update your confidence. You never arrive at certainty; you narrow uncertainty over time. The "precision or nothing" trap is a frequentist fallacy: demanding a p-value when what you need is a posterior that's directionally useful. The teams that get this right treat every quarter as another round of evidence, not an excuse to wait for conclusive proof.
The narrative underpinning a team's "ROI," measured over time, is as much about conviction and signals ("we seem to be doing a lot with a little") as anything scientific. Almost by definition, because of the lag in outcomes. Teams that dominate through usability, or speed, or operational excellence rarely did precise math about that differentiation beforehand. They had _conviction_ , which started to show signals of working. Stubbornness, skill, culture, positive reinforcement.
What I am trying to get at is that the question of "what is the ROI of engineering" or "what do we get from our money" is a set of behaviors, continuously applied. It is a culture of stewardship and thriftiness.
It's a habit of a team constantly asking itself about the leverage of its work. Not "what can we do" but "what _should_ we be doing?" Is this the highest-leverage use of our time? Could we achieve the same outcome with less complexity? Without hiring? Are we solving the right problem, or just the one that landed in our lap? Teams that ask these questions every day, every week, every quarter, compound that discipline over years. They stay lean. They stay functional. When they do add capacity, it's onto a functional setting. Very different from how most companies treat this.
**Stick with that attitude quarter after quarter, year after year, and you get great things. You know you 're lean. You know most of your teams are functional, so you're adding teams onto a functional setting. Very different from how most companies treat this.**
The heuristic of "be incredibly stingy about hiring, but very watchful and supportive of your team" has a lot of merit. It's a forcing function for exploring all paths before throwing bodies at the problem. And remember: "revenue per engineer" is more a statement on the overall business model than on engineering efficiency. It's about the whole system.
And the teams that garden their codebase, investing some portion of their normal time and focus? They supercharge the flywheel. In two years, when their peers might be sitting around struggling to ship anything, this team is still cooking, having fended off the normal entropy.
## The Job
There is no formula. There is no framework you can buy. There is no dashboard that will tell you what your engineers are "worth." There are only behaviors, sustained over time, that earn you the right to claim your investments mattered.
Stewardship. Thriftiness. Conviction held loosely enough to update but firmly enough to act on. Honest conversations with finance that respect the lifecycle and the cost of information. The willingness to narrow uncertainty a little bit, every quarter, rather than demanding certainty or giving up.
**That 's the job. It always has been.**
The good news: there's no better time than the present to start. You can begin today.
1. Identify leading indicators. What early signals would tell you whether your investments are working before the lagging financial results show up?
2. Build a model for how the business works. Not a perfect model. A useful one. How do the levers product can move (reasonably) actually contribute to revenue, retention, and cost structure?
3. Start regularly assessing those leading indicators. Every quarter, revisit your priors. Update your confidence. Treat it as a practice, not an audit.
4. Apply real discipline around hiring. Before adding headcount, ask: have we exhausted all ideas on how to fix existing issues to make this possible with who we have? Apply discipline around team formation and funding. If you don't have this, start! It isn't about teams proving why they should exist--it is about at least having a reasonable hypothesis and some evidence (or a plan to get some evidence).
5. Have honest conversations with finance. Not the dumb game of time allocation, projects completed, and made-up business cases. Or oversimplified lifecycle models. Establish a reasonable model together that accepts the lag of outcomes in product, that accepts a portfolio of bets that are different shapes, and that accepts teams are operating in different modes that need specific funding models.
## Related Posts
| | |
#### TBM 390: Governance by Principle, Not by Template
---
| | John Cutler| | *
---|---|---
| November 23, 2025
| | Read full story
---
| | |
#### TBM 352: Funding, Planning, and Context
---
| | John Cutler| | *
---|---|---
| April 20, 2025
| | Read full story
---
| | |
#### TBM 6/52: Inputs First. Bets Next
---
| | John Cutler| | *
---|---|---
| February 10, 2022
| | Read full story
---
| | |
#### TBM 377: Time Allocation ≠ Capacity Allocation
---
| | John Cutler| | *
---|---|---
| September 5, 2025
| | Read full story
---
You're currently a free subscriber to The Beautiful Mess. For the full experience, upgrade your subscription.
Upgrade to paid
---
| | | Like
---
| | Comment
---
| | Restack
---
(C) 2026 John Cutler
548 Market Street PMB 72296, San Francisco, CA 94104
Unsubscribe