Engineering economics

Every allocation of engineering effort is a choice made against alternatives. v1.0 framed this competency as resource allocation and build-versus-buy. v3.0 renames it engineering economics because its scope has grown. It now covers the cost of delivery as a whole; budgets and headcount as investments that have to be argued for and defended; vendors and the dependencies they create; and a third option beside build and buy, the AI service, which has its own profile of cost and risk. The disciplines themselves are old. Build what differentiates and buy the commodity. Weigh total cost of ownership over sticker price. Concentrate effort so that work gets finished, instead of spreading it thin. Let what has already been spent argue for nothing. What has changed is that managers at every scope are now expected to reason about engineering in terms of cost and return, and the examinations reward the option that ties a decision to the economics over the one that follows engineering preference. Engineering is usually a company's largest discretionary cost, and a manager who cannot explain what it buys will be told what it costs.

1. Build the core, buy the context. Build what differentiates the business and where control matters. Buy or adopt the commodity, which frees scarce engineers for differentiating work. Core means differentiating, which is not the same as important.
2. Weigh total cost of ownership, not sticker price. Building is never a one-time cost, because maintenance lasts for ever. Buying is not free either, once integration, lock-in and exit are counted. The discipline is to name the lifetime costs explicitly; computing them precisely is not the point.
3. What has been spent argues for nothing. Only the forward-looking comparison counts: value remaining against cost remaining, set against the alternatives. Changed fundamentals justify switching a bet. Novelty does not.
4. Concentrate to finish. With too many bets running at once, none of them is funded properly. Funding one decisively beats hedging into two mediocre efforts.
5. Argue headcount and budget as investment, in outcomes. Say what the spend enables and protects and what not spending costs, and stage it with checkpoints. A cut goes to the lowest-value work. It is never spread evenly as a way of avoiding a decision.
6. Weigh control and dependency, not only cost. For a strategic capability, two questions outrank price and speed: who ends up owning it, and where you stand if a vendor or partner relationship sours.

The economic disciplines here are practitioner frameworks. The one bias with a research literature behind it is graded accordingly.

Core versus context practice

Geoffrey A. Moore, Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution (2005) sets out the distinction. Core is whatever differentiates a business in its customers' eyes. Context is everything else that has to be done without differentiating. Build and invest in core; buy, adopt or outsource context; and move engineers from context to core. The boundary shifts as yesterday's differentiator becomes a commodity. The usual misreading treats "core" as meaning "important". Email is important and is almost never core.

Total cost of ownership practice

This is the full lifetime cost of a capability. For a build it is the build cost plus maintenance for ever. For a purchase it is the price plus integration, lock-in and the cost of exit. It has no single author, and it corrects every claim that something is "cheaper". Costs over a long horizon are estimates. The discipline is to name them explicitly so they can be argued over, without computing them to a false precision.

Sunk-cost discipline research

Hal R. Arkes and Catherine Blumer, The Psychology of Sunk Cost (1985) found that prior investment makes people more likely to continue a course of action, regardless of its prospects. In engineering economics this governs three familiar cases: the half-done migration whose justification has worn away, the championed bet that a more promising direction has overtaken, and the legacy system kept because so much went into it. The recommendation always looks forward: continue, descope or stop, judged on value remaining against cost remaining. Executive integrity means applying the same arithmetic to one's own advocacy.

Build, buy, or AI service practice

This is a decision, not a named model, and v3.0 adds it as a three-way choice: besides building a capability or buying a product, a team can adopt an AI service that provides it. The third option has a profile of its own. Its initial cost is low and its ongoing cost uncertain, the alternatives go out of date quickly, and it depends on a provider whose terms and capabilities change. It is weighed with the same questions as the other two. Is this core? What is the lifetime cost? Where do we stand if the provider changes course?

Headcount as investment practice

This is a framing, not a named model, and the unit treats it as essential for anyone who argues for a budget. Engineering headcount is an investment with a return. It is argued in terms of what it enables and protects and what its absence costs, staged with checkpoints, and defended with outcome measures in place of activity. The failure is a budget defended by describing how busy everyone is.

The build/buy/AI worksheet

Any capability decision larger than a sprint gets a one-page comparison. It asks whether the capability is core or context; sets out the lifetime cost of each option, including maintenance, integration, lock-in and exit; and assesses reversibility. For a strategic capability it also asks who ends up owning it and what happens if the relationship sours. The recommendation follows from the page, and the page is kept so the decision can be revisited when the boundary moves.

The forward-looking review

A bet that has consumed more than its budget, or whose justification has weakened, gets a review that ignores what has been spent. The review asks what value remains, what it will cost to obtain, and what the alternatives would return for the same spend. It ends in continue, descope or stop. The reviewer applies it with the same rigour to bets they championed.

