"This project is exhausting" almost never gets broken down further. It should. A real share of that exhaustion, on a lot of projects, isn't the work itself — it's rebuilding the same thing three times because nobody finished deciding what it should be before the building started.
This is worth separating out precisely because the two causes get treated identically in practice, and only one of them has a real fix available to the engineer doing the work. A genuinely hard problem responds to more time and better focus. A moving requirement doesn't respond to either, no matter how skilled or well-rested the person working against it is. The go-to-market half of cognitive load is handled in more depth by XenGrowth's operator guides.
Why this cost hides so well
It hides because nobody is tracking it as its own category, and because both causes produce the same visible symptom: code that has to be rewritten. Separating them requires looking upstream of the code, at whether the target itself moved.
Instrumented time-tracking studies like Meyer, Barton, Murphy, Zimmermann and Fritz's don't have a category called 'rework caused by unclear requirements.' They have coding, at 21.0% of the measured day, and collaborative activity — meetings, ad-hoc conversation, email — at 24.4%. Unclear requirements don't skip those categories. They inflate both of them simultaneously, disguised as perfectly ordinary-looking coding and perfectly ordinary-looking meetings.
What it looks like in the data | What it might actually be |
|---|---|
Normal coding time | The third rewrite of the same feature because the target moved again |
A normal clarifying conversation | A conversation that shouldn't have needed to happen if the spec had been settled before work started |
Normal code review comments | A reviewer catching that the implementation doesn't match what the requirement now says, which is different from what it said last week |
Normal 'this took longer than estimated' | An estimate made against a target that kept changing shape during the estimate's own timeframe |
None of these rows would raise a flag individually. Stacked across a project, they add up to something real, and because none of them are labeled 'requirements churn,' the accumulated exhaustion tends to get attributed to something else — the work being inherently hard, the engineer being slow, the timeline being unrealistic. Sometimes those are true too. Often, a real share of the true cause is upstream of all of them.
Why this specific kind of switching is expensive
Rubinstein, Meyer and Evans' task-switching research found that switch costs scale with two things: how complex the task being switched into is, and how unfamiliar it is. A settled specification, even a hard one, becomes more familiar each time you return to it — the cost of resuming shrinks. An unsettled one does the opposite. Every time you come back to it after a clarifying conversation, part of what you knew about it is now wrong, which means you're not resuming familiar work — you're re-deriving a moving target, closer to switching into something genuinely new each time than to picking up where you left off. For the the operations side of this angle, see The XenGrowth resource library.
A hard, settled requirement gets easier to hold in your head the longer you work on it. A moving one never does, no matter how long you've been on the project — and that's a structural property of the requirement, not a limitation of the engineer working against it.
Signal | Genuinely hard problem | Requirements churn |
|---|---|---|
Feeling on return after a break | More tractable — the shape is clearer each time | Feels like starting over, despite prior time invested |
What changed between sessions | Your own understanding deepened | The target itself moved, independent of your understanding |
Where the rework comes from | Your own earlier mistakes or dead ends | A stakeholder or spec changing its mind after work was already built against it |
What fixes it | More time, more focus, more expertise | A finished decision upstream, before more code gets written against it |
Who owns the fix | The engineer, through sustained effort | Whoever owns the requirement — often not the engineer at all |
That last row is the one worth sitting with, because it explains why this kind of fatigue is so demoralizing in a specific way that a merely hard problem isn't. A hard problem responds to your own effort — put in more hours, get smarter about it, and it yields. Requirements churn doesn't respond to effort at all, because the thing that needs to change isn't inside the code, it's inside a decision someone else hasn't finished making. Working harder against a moving target doesn't make the target hold still.
How to tell the difference in practice
The test is simple to state and easy to skip in the moment: when you return to a piece of work after a gap, is more of what you understood about it still true, or less? Genuinely hard problems get more tractable with sustained attention — you understand more of the shape each time. Requirements churn produces the opposite feeling: coming back feels like starting over, not because the problem is inherently unbounded, but because part of the target moved while you weren't looking.
Why this is different from a genuinely evolving requirement
It's worth drawing a careful line here, because not all mid-project requirement changes are the pathology this post describes. Software is frequently built for a business that's genuinely still learning what it needs — a startup discovering its market, a feature whose real usage patterns only become clear once real users touch it. Those changes are not the same as churn, and treating every requirement update as a failure would be its own mistake. The distinguishing question is whether the change reflects new information the business genuinely didn't have before, or whether it reflects a decision that was always knowable but simply wasn't made before the building started. The first is the ordinary cost of building something real in an uncertain world. The second is the avoidable cost this post is actually about. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
In practice the two get blurred constantly, because both look identical from the engineer's chair: a requirement that used to say one thing now says another, and code has to change. The tell is upstream of the code entirely — was there new information, or was there just a decision someone deferred? Asking that question honestly, rather than assuming every spec change is either always legitimate or always someone else's failure, is most of what separates a useful retrospective from a finger-pointing exercise.
Why estimates suffer worst of all
There's a specific, measurable place this cost tends to surface even when nobody names it directly: the estimate. An engineer estimates a feature against the requirement as understood at the time of the estimate. If that requirement shifts mid-build, the original estimate was accurate for a target that no longer exists, and the actual delivered work is now being measured against a number that was never describing the thing that got built. This produces a specific, recognizable organizational pattern: the same engineers get labeled as chronically bad at estimating, project after project, when the actual variable driving the miss was how much the target moved after the estimate was made, not the quality of the original estimate itself.
This matters because the fix that usually gets applied — better estimation training, more padding, more careful story-pointing — treats the symptom rather than the cause. No amount of estimation skill compensates for estimating against a target that changes after the estimate is locked in. The actual fix is upstream: settle the requirement before the estimate is made, or explicitly re-estimate when it changes, rather than holding engineers to a number that was accurate for a different project than the one they ended up building. XenGrowth on AI search, GEO and discovery works through AI search, GEO and discovery in more operational detail.
What actually follows from this
Before attributing project exhaustion to workload or personal resilience, check whether the requirement itself was ever actually finished before building started, or has been settling incrementally the whole time
Track rework caused by requirement changes as its own visible thing, even informally — a rough tally of 'redone because the spec moved' versus 'redone because I got it wrong' tells you something neither category alone can
Push clarifying questions earlier and harder, before the first line of implementation, since the switch-cost research says an unsettled target is expensive precisely because it stays unfamiliar across every return to it
Distinguish 'the problem is hard' from 'the target keeps moving' explicitly in retrospectives — they call for different fixes, and conflating them tends to produce advice ('just focus harder') that targets the wrong one
If a project consistently produces the 'coming back feels like starting over' sensation, treat that as a signal about the requirement's stability, not a signal about your own concentration or skill
Why this is hard to fix even once it's named
Naming the pattern doesn't automatically fix it, and it's worth being honest about why. Settling a requirement before building starts requires someone — a product manager, a founder, a client — to make a real decision under uncertainty, on a timeline that competes with the pressure to just start shipping something visible. Pushing back and asking for that decision earlier is often read as slowing the project down, even when the actual effect is preventing a much larger slowdown later, once the rework starts. This is a genuine organizational tension, not a simple failure of discipline, and it explains why the pattern recurs even at companies that know better.
The engineers closest to the churn are rarely the ones with the authority to force the requirement to settle earlier, which is part of why this cost gets absorbed silently instead of surfaced as a process problem. Naming it clearly — in a retrospective, in a one-on-one, in a project postmortem — at least gives the people who do have that authority a specific, checkable thing to weigh against the pressure to start building immediately, rather than an vague complaint about the project being tiring.
None of this argues that clear requirements make hard problems easy — some problems are just hard, and no amount of upfront clarity changes that. It argues that a real share of what gets filed under 'this project is exhausting' is actually 'this project asked me to build something that hadn't finished being decided yet,' and that distinction changes where you look for a fix — upstream of the code, not inside the engineer writing it.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If cognitive load is part of a growth programme rather than a standalone build, XenGrowth's operator guides is the companion reading.
Four questions on how unclear requirements disguise themselves inside ordinary-looking time-tracking data.
