The Denominator I Corrected
and the one nobody else did

In April I was checking closing results. The Serbian team's KPIs had an anomaly.

I started digging.

The trace led back to my own tool. A few releases earlier, I had added location-based working hour adjustments. The trigger came from something I had noticed years back at Accenture: working hours vary more than most assume. Norway, Denmark, India, Serbia — each country carries its own standard, and what counts as a full day is not the same number twice.

In Riga, the working day is 8 hours, lunch excluded. In Serbia, 8 hours total, with 30 minutes of lunch inside. In India, 9 hours total, with an hour of lunch inside. The effective maximum PC time — the actual billable window — is different in each place.

My tool measures utilization against that window. So I corrected the denominator per location.

What I had not checked was downstream.

One reporting layer was still dividing by a flat 8 hours for everyone. Before my change, everything was misaligned in the same direction and nobody noticed. After my change, the upstream denominator became precise and the downstream one stayed approximate. A Serbian employee working a full day would show slightly under 100% utilization in one place and exactly 100% in another. The gap became visible for the first time.

My improvement had created the anomaly. Or more accurately, it had exposed a mismatch that was already there, waiting.

This was not the first time.

I have traced similar anomalies back to my own earlier changes across other tools, other spreadsheets, other projects. A small tweak upstream. A quiet failure somewhere downstream. Every time, the same recognition: the thing I improved became the thing I had to debug.

The pace of that cycle has changed. Tools I once built over days now take hours. AI-assisted iteration has compressed the distance between idea and release. The changes arrive faster. The downstream does not.

Years earlier, I was sitting in an entrepreneurship class during my MBA at Riga Business School. One of the lecturers described a system he had built in the late 1980s.

The main stakeholder had found a rounding error. Cents. Here and there, a one-cent gap in the output.

For the developer, the number was immaterial. A few cents against millions in revenue.

The client did not see it that way.

If your system makes mistakes at cents, I do not trust it at all.

The cause was not a bug in a single calculation. The wrong data model had been chosen early. The wrong function had been chosen to go with it. The cents were just where it became visible to the client.

A small gap. A total trust collapse.

Both scenes share the same shape.

A small decision, made early, in one place. The rest of the system does not follow. Something surfaces far downstream, looking like a different problem entirely.

The location adjustment I added was not large. The data model that lost the client was not dramatic. Neither felt like a risk at the moment it was made.

That is exactly the problem.

The downstream is still there.

It just has less time to announce itself.

P.S. The April anomaly was eventually debugged with AI assistance. Which felt appropriate.