The investment case

Headcount or budget is requested as an investment. The request sets out what it enables, what it protects, what not funding it would cost and how success will be measured, and it is staged so that the first tranche can be judged before the second is released. A cut is answered with the same structure. First identify the work that would not be started today, then aim the cut at it.

The vendor register

The register lists every significant vendor and AI service the department depends on. For each it records what the service does, what it costs, what leaving it would cost, and how much of the department's delivery would stop if it failed. It is reviewed every year. A dependency that could stop delivery and has no exit plan is a risk to be engineered down.

Charter clarity

Sometimes a peer department encroaches on a capability the team owns, or an opportunity with a high return turns up outside the team's charter. The right move is a conversation about the boundary at the level where charters are set, either to clarify the charter or to propose an explicit change. Duplication fought commit by commit is the wrong move, and so is a quiet land-grab. How charters are designed is covered in SV-6 Organisational design and leading change.

At team scope the manager deals with build-versus-buy calls and the team's own costs, and applies core versus context, total cost of ownership and focus directly. At organisational scope the work becomes a department budget and headcount plan. The manager chooses between bets of similar size on outcome, cost of delay, risk and reversibility; cuts under constraint by targeting the lowest-value work; and settles charter disputes at the level that owns them. At executive scope the manager is responsible for the economics of engineering as a whole (cost of delivery, capital allocation, headcount as investment) and for decisions with strategic consequences beyond engineering. These include build-versus-partner where the partner could become a competitor, funding one of two compelling bets properly instead of splitting the money to avoid choosing, and treating an acquisition's integration as a strategy with a bill attached. The pattern is in How Judgment Scales, and governance of the third option is covered in TJ-5 AI-assisted engineering.

• Builds the differentiating core and buys the commodity context. team
• Weighs total cost of ownership over sticker price. team
• Concentrates effort to finish instead of spreading it across too many bets. team
• Revisits allocations on evidence as priorities shift. team
• Evaluates an AI service as a third option with its own cost, obsolescence and dependency profile.
• Failure mode: building commodity capability because it was not invented here. team
• Failure mode: outsourcing the differentiator. team
• Failure mode: ignoring maintenance that lasts for ever. team
• Failure mode: too many simultaneous bets. team
• Compares bets of similar size explicitly on expected outcome, cost of delay, strategic fit, risk and reversibility, and not on whose advocacy is loudest. org
• Switches a committed bet only on changed fundamentals, never because something newer has appeared. org
• Reassesses a half-done, over-budget migration on forward-looking arithmetic, ending in a clean continue, descope or stop. org
• Targets a budget cut at the lowest-value work (what would not be started today), never at an across-the-board shave. org
• Settles a charter dispute explicitly at the level where charters are set. org
• Takes a high-return opportunity outside the team's charter to its owner, or proposes a charter change, instead of grabbing the territory or ignoring it. org
• Plans and defends a department budget and headcount in terms of outcomes and cost of delivery. org
• Failure mode: finishing doomed work to honour its sunk cost. org
• Failure mode: chasing novelty mid-bet. org
• Failure mode: peanut-butter budget cuts. org
• Failure mode: fighting charter wars through duplicated engineering. org
• Weighs a build-versus-partner decision for a strategic capability mainly on control and dependency risk: who owns the capability, and where you stand if the relationship sours. exec
• Funds one of two compelling bets properly, weighing the asymmetry (which failure is survivable, which success compounds) instead of splitting to avoid the decision. exec
• Applies the same forward-looking arithmetic to a bet they personally championed, and redirects when a better direction has emerged. exec
• Treats an acquisition's integration as an explicit strategy with a bill: which platform consolidates, which teams merge, on what timeline, with the cost of retaining the people the company bought priced in. exec
• Reasons about the economics of the whole function, such as cost of delivery and capital allocation, and changes them. exec
• Failure mode: partnering the crown jewels to a future competitor. exec
• Failure mode: splitting funding to avoid choosing. exec
• Failure mode: letting acquired stacks and organisations drift unintegrated. exec
• Failure mode: optimising acquisition cost while the acquired talent walks out. exec

Control versus cost. Buying is usually cheaper, and building keeps the capability in hand. For context, buy; for core, build. The hard cases are capabilities sitting on a moving boundary, and the judgment is in seeing which way that boundary is moving.

Focus versus optionality. Funding one bet properly means giving up the other, and keeping both alive funds neither. Asymmetry decides it: which failure is survivable, which success compounds, and which bet builds capability the strategy needs anyway.

Persistence versus sunk cost. From the inside, the bet that needs one more quarter looks the same as the bet that should have been stopped a year ago. Only the forward-looking review tells them apart, and it is hardest to apply to one's own advocacy.

