Engineering economics

Every allocation of engineering effort is a choice against alternatives, and v1.0 framed this competency as resource allocation and build-versus-buy. v3.0 renames it engineering economics because the object has widened: the cost of delivery as a whole, budgets and headcount as investments that must be argued and defended, vendors and the dependencies they create, and a third option beside build and buy — the AI service — with its own cost and risk profile. The disciplines are old: build what differentiates and buy the commodity, weigh total cost of ownership rather than sticker price, concentrate effort to finish rather than spreading it thin, and let what has already been spent argue for nothing. What is new is that a manager at every scope is now expected to reason about engineering in the language of cost and return, and that the examinations reward the option that ties a decision to the economics over the one that follows engineering preference. The competency matters because 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, freeing scarce engineers for differentiating work. Core is about differentiation, not importance.
2. Weigh total cost of ownership, not sticker price. Building is never a one-time cost — maintenance is forever; buying is not free — integration, lock-in, exit. The discipline is naming the lifetime costs explicitly, not computing them precisely.
3. What has been spent argues for nothing. Only the forward-looking comparison — value remaining against cost remaining, against alternatives — counts. Changed fundamentals justify switching a bet; novelty does not.
4. Concentrate to finish. Too many simultaneous bets means none of them is funded properly. Funding one decisively beats hedging into two mediocrities.
5. Argue headcount and budget as investment, in outcomes. What the spend enables and protects, what not spending costs, staged with checkpoints. A cut is targeted at the lowest-value work, never spread evenly to avoid deciding.
6. Weigh control and dependency, not only cost. For a strategic capability, the question of who ends up owning it — and what position you are in if a vendor or partner relationship sours — outranks price and speed.

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

Core versus context practice

The distinction set out in Geoffrey A. Moore, Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution (2005): core is what differentiates a business in its customers' eyes, context is everything else that must be done but does not differentiate. Build and invest in core; buy, adopt or outsource context, and move engineers from the second to the first. The boundary moves — yesterday's differentiator commoditises — and the common misreading is to treat "core" as "important": email is important and almost never core.

Total cost of ownership practice

The full lifetime cost of a capability: build cost plus maintenance forever, or purchase price plus integration, lock-in and exit cost. No single author; the corrective to every "cheaper" claim. Long-horizon costs are estimates, and the discipline is to name them explicitly so they can be argued, not to compute them to a false precision.

Sunk-cost discipline research

The finding in Hal R. Arkes and Catherine Blumer, The Psychology of Sunk Cost (1985) that prior investment increases the tendency to continue a course of action, independent of its prospects. In engineering economics it governs the half-done migration whose justification has eroded, the championed bet a more promising direction has overtaken, and the legacy system kept because so much went into it. The recommendation is always forward-looking — continue, descope or stop on value remaining against cost remaining — and executive integrity is applying the same arithmetic to one's own advocacy.

Build, buy, or AI service practice

Not a named model but the three-way decision v3.0 adds: alongside building a capability or buying a product, adopting an AI service that provides it. The third option has its own profile — low initial cost, uncertain ongoing cost, rapid obsolescence of the alternatives, and a dependency on a provider whose terms and capabilities change — and it is weighed with the same questions as the other two: is this core, what is the lifetime cost, and what position are we in if the provider changes course.

Headcount as investment practice

Not a named model but the framing this unit treats as essential for anyone who argues a budget: engineering headcount is an investment with a return, argued in what it enables and protects and what its absence costs, staged with checkpoints, and defended with outcome measures rather than activity. Its failure is the budget defended by describing how busy everyone is.

The build/buy/AI worksheet

For any capability decision larger than a sprint, a one-page comparison: is this core or context; the lifetime cost of each option including maintenance, integration, lock-in and exit; reversibility; and, for strategic capabilities, 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

Any bet that has consumed more than its budget or whose justification has weakened gets a review that ignores what has been spent: what value remains, what it will cost to obtain, and what the alternatives would return for the same spend. The output is continue, descope or stop. The review is applied with the same rigour to bets the reviewer championed.

The investment case

Headcount or budget is asked for as an investment: what it enables, what it protects, what not funding it costs, and how success will be measured, staged so that the first tranche can be evaluated before the second. The same structure answers a cut: the work that would not be started today is identified first, and the cut is targeted at it.

The vendor register

Every significant vendor and AI service the department depends on, with what it does, what it costs, what the exit would cost, and how much of the department's delivery would stop if it failed. Reviewed annually; a dependency that could stop delivery and has no exit plan is a risk to engineer down.

Charter clarity

