The Economics Problem Inside Software Teams Is Still Unsolved

Viktor Cessan’s essay The Economics of Software Teams reopened a question many engineering organizations prefer to leave vague: software teams are expensive, but the value they create is often described in language that finance, product and leadership teams cannot use for decisions. The essay gained attention on Hacker News because it made that tension concrete. It did not pretend that every line of code can be priced neatly, but it asked a fair question: when a team costs a meaningful amount every month, what business outcome is that cost supposed to protect or create?

The point is uncomfortable because most teams are better at measuring activity than value. Tickets closed, story points, sprint velocity, pull requests and release counts can describe motion. They do not show whether customers adopted the feature, whether sales cycles became shorter, whether support costs fell, whether risk decreased or whether the company gained a defensible advantage. A team can look busy and still be working on the wrong economic problem.

Cost is visible; value is harder to prove

Cessan uses a Western European example in which a team of eight engineers can cost about €1 million per year once salary, benefits, equipment, management overhead and office costs are included. The exact number will vary by country, seniority, remote setup and company structure. The useful part is the habit of making the cost visible before a roadmap discussion begins.

Once that cost is visible, familiar decisions look different. Three weeks spent on a low-impact feature are no longer “just engineering time.” They are a capital allocation choice. A platform rewrite started mainly because the current system feels embarrassing is not automatically strategic. A reporting dashboard requested by one internal stakeholder may be useful, but it still has to compete with other work that could reduce churn, unblock sales, improve reliability or lower operating risk.

This does not mean every task needs a fake euro value attached to it. It means teams should be honest about the type of value they are pursuing. Some work creates revenue. Some protects revenue. Some reduces future cost. Some reduces risk. Some buys speed for other teams. The problem starts when all of these are described with the same vague phrase: “important engineering work.”

Break-even is too low a target

One of the stronger parts of the essay is the argument that break-even is not enough. Cessan draws on Leah Tharin’s work on product and growth team economics: the successful bets must pay for the failed ones as well. If a team launches five initiatives and two of them work, those two wins need to cover more than their own delivery cost. They also need to absorb the cost of the experiments that did not land.

That is a hard message for software teams, but it reflects how portfolio decisions work. A team that generates value equal to its direct cost may still be a weak investment if the organization carries failed projects, coordination overhead and opportunity cost around it. The lesson is not that teams should chase vanity ROI numbers. It is that teams need a clearer threshold for why a bet deserves attention now.

The Hacker News pushback matters

The Hacker News debate also exposed a real weakness in simplistic economics. Product value is rarely created by one team alone. A contract may close because of engineering, sales, support, pricing, timing and brand trust. A reliability project may avoid a future outage that never becomes visible. A security improvement may matter most on the day it prevents a breach. Trying to assign precise value to a single squad can become artificial very quickly.

That criticism is valid, but it should not become an excuse for avoiding measurement altogether. There is a middle ground between spreadsheet theatre and complete blindness. Teams can work with ranges, scenarios and explicit assumptions. They can ask which customer segment benefits, which metric should move, what risk is being reduced and what evidence would show that the work failed. Approximate thinking is much better than pretending value is unknowable.

LLMs make the question more urgent

Cessan’s essay also touches a newer pressure: large language models are changing the cost of prototyping and some forms of software production. If an internal tool, integration or first version can be built faster than before, companies will ask harder questions about why a large team, a large codebase or a long delivery cycle is necessary.

That pressure should not be overstated. An LLM-assisted prototype is not the same as a secure, compliant, maintainable enterprise product. Real software still needs architecture, observability, testing, incident response, data governance, accessibility, security review and long-term ownership. But the comparison is changing. When the cost of a rough version falls, the expensive part of software work must justify itself through reliability, domain knowledge, trust, scale and judgment rather than through code volume alone.

What a better operating model looks like

The answer is not to judge every engineering team by a single ROI formula. That would punish important work such as infrastructure, reliability, privacy, security and developer tooling. The better answer is shared language. Engineering, product and finance need to agree on the type of value a team is expected to create before the roadmap is full.

A platform team can justify itself through hours saved across other engineers, reduced build failures or faster onboarding. A reliability team can point to fewer incidents, shorter recovery times and lower customer risk. A product team can connect work to activation, retention, expansion or support volume. A security team can describe expected loss reduction and compliance exposure. None of those measures is perfect. All of them are better than counting output and hoping value appears later.

The economics problem inside software teams remains unsolved because software value is messy. It is shared, delayed and often indirect. But that is precisely why the conversation matters. Teams that can explain their economics without flattening their work will be easier to fund, easier to protect and harder to confuse with mere headcount. In 2026, when AI tools are making some kinds of production cheaper, that clarity is no longer optional.