The Most Expensive Engineering Work Is Work Nobody Needed

Shipping on time doesn’t prove the work was worth doing

Most engineering organizations are good at measuring whether work was delivered. Was it on time? On budget? Did the launch go smoothly? Far fewer go back and ask whether anyone needed it.

A team can execute perfectly and still deliver something that didn’t deserve the investment. The estimates held, the code is clean, the release was quiet, and six months later almost nobody uses the feature.

The most expensive engineering work is work nobody needed. It costs the time to build it, keeps costing maintenance, support and operational complexity for as long as it exists, and takes the place of work that would have mattered.

On-time delivery tells you the team can execute. It says nothing about whether the decision to build was sound, and that decision usually has a different owner.

Unnecessary work keeps consuming capacity after launch

The build is the cost everyone sees, and often the smallest one. Once a feature ships, the team has to carry it:

• It has to survive every framework upgrade, dependency patch and schema change.
• It produces bugs that someone has to triage.
• Support has to understand it, and the few customers who use it expect it to stay.
• It adds code paths and tests that make nearby changes slower and riskier.

The largest cost appears on no report: the work the team didn’t do because it was building this instead. And once even a handful of customers depend on a feature, retiring it becomes its own project. Services behave the same way, which is why I care more about what it costs to own a service for years than what it costs to create one.

How do teams end up building features nobody needs?

Rarely through carelessness. Unneeded features usually start with a vague problem, pressure from a stakeholder, a solution proposed before anyone understood the problem, or a priority nobody felt able to challenge.

Vague problems

“Customers want better reporting” can justify almost any amount of work, because nobody has said which customers or which decision.

Stakeholder pressure

A senior leader or a large customer asks, and the request becomes a commitment before anyone checks how widely the problem exists.

Premature solutions

The request arrives as a design: “Build a dashboard.” The team estimates the dashboard instead of asking what question it should answer.

Unchallenged priorities

Something entered the roadmap a quarter ago, the reasons behind it changed, and nobody revisits it because it’s already planned.

None of this requires bad intent, only a process where the first reasonable-sounding idea becomes the plan.

A request, a proposed solution and the underlying need are different things

Most requests arrive with all three mixed together. Take a hypothetical one from an account manager:

The request

“Our biggest customer needs an export to Excel.”

The proposed solution

A scheduled export with configurable columns and email delivery.

The underlying need

Their finance team reconciles invoices at month-end and can’t easily see which payments failed.

Once the need is clear, the options change. A filtered view of failed payments might solve it, or a one-off CSV and a short call. The scheduled export could still be right, but now the team is choosing it on purpose. It’s the same discipline as turning ambiguity into executable work: start from the outcome and make the first slice test the riskiest assumption.

Three hypothetical examples

These are illustrations, not accounts of a specific company.

Hypothetical example 1: A reporting dashboard when an existing report would do

Leadership asks for a dashboard to track customer churn, and the team scopes a pipeline, charts and filters. Before committing, someone asks what decision it will inform. The answer is a monthly retention review, and an existing report with two added columns already answers that question. The dashboard might earn its place later if people need the answer weekly. Today it would be a live system maintained for one meeting a month.

Hypothetical example 2: An integration built before customer demand is validated

Sales believes a CRM integration will unlock deals, so the team spends a quarter building it. A few customers turn it on, and the deals turn out to have stalled for other reasons. A cheaper first step would have been a CSV import, or syncing data by hand for the three customers who asked, long enough to see whether it changed anything. Instead, the integration now needs updating every time the partner changes its API.

Hypothetical example 3: A rewrite proposed before anyone names what it must fix

A team wants to rewrite a legacy service because it’s painful to work in. Everyone agrees, but nobody has written down what has to be better afterward: deploy time, defects in one module, onboarding time, a scaling limit. Without that list, the rewrite has no finish line and no way to show it worked. With it, the team can often fix the worst problems in place and choose a rewrite only if that falls short. I treat it the way I treat technical debt: as an investment decision.

Engineers need room to question the work

Engineers are often the first to notice that something doesn’t add up: a feature that duplicates an existing one, or a dashboard built on data nobody trusts. Whether they say so depends on what happened the last time someone did. If questioning a request gets an engineer labeled difficult, people stop asking, and the team gets very efficient at building whatever arrives.

So I try to make those questions a normal part of the work:

• Questions about the need are welcome at planning, alongside questions about the estimate.
• Engineers hear the context behind a request: who asked, what problem, what evidence.
• “Could we test this first?” is treated as a proposal, not a refusal.

It’s also how engineers learn to reason about the business, a big part of how I mentor engineers until they can replace me.

How do you challenge a request constructively?

Ask about the outcome before the solution, and offer a smaller way to test it instead of a flat no. Most stakeholders welcome those questions once it’s clear they’re aimed at getting them the result they want.

• “What outcome are we trying to change?”
• “Who has this problem today, and how are they handling it now?”
• “How will we know it worked?”
• “Could we test this before committing a team?”
• “If we build this, what moves out of the quarter?”

Product and sales should get honest options with the costs attached, and the decision stays with the people accountable for it. Engineering’s job is to make sure that decision is made with the full cost in view.

When work is justified without immediate revenue

None of this means every piece of work needs a revenue forecast.

Experiments

An experiment that disproves a hypothesis did its job. The waste is one with no hypothesis, no success criteria and no end date, or one that quietly becomes a permanent feature.

Compliance and security

These are justified by the risk they remove. The useful question is what the smallest compliant version looks like.

Foundational work

Platform, reliability and tooling work pays off through everything built on it. It still needs a named problem: which teams it unblocks, which incidents it prevents.

The test is the same for all three: a clear reason, a way to tell whether it worked, and someone who owns the result. A well-run experiment that came back “no” wasn’t a mistake. Continuing to build as if it had come back “yes” would be.

Faster development with AI makes this decision more important

AI tools make code much cheaper to produce. When the build gets cheaper, it becomes a smaller share of the total cost, while maintenance, support, operational complexity and the team’s attention stay roughly where they were. A team that can produce features twice as fast can also accumulate work nobody needed twice as fast.

Cheap code is a real advantage when it’s pointed at testing a need: throwaway prototypes, quick experiments, a rough version in front of a few customers. It’s a liability when it lets a team skip the question of whether the thing should exist. As with what AI changes for engineers, the judgment around the output is still the scarce part.

What should you ask before committing engineering capacity?

Before a team commits, I want answers to eight questions about the problem, the evidence, the cost of doing nothing, the smallest test, existing alternatives, what gets delayed, who owns the outcome, and what would make us continue, change direction or stop.

1. Who has this problem, and how often? A daily problem for many users and a quarterly annoyance for one are different investments.
2. What evidence shows it matters? Support tickets, lost deals, usage data, customer conversations. One loud request is a signal, not evidence.
3. What happens if we do nothing? Sometimes the honest answer is “not much,” and that’s worth knowing.
4. What is the smallest way to test the need? A prototype, a manual process, or a conversation with five customers.
5. What existing solution or manual process could work? An existing report, a configuration change, or someone doing it by hand for a month.
6. What are we delaying by choosing this? Every yes delays something else. Name it.
7. Who owns the outcome after launch? Someone responsible for whether it worked, and for retiring it if it didn’t.
8. What result would make us continue, change direction or stop? Decide before launch, while nobody is attached to the answer.

Thin answers don’t automatically mean no. They mean the first piece of work is finding out.

Short answers