Frederick Taylor’s scientific management rested on one design decision: separate planning from execution. Management decides what to do and why. Workers execute, without needing to know the why, because the why was never theirs to hold.
That’s the part everyone quotes when they invoke Taylor as a villain. It’s not the part that matters most.
Taylor’s method had a prior, harder step: send an engineer to study your best worker, time every motion, extract whatever tacit skill made that person good at the job, and write it into a procedure management could now own and hand to anyone. This is one of the cases where a non-technical background turns out to be useful.
Harry Braverman’s reading of this, still the reference point in labor-process theory, breaks Taylorism into three linked moves: dissociate the work from the worker’s own judgment, concentrate all the thinking in management, then use that concentration of knowledge to control exactly how the work gets done.
The worker’s disempowerment wasn’t the starting condition of the system. It was the payoff of an extraction that had already happened. Whatever else Taylor’s foremen were, they had actually gone and found out why, before they wrote the instruction card.
Software supposedly settled this argument in 2001. The Agile Manifesto was, among other things, an explicit rejection of the command-and-control model: cross-functional teams, shared ownership, the developer as participant in deciding what to build, not just how.
Most engineering leaders would say their org doesn’t work the Taylorist way anymore.
Open the ticket template anyway. Acceptance criteria, a field for the description, a field for the mockup link. No field for why. Definition of Ready checklists ask whether the ticket is estimable, not whether the reasoning behind it is legible to whoever picks it up.
This is the risk worth naming precisely: a team can genuinely reject Taylor’s org chart and still reproduce his worst move at the artifact level, the concentration of thinking in whoever wrote the ticket, without doing the extraction that was supposed to justify it, someone actually studying the problem closely enough to write the why down.
When that happens, the knowledge isn’t even centralized in management’s hands the way Braverman describes. It’s just gone, unextracted, sitting in one person’s head until they forget it or leave.
Some of this really is a competence problem
It would be convenient to say this is purely structural, that nobody’s actually at fault. It isn’t purely that.
Plenty of tickets are underspecified because whoever wrote them was rushed, or hadn’t thought it through, or assumed the obvious was obvious to everyone. That’s a real, ordinary, fixable failure of diligence, and no amount of systems thinking should excuse it.
But fix every one of those and a remainder is still left over, because Brooks made a narrower and harder claim than “write better tickets”: deciding precisely what to build is the single hardest part of a software project, harder than writing the code, and getting it wrong is more damaging and more expensive to correct than any other kind of mistake in the process.
If that’s true, no amount of diligence closes the gap completely, because full specification of “what to build” would require having already solved the problem the code exists to solve. Someone still resolves the leftover ambiguity at build time, and it’s whoever’s holding the keyboard, whether the earlier work was diligent or not.
What the missing field costs
The ordinary cost is invisible by design: a decision gets made once, the reasoning lives in one head or one closed thread, and every later reader of that code has to find that person, guess, or redo the reasoning from scratch.
A study on developers debugging unfamiliar codebases found that one of the persistent gaps wasn’t in the IDE or the tooling, it was that existing documentation and the code itself lived in separate places, so developers doing program comprehension work couldn’t use one while looking at the other. The intent usually wasn’t absent. It just wasn’t reachable from where the developer was actually looking.
DORA’s 2023 State of DevOps report offers a number worth being careful with: documentation quality doesn’t act alone, it multiplies the effect of other technical capabilities, amplifying the organizational impact of continuous delivery by 2.7x and continuous integration by 2.4x.
That measures documentation quality broadly, not “why” fields specifically, so treat it as a proxy, not proof. The mechanism it points at is still the one this argument depends on: legible reasoning makes existing capability worth more, not the other way around.
Incidents are where I’ll admit the evidence runs out and opinion starts. The Uptime Institute’s 2025 outage analysis found roughly 40% of organizations suffered a major outage from human error in the prior three years, 58% of those from staff not following procedure.
The report attributes the rise to staff shortages. It doesn’t ask whether the staff understood why the procedure existed before skipping it.
My own guess, and it is a guess, not a finding: a rule nobody can explain the reason for gets treated as friction to route around the moment it’s inconvenient, and that’s a different failure than incompetence, even though it gets logged the same way in a postmortem.
The counterargument, and why it doesn’t fully land
None of this means write everything down. A ticket padded with paragraphs nobody reads isn’t better than one with none, it’s the same failure with worse ergonomics.
Architecture decision records get written once and never opened again. This is a real failure mode, not a hypothetical one, and I don’t have a study to back the claim, just enough of them read secondhand from confluence graveyards to trust the pattern.
Where I think it still lands: the difference between context that’s discoverable at the point of the decision and context that exists somewhere, technically, if you know who to ask. That’s a judgment call on my part, not a measured distinction, but it’s the one the rest of this argument rests on, so it’s worth naming as opinion rather than dressing it up as more than that.
What changes, and what doesn’t
A habit fixes the gap at the ticket level: put the why next to the what, in the artifact people actually open, not in a meeting they weren’t in. That’s a small, real, achievable thing.
It is also not a fix for the structural problem this piece spent five sections describing. Taylorist artifacts persist because they’re cheap and legible to write, not because anyone chose them on purpose, and one team writing better tickets doesn’t change what the template defaults to for the next team.
The honest version of this piece’s advice is: this helps the team that does it, and it does nothing about the org chart underneath.
One more variable, new enough that most writing on this topic hasn’t caught up: AI coding agents now fill a growing share of the gap that used to fall to a human engineer filling in an underspecified ticket. That doesn’t make the why less necessary, it makes it more so.
A model resolving an ambiguous retry policy has less access to the tacit context a human engineer would have picked up by osmosis, in Slack, in a hallway conversation, and it will resolve that ambiguity with total confidence either way.
Writing the why down was always for the next person. It’s now also for the thing about to guess on your behalf at a speed no reviewer can fully audit, and unlike Taylor’s foreman, it never went and found out first.