How to measure the cost of repeated engineering investigation

Every engineering organization pays a tax on systems it does not fully understand. An engineer opens a ticket, spends a day working out how the billing retry logic actually behaves, fixes the issue, and moves on. Three months later a different engineer spends a day working out the same thing. The knowledge was produced twice and kept neither time.

This cost is real, recurring and almost never on a budget line. Because it is invisible, it loses every prioritization argument to work with a visible number attached. The fix is not to estimate it. It is to measure it.

What you are measuring

Define the thing precisely or the measurement will not survive scrutiny. A useful definition:

Investigation time is time an engineer spends establishing how an existing system behaves before they can make a change, answer a question or resolve an incident. It excludes designing or writing the change itself.

Repeated investigation is investigation time spent establishing something that had already been established by someone in the organization and was not available in a form the engineer could find and trust.

The second definition is the one that matters, and it has a test built in: could this have been looked up? If the answer is yes but the engineer did not know where, or did not trust what they found, it counts.

What to count

Keep the instrument small. Four fields per investigation episode are enough.

1. System or component. Specific enough to aggregate. “Order service, idempotency handling” rather than “backend”.
2. Time spent. In hours, to the nearest half hour. Precision beyond that is false.
3. Question answered. One sentence. “How long does a duplicate ref block a retry?”
4. Prior answer existed? Yes, no, or unknown. Yes means someone had established this before and it was not findable or not trusted.

Optional fields that help later: whether the answer was written down afterwards, and where; whether the investigation was triggered by an incident, a feature, or a question from another team.

How to collect it

Choose a method the team will tolerate for a defined period. Six to eight weeks is long enough to see patterns and short enough that people will do it.

Ticket tagging. Add an investigation label and a time field to the issue tracker. Engineers tag tickets where investigation dominated. Low effort, under-counts, because many investigations never become tickets.

Incident and review notes. Post-incident reviews already record timelines. Pull out the time between “began looking” and “understood the cause”. For code reviews, note when a review stalls on “how does this part actually work?”.

Short retrospective prompts. Once a week, each engineer answers: what did you have to work out about an existing system this week, and how long did it take? Five minutes, higher coverage than ticket tagging, relies on recall.

Support and question channels. Count questions in team channels that ask how a system behaves, and time to a confident answer. These are investigations someone else is doing on the asker’s behalf.

Use two methods and reconcile. Where they disagree, the higher figure is usually closer, because every method under-counts.

Turning counts into a cost

Once the period ends, the arithmetic is simple. The point is to keep every input visible so the result can be challenged.

repeated_hours      = sum of hours where prior_answer_existed = yes
loaded_hourly_cost  = fully loaded engineer cost / working hours per year
direct_cost         = repeated_hours × loaded_hourly_cost
annualized          = direct_cost × (52 / weeks measured)

A worked example, with placeholder numbers chosen only to show the arithmetic:

Those values are illustrative. Yours will differ, and the method is the point. Present the table with your real inputs, not the conclusion alone.

Add the costs that hours miss

Hours are the floor. Three further effects are harder to quantify and should be stated rather than omitted.

• Delay. Investigation sits at the front of a change. A day of investigation often delays a feature by more than a day because of coordination around it. Record elapsed time alongside effort where you can.
• Incident duration. Time to understand a system during an outage is time the outage continues. Pull this from incident timelines separately; it is often the most persuasive figure.
• Decision avoidance. Changes that were not attempted because nobody understood the system well enough to estimate them. Collect examples from planning discussions. These cannot be summed, but a list of three concrete deferred changes carries weight.

Resist attaching invented multipliers to these. A stated qualitative cost is credible. A made-up factor is not.

Reading the result

Aggregate by system. The distribution is usually uneven: a small number of components account for most repeated investigation. Those are the candidates for deliberate documentation, behavioral analysis, or tests that encode the answers.

For each candidate, you now have a comparison to make: the annualized repeated investigation cost against the one-time cost of establishing the system’s behavior properly and keeping that record current. The comparison will not always favor action. Some systems are investigated repeatedly because they are about to be retired. The measurement lets you tell those apart from the ones that will keep charging the tax.

Keep measuring after you act

If you invest in understanding a system, measure the same way afterwards. The number should fall for that system. If it does not, the record you produced is not findable, not trusted, or not answering the questions engineers actually have. Each of those is a different problem, and the follow-up investigation log will tell you which.

Where Foundry fits

When a system tops this list, Foundry can establish its behavior once and deliver it in a form engineers can look up and trust: a behavior report with every finding labeled observed, inferred, verified or open, a dependency map, and tests that keep the answers current as the system changes. The engineering leaders page covers how teams decide which system to start with.