When a peer department encroaches on a capability the team owns, or a high-return opportunity appears outside the team's charter, the move is a boundary conversation at the level where charters are set — clarify, or propose an explicit change — not duplication fought commit by commit or a quiet land-grab. The design of charters is SV-6 Organisational design and leading change.

At team scope the object is a build-versus-buy call and the team's own cost, and the manager applies core-versus-context, total cost of ownership and focus directly. At organisational scope the object becomes a department budget and headcount plan, choosing between bets of similar size on outcome, cost of delay, risk and reversibility, cutting under constraint by targeting the lowest-value work, and settling charter disputes at the level that owns them. At executive scope the object is the economics of engineering as a whole — cost of delivery, capital allocation, headcount as investment — and the decisions with strategic externalities: build-versus-partner where the partner could become a competitor, funding one of two compelling bets properly instead of splitting to avoid choosing, and an acquisition's integration treated as a strategy with a bill. The pattern is in How Judgment Scales; the third option's governance is 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 rather than 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 forever-maintenance. team
• Failure mode — too many simultaneous bets. team
• Compares bets of similar size on expected outcome, cost of delay, strategic fit, risk and reversibility — explicitly, not by advocacy volume. org
• Switches a committed bet only on changed fundamentals, never on the appearance of something newer. org
• Reassesses a half-done, over-budget migration on forward-looking arithmetic with a clean continue, descope or stop. org
• Targets a budget cut at the lowest-value work — what would not be started today — never the across-the-board shave. org
• Settles a charter dispute explicitly at the level where charters are set. org
• Surfaces a high-return opportunity outside the team's charter to its owner, or proposes a charter change, rather than land-grabbing 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 primarily on control and dependency risk — who owns the capability, and what position you are in if the relationship sours. exec
• Funds one of two compelling bets properly, weighing asymmetry — which failure is survivable, which success compounds — rather than 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 retention of the people actually bought priced in. exec
• Reasons about the economics of the whole function — cost of delivery, 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 the answer is buy; for core the answer is build; the hard cases are the capabilities on the moving boundary, and the judgment is in seeing which way the boundary is moving.

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

Persistence versus sunk cost. The bet that needs one more quarter and the bet that should have been stopped a year ago look the same from inside. The forward-looking review is the only instrument that 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; it also decides who owns the capability later. For context the 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 reads as unfair; a cut spread evenly reads as fair and degrades everything. The judgment is to make the targeting explicit and its criteria visible, so that the unfairness is to the work and not to the people.

A head of engineering must decide how the company will obtain 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. Build it, which the platform team estimates at a year with four senior engineers. Buy it from a vendor, whose product is good, whose pricing is per-request and whose roadmap is opaque. Or partner with a well-funded company in an adjacent market that has offered to provide the layer at low cost in exchange for a close integration — and that could, on the evidence of its own strategy, become a competitor within two years.

The pull is toward the partner: fastest, cheapest, and the offer is on the table. The chief financial officer favours it. The head of engineering starts 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 — it is the thing the product strategy differentiates on — and under the partnership the capability would be owned by a company with every incentive to withdraw it at the moment it mattered most. The position the company would be in if the relationship soured is the primary weight, and it is untenable.

The vendor option is then weighed on total cost of ownership rather than sticker price: per-request pricing against projected volume, integration cost, the cost of exit if the roadmap diverges, and the dependency on a provider whose terms can change. The build option is weighed on the same terms: a year of four senior engineers, maintenance forever, and the opportunity cost of what those engineers would otherwise do — but ownership of a core capability, and the ability to differentiate on it.

The recommendation is staged: buy the commodity parts of the layer from the vendor now, with an exit plan and a contract that caps the pricing risk, and build the differentiating parts — retrieval and evaluation, where the product's edge lives — with two engineers rather than four, over the same year. The partnership is declined, with the reasoning given to the chief financial officer in the company's terms: the offer is cheap because the partner would own the thing the strategy depends on.

What the head of engineering does not do is decide on cost and speed, which would have chosen the partner and handed a future competitor the capability that mattered.

• 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 — the AI option's governance, capability-building and 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; buy the commodity. The misreading is treating "core" as "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 the sticker price hides: maintenance forever for a build; integration, lock-in and exit for a purchase. The discipline is naming them explicitly, not computing them precisely.
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 alternatives, and produces 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 fifteen percent. Where do you look first, and what is the wrong answer? org
   Answer

   At the work with the lowest strategic value — 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, rapid obsolescence of the alternatives, and dependency on a provider whose terms and capabilities change. It is weighed with the same questions — core or context, lifetime cost, position 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 what position you are in if the relationship sours. For a core capability that outranks cost and speed, because the cheap 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 both the bet and the credibility.

• 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.