Weighing Options via ROI

Engineering Capacity Is the Currency

A company has exactly one truly scarce resource, and it is not money. Money can be raised. Servers can be rented. The thing that cannot be conjured on demand is the focused attention of engineers who understand your system. Every roadmap meeting, every "quick favor," every Slack thread that ends in "can we just add a toggle for this?" is someone spending that currency — usually without looking at the price tag.

The core CTO mental move is a double translation. First: translate every proposal, no matter how it arrives, into engineer-weeks. Not story points, not t-shirt sizes — engineer-weeks, because engineer-weeks convert directly into salary dollars and forgone alternatives. Second: translate every promised outcome into one of three things — money (revenue gained or cost avoided), risk reduced (outages, churn, security incidents), or optionality created (doors this opens later). If a proposal cannot be expressed in those terms, it is not yet a proposal. It is a vibe.

The basic formula is not sophisticated:

• ROI = (value created − cost) / cost
• Cost = engineer-weeks × fully-loaded weekly cost of an engineer
• Value = money, risk reduction, or optionality — annualized

Here is the part people miss: every input to that formula is an estimate, and most of your estimates will be wrong by 2x in one direction or another. That does not make the exercise useless. It changes what the exercise is for. You are not computing ROI to get a precise number. You are computing it to rank options. Rankings are robust to estimation error in a way that point estimates are not: if project A looks 8x better than project B, you can be wrong by 2x on every input and A still wins. If they look roughly tied, the honest answer is "these are tied, so decide on strategy or speed of learning, not on fake decimal places."

Let us make it concrete. Assume a fully-loaded engineer costs about $4,000 per week. Three projects are competing for the next quarter:

Notice what the table does. The infra migration — the project engineers are most excited about — does not survive contact with arithmetic unless someone can put a number on "flexibility." Sometimes they can! Maybe the current platform caps you at a scale you will hit in nine months, and the migration is really an insurance policy against a $2M outage-driven churn event. Fine — then write that down and put a probability on it. The discipline is not "never do infra work." The discipline is: infra work competes in the same currency as everything else, and its advocates must speak that currency.

Also notice that the admin automation — small, boring, unglamorous — ranks first. This is the normal shape of the world. A CTO who only funds exciting projects is running a film festival, not an engineering org.

Opportunity Cost: What You Didn't Build

"It only took two weeks" is never a complete sentence. The real cost of building X is not the two weeks — it is the Y that those same people did not build during those two weeks. Salary is the visible cost; the invisible cost is the best forgone alternative, and the invisible cost is almost always larger.

Two weeks of your best engineer on a low-value pet feature costs the company two weeks of that engineer on your highest-value project. If the highest-value project returns $50k per eng-week and the pet feature returns $2k per eng-week, the "cheap two-week feature" just cost you roughly $96k in forgone value. Nobody wrote a check, so nobody noticed. Opportunity cost is the silent line item on every engineering invoice.

The practical tool here is the default-alternative test. Before approving any project, name the specific best alternative use of the same people over the same period, and compare against that — not against zero. The comparison set must always include the humblest option of all: do nothing new, and sell more of what already exists. Ship nothing; spend the quarter on reliability, performance, and helping sales close. For a surprising number of proposed projects, "do nothing and sell harder" wins the comparison, which tells you the proposal was never about ROI in the first place.

• Wrong question: "Is this feature worth two weeks?" (Almost everything clears this bar. That is the problem.)
• Right question: "Is this feature worth more than the best other thing these two engineers could do with the same two weeks?"

This is also why headcount does not fix prioritization. Doubling the team doubles the currency in circulation; it does not change the fact that every unit of it still has a best use and many worse uses. Companies that cannot rank at 10 engineers cannot rank at 100 — they just burn opportunity cost at 10x the rate, with better catering.

Cost of Delay: Urgency Is a Number

Most teams treat urgency as an emotional state — whoever sounds most stressed in the planning meeting wins. Don Reinertsen's contribution, in The Principles of Product Development Flow, was to insist that urgency is a number: the cost of delay is simply the value you forfeit per unit of time the thing remains unshipped. A feature worth $520k per year has a cost of delay of $10k per week. Every week it sits in the backlog, someone is quietly setting $10k on fire. Once you price delay, the arguments change character: instead of "marketing says this is urgent," you get "this loses $10k a week and that one loses $2k a week," and the meeting gets shorter.