Speed versus dependency. An AI service or a partner delivers a capability now, and it also decides who owns that capability later. For context, speed wins. For a strategic capability, the dependency question outranks it.

Targeted cuts versus fairness. A cut aimed at the lowest-value work lands on particular teams and looks unfair. A cut spread evenly looks fair and degrades everything. The judgment is to make the targeting explicit and its criteria visible, so that the unfairness falls on the work and spares the people.

A head of engineering has to decide how the company will get the AI infrastructure its products will increasingly depend on: the model serving, retrieval and evaluation layer that the next two years of product strategy assume. Three options are on the table. The first is to build it, which the platform team estimates at a year with four senior engineers. The second is to buy it from a vendor whose product is good, whose pricing is per request and whose roadmap is opaque. The third is a partnership with a well-funded company in an adjacent market. It has offered to provide the layer cheaply in exchange for close integration, and, on the evidence of its own strategy, it could become a competitor within two years.

The pull is toward the partner. It is the fastest and cheapest option, the offer is already on the table, and the chief financial officer favours it. The head of engineering starts instead with the question that outranks cost and speed for a strategic capability: is this core, and who ends up owning it? The layer is core, since it is what the product strategy differentiates on. Under the partnership it would be owned by a company with every incentive to withdraw it at the moment it mattered most. The company's position if the relationship soured carries the most weight, and that position would be untenable.

Next the vendor option is weighed on total cost of ownership instead of sticker price. That means per-request pricing against projected volume, the cost of integration, the cost of leaving if the vendor's roadmap diverges, and the dependency on a provider whose terms can change. The build option is weighed in the same terms: a year of four senior engineers, maintenance for ever, and the opportunity cost of what those engineers would otherwise do. Against that, the company would own a core capability and could differentiate on it.

The recommendation is staged. The commodity parts of the layer are bought from the vendor now, with an exit plan and a contract that caps the pricing risk. The differentiating parts, retrieval and evaluation, where the product's edge lies, are built over the same year by two engineers instead of four. The partnership is declined, and the head of engineering gives the chief financial officer the reasoning in the company's terms: the offer is cheap because the partner would own the thing the strategy depends on.

Deciding on cost and speed would have chosen the partner and handed a future competitor the capability that mattered. The head of engineering did not make that decision.

• SV-3 Roadmapping: the roadmap's platform investment as the recurring allocation decision.
• SV-2 Communicating and partnering across functions: arguing the investment case to executives and the board.
• SV-6 Organisational design and leading change: charters and ownership boundaries as the structural form of allocation.
• TJ-5 AI-assisted engineering: governing the AI option, building capability for it, and its risk.
• DE-1 Prioritisation under constraint: the portfolio ranking that allocation decisions serve.

1. How does core versus context guide a build-versus-buy decision, and what is the common misreading?
   Answer

   Build what differentiates the business and where control matters, and buy the commodity. The misreading is to treat "core" as meaning "important". Email is important and almost never core.
2. What does total cost of ownership add to a "this is cheaper" argument?
   Answer

   The lifetime costs that the sticker price hides: maintenance for ever for a build, and integration, lock-in and exit for a purchase. The discipline is to name them explicitly; precise computation is not the point.
3. A year-old migration is half done, over budget, and its justification has weakened. What does the recommendation weigh, and what does it ignore? org
   Answer

   It weighs value remaining against cost remaining, compared with the alternatives, and ends in continue, descope or stop. It ignores what has already been spent, which argues for nothing.
4. You are told to cut the department budget by 15%. Where do you look first, and what is the wrong answer? org
   Answer

   At the work with the lowest strategic value, meaning the initiatives that would not be started today. The wrong answer is the across-the-board shave, which degrades everything equally and decides nothing.
5. What is different about the AI service as a third option beside build and buy?
   Answer

   Low initial cost, uncertain ongoing cost, alternatives that go out of date quickly, and dependency on a provider whose terms and capabilities change. It is weighed with the same questions as the others: core or context, lifetime cost, and where you stand if the provider changes course.
6. In a build-versus-partner call where the partner could become a competitor, what weighs most and why? exec
   Answer

   Strategic control and dependency risk: who ends up owning the capability, and where you stand if the relationship sours. For a core capability these outrank cost and speed, because the offer is cheap precisely because the partner would own what the strategy depends on.
7. What makes redirecting from a bet you personally championed the credibility move rather than the credibility loss? exec
   Answer

   Applying the same forward-looking arithmetic to your own advocacy is what makes your next recommendation believable. Doubling down to protect the appointment or the argument loses the bet and the credibility together.

• Geoffrey A. Moore, Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution (2005): core versus context.
• Hal R. Arkes and Catherine Blumer, The Psychology of Sunk Cost (1985): the psychology of sunk cost.