The Correction Clock: how to measure a cost most teams misprice
An $80,000 rework on a team that was supposed to save $30,000. The Correction Clock is the part of the math nobody puts in the budget.
A few years ago I sat in a budget review with the CEO of a SaaS company in Austin. Her engineering team had been running through us for about eight months, three engineers in her Austin office, four in Argentina with a two-to-three hour offset, and one in Portugal who added five hours on top of that. She had spent roughly what we’d budgeted. She was not getting what she’d expected.
The releases were slower than projected. The Austin team was burning a lot of cycles redoing things that had come back wrong. There were no obvious failures, no missed deliverables, no individual engineer to blame. Just a pervasive sense that the team was working very hard for less output than the headcount suggested.
I spent two days going through the sprint history feature by feature. The pattern was the same one I had seen on my own teams. The rework wasn’t concentrated in any one engineer or any one type of work. It was distributed evenly, and it was always tied to the same shape: a question that needed an answer before the build could go right, and an answer that came back six hours later, when the build was already heading somewhere wrong.
I added it up. The total rework cost, in developer hours, was close to $80,000. The savings from the Argentina team’s lower hourly rate, compared to hiring four equivalent engineers in Austin, was about $30,000.
She had spent $50,000 more than she would have spent on a local team. And she felt like she’d saved money.
What I started calling it
After that review, I started using a name for what I had been observing: the Correction Clock.
The clock isn’t about hourly rate. It’s about feedback velocity, how fast a wrong assumption can be caught, and how many wrong-assumption hours get burned before the correction arrives. An engineer at $40 an hour working six hours in the wrong direction costs $240 in wasted time, not counting the rework. An engineer at $70 an hour who catches the misalignment in two hours costs $140. On any given day, in any sprint with real ambiguity, the cheaper engineer was more expensive.
That math doesn’t always work the same way. When requirements are genuinely clear and the work is well-defined, the timezone gap shrinks as a cost factor. There are categories of work where an offshore team at a large offset makes obvious economic sense, and I’ve used that model effectively. But most software development, in most growing companies, is not that kind of work. Most software development is navigating ambiguity in real time. And navigating ambiguity in real time requires being able to ask and answer questions in real time.
The Correction Clock doesn’t stop running because you’re not watching it.
The relational half nobody costs in
The structural half of the clock is what people try to solve with meeting schedules, async-first policies, and overlap windows. Those work, within limits.
The relational half is subtler, and the half most managers miss. The speed at which a question gets asked is not the same as the speed at which the question gets answered. If an engineer doesn’t feel safe enough to flag a misalignment, the question is never asked at all. It becomes an assumption, which becomes code, which becomes a feature reworked in week four.
Manisha Sahni, who had run a team across six time zones for several years, described it to me on the podcast: the teams that function best across distance are the ones where engineers know each other as people, not as roles. When you know someone as a person, you send them a quick message saying “I’m not sure about this.” When you know them as an avatar in your project management tool, you make an assumption and keep moving.
The clock runs slower on teams where people know each other. Not because they’re better engineers. Because the question gets asked faster.
How to measure it
You don’t need new tooling. You need one habit.
For the next ten things your team builds, write down two dates: the date the work began, and the date someone first noticed a meaningful misalignment with the original intent. The gap between those two dates, averaged across the ten, is your Correction Clock.
Under one day: you have a healthy team and a tight feedback loop. Under three days: normal. Over a week: a structural problem no amount of process documentation will fix, your team has lost the ability to detect its own drift.
What the clock explains, and what it doesn’t
The Correction Clock explains the cost structure of timezone gaps when requirements involve real ambiguity. It explains why a team that looks cheaper on paper can be more expensive in practice, and why some of the best distributed teams I’ve worked with have spent heavily on nearshore presence and relationship-building. The investment looks like overhead. It’s actually a reduction in rework.
The clock doesn’t explain every case of rework. If your product team genuinely doesn’t know what it wants yet, no amount of feedback velocity will save you, that’s a different problem. The clock also doesn’t tell you the right timezone offset for your team. Some teams run well at twelve-hour offsets. Some fall apart at four. What changes is the surrounding factors, not the offset itself.
The clock runs at the same speed everywhere. What you’re controlling is how often it costs you.