Cost of delay leads directly to the most counterintuitive scheduling insight in the book: weighted shortest job first. When projects compete for the same team, order them by value divided by duration, not by value. Big valuable projects feel like they should go first because they are worth the most. But a big project blocks the pipe for a long time, and everything waiting behind it accrues its own delay cost the entire while.

Worked example. One team, three candidate projects:

Value ordering says do A first: it is worth three times either alternative. But run the delay math. If A goes first, B waits 12 weeks (~$96k of delay cost) and C waits 14 (~$126k). If B and C go first, A waits only 5 weeks (~$115k) — roughly the same delay pain — but B and C start paying out months earlier, and you bank two shipped, de-risked wins before committing three months to the big bet. Sequencing B, C, then A delivers more total value from the identical team doing the identical work. Nothing about the projects changed. Only the order did. That is why CTOs obsess over sequencing: it is free money that most organizations leave on the table because "biggest first" feels responsible.

One-Way Doors and Two-Way Doors

Jeff Bezos gave operators the most useful two-bucket taxonomy in management: some decisions are two-way doors — walk through, dislike what you find, walk back out — and some are one-way doors, where walking back is impossible or ruinously expensive. The entire art is matching your decision process to the door type. Two-way doors deserve speed and delegation: decide with ~70% of the information you wish you had, push the decision to the person closest to the work, and treat a wrong call as a cheap lesson. One-way doors deserve slow, senior, deliberate scrutiny, because you will live with them for years.

In engineering, the doors sort roughly like this:

Organizations fail at this in two symmetrical ways. The first is treating everything as a one-way door: every button color gets a design review, every library choice gets an architecture council, and the company achieves consensus paralysis — maximum deliberation applied to minimum stakes. The second is treating everything as a two-way door: "let's just ship it and iterate" applied to a data model, and eighteen months later half the engineering org is doing a live schema migration on a table with two hundred million rows, which is the software equivalent of rebuilding a bridge while traffic is on it. Both failures come from refusing to ask the classification question at all.

The genuinely senior move is the third option: convert one-way doors into two-way doors by spending a little engineering up front on reversibility.

• Feature flags turn a risky launch into a dial you can turn back down. The launch stops being a decision and becomes an experiment.
• Abstractions at the boundary — put a thin interface between you and the vendor or storage engine, and the "irreversible" vendor choice becomes a swappable implementation detail. You pay a small tax now for an exit door later.
• Contracts and versioning — a versioned public API lets you ship v2 without breaking v1's promises, converting "we can never change this" into "we can deprecate this on a schedule."

Reversibility is rarely free — but it is often cheap, and buying it is one of the highest-ROI purchases in this entire module: you are buying back the option to be wrong.

Build vs. Buy

The first filter is Geoffrey Moore's core vs. context. Core is what makes customers choose you over the alternative — build it, own it, pour your best people into it. Context is everything else that merely has to work: auth, billing, email delivery, analytics pipelines, admin dashboards. For context, the question is not "could we build this?" Of course you could. Your engineers can build anything; that is precisely the trap. The question is whether building it is the best use of the scarcest currency you have — and for context work, it almost never is, because every week spent rebuilding a solved problem is a week not spent on the thing customers actually pay you for.

The second filter is total cost of ownership. The build estimate you hear in the planning meeting is the down payment. The mortgage is everything after: maintenance, on-call, security patches, upgrades, documentation, and the onboarding cost of every future engineer who has to learn your homegrown thing instead of an industry standard. A useful rule of thumb: steady-state ownership of a system runs 15–20% of its build cost per year, forever, and for anything security-sensitive it runs hotter. Worked comparison for a 40-person startup deciding on authentication:

Buy wins here — not because vendors are cheap, but because auth is context, the tail risk of getting it wrong is catastrophic, and the eng-weeks freed up can go to core. Note the honest third column entry, though: vendor risk is a real column, not a footnote. A vendor can triple prices at renewal, get acquired by your competitor, or sunset the product. This is where the door-conversion trick from the previous section earns its keep: wrap the vendor behind your own thin interface, keep your data exportable, and the buy decision stays a two-way door.

The third filter comes from Dan McKinley's essay Choose Boring Technology: you get about three innovation tokens per company. Each novel technology you adopt — the exotic database, the bleeding-edge framework, the language nobody on the team has run in production — costs a token, paid out in unknown failure modes, thin documentation, and 3 a.m. debugging sessions with no Stack Overflow answers. Spend your tokens where you differentiate; everywhere else, choose the boring thing whose failure modes are already catalogued in a decade of postmortems. The boring choice is not timid. It is the choice of someone who has correctly priced novelty.

Technical Debt Is Actual Finance

Ward Cunningham's debt metaphor gets repeated so often that people forget it is not a metaphor — it is a working financial model with real terms. Principal is the cost to fix: the refactor, the migration, the rewrite of the tangled module. Interest is the recurring drag: the extra time every feature takes because it touches the tangled area, the bugs that regress twice a quarter, the onboarding weeks lost to "oh, that part — let me explain the history." Debt is not bad. Debt is leverage: taking on messy code to ship a customer-winning feature this quarter can be a great trade, exactly like a business borrowing to fund growth. The sin is not borrowing. The sin is not tracking the interest rate.

And here is the judgment call that separates a CTO from a perfectionist: some debt should never be repaid. Interest is only charged when you touch the code. Debt in a module scheduled for deletion, debt in a stable corner nobody has modified in two years, debt in a prototype that will be thrown away — this debt charges no interest, and repaying it is burning engineer-weeks to polish a room you are about to demolish. The portfolio view: pay down debt where the interest rate is high (code touched by every feature), carry debt indefinitely where the interest rate is zero.

This framing also solves the oldest political problem in engineering: getting leadership to fund refactors. The argument that never works is aesthetic: "the code is ugly," "it's not best practice," "we have a lot of debt" (a sentence with no numbers in it). Leadership cannot weigh that against a revenue feature, so it loses, every time, and engineers conclude that leadership does not care about quality. Leadership cares fine — it just only speaks one language. So speak it:

• Never say: "The billing module is a mess and we really need to clean it up."
• Say: "Every feature touching billing costs ~40% extra — that was about 9 eng-weeks of pure interest last quarter, and billing regressions caused 2 of our 3 sev-2s. Repayment is a 6-week refactor. It pays for itself in under two quarters, and the payback improves if the roadmap keeps hitting billing — which it does."

The second version is approvable because it is an investment memo: principal, interest rate, payback period. It can also be honestly rejected — maybe the roadmap is pivoting away from billing and the interest is about to stop accruing — and that rejection is a legitimate financial decision rather than a culture war. Putting numbers on debt does not guarantee the refactor wins. It guarantees the refactor competes.

Expected Value, Risk, and the Planning Fallacy

Everything so far pretended outcomes are certain. They are not, and the fix is old and simple: multiply each outcome by its probability. Expected value = probability × payoff, summed over outcomes. A project with a 20% chance of returning 10x has an expected value of 2x, which beats a sure 1.5x — on paper.

Whether it beats it in reality depends on something the formula does not show: how many bets you get. Across a portfolio of ten independent 20%-chance bets, the odds that none hits are about 10% — the portfolio reliably converts long shots into expected value, which is why venture capital works. But if the risky project is your only bet — the one launch this runway allows — then 80% of the time you get zero, and companies do not get to average over timelines they did not survive. The sure 1.5x keeps you alive to bet again. The CTO synthesis: run a portfolio when you can (many small bets, mostly boring, a few moonshots), and respect survival constraints when you cannot. Never take a company-killing risk for a merely good expected value.

Now for the inputs themselves. Engineering estimates are not just noisy — they are noisy with a known bias. The planning fallacy means humans estimate the best-case path: the version of the project where nothing surprises anyone, which has never once occurred. The working heuristic, only half a joke: multiply the estimate by pi. A "four-week" project landing at twelve weeks is not a scandal; it is the median outcome wearing a party hat. The professional response is not to demand better guessing but to estimate in ranges: ask for a 50% estimate and a 90% estimate, and read the gap between them. "Four weeks or maybe five" is a real plan. "Four weeks, but honestly could be four months" is a research project cosplaying as a plan — budget accordingly, or spend one week on a spike to shrink the range before committing.

The cheapest risk-discovery tool in existence is the pre-mortem. Before committing, gather the team and ask: "It is nine months from now and this project failed embarrassingly. What happened?" The tense does the magic — people who would never voice doubts about a live plan ("negativity") will happily explain a hypothetical corpse. In thirty minutes you will surface the vendor dependency nobody de-risked, the migration everyone was quietly dreading, and the stakeholder who never actually agreed to the requirements. At a cost of one meeting, the pre-mortem is plausibly the highest-ROI activity in this entire module — which is a fitting place to end a module about ROI.

Knowledge Check

Test your understanding before moving on.