The best case against this book

The honest counterargument

Am I telling you to never build infrastructure, never abstract, never invest ahead of need? No — and the strongest counterargument deserves daylight. Sometimes up-front design genuinely pays. Platforms that will host other teams' code, public APIs you can’t break later, data models that are brutally expensive to migrate: in those places, the cost of changing your mind later is so high that speculative design is the cheaper bet. Frameworks exist because someone generalized well. Tom Wujec’s marshmallow challenge (twenty sticks of spaghetti, a yard of tape, a yard of string, one marshmallow, eighteen minutes to build the tallest tower that stands) cuts both ways: kindergartners beat business-school graduates by building and rebuilding instead of planning, but nobody iterates their way into a bridge.

So the rule is not “never design for the future.” The rule is: the burden of proof sits with the complication. The future you design for must be named, specific, and likely — not a vibe. Most code, in most teams, is not a public API or a migration-proof data model. It’s application code that will be reshaped a dozen times before it stabilizes, and there, simplicity wins so often that it should be the default you have to argue your way out of.

The honest counterargument — at full strength

The evidence for diversity is real, and it attacks my anecdote precisely where anecdotes are weakest. Decades of research on group decision-making (Katherine Phillips' work is the place to start) keep finding the same uncomfortable pattern: homogeneous teams feel better and perform worse on complex judgment. They agree faster, and the speed is the problem: agreement arrives before examination. Diverse teams report more friction, lower confidence, more discomfort, and turn out to be more accurate, because someone in the room doesn’t share the default assumption and therefore checks it. My beloved one-look decisions? Some of them were compression. Some of them, statistically, were five similar heads making the same mistake in perfect unison, and a team that similar has no one positioned to notice. The comfort I remember as performance was partly comfort, full stop.

Monocultures ship their blind spots. A team of people who resemble each other builds products tuned to people who resemble them, and the defects are invisible from inside, by construction, because the familiar disappears from view. The industry’s catalog of facepalm failures (products that didn’t account for users unlike their builders) is largely a catalog of cohesive, comfortable, homogeneous rooms.

“Fit” is the laundered word for bias. The mechanism, and it’s not hypothetical: connection forms fastest along lines of resemblance, so a hiring process that selects on “would we connect?” silently selects on “are they like us?“, and every round of it narrows the gate. The candidate who’d have been excellent but didn’t get the movie quotes; the brilliant engineer at a different life-stage who failed the beer test by having a family to get home to. Each individually defensible “fit” decision compounds into a wall, and the people outside it are not randomly distributed. This is how exclusion actually operates in our industry — rarely as hostility, usually as comfort, hire by hire.

And the generational observation has a hard legal and ethical fence. Noticing that a past team clicked partly through shared generation is memoir. Hiring by birth year is age discrimination: illegal in most places this book will be read, and rightly, because “same energy budget” is the kind of phrase that has been used to throw experienced people away. The observation may explain history. It must not select futures.

The honest counterargument

The defense has real evidence, and it starts with history: those of us sneering at sprints from atop continuous delivery are standing on ground Scrum cleared. It broke the multi-year waterfall, normalized iteration, gave teams their first retrospectives and their first legitimate “no” to mid-sprint chaos. The two-week heartbeat was a radical shortening in its day — the small-batch logic, frozen at 2003’s frontier. Criticizing the dam is easy on a river that was straightened by the dam-builders.

Second: for a team with no discipline at all (no rhythm, no planning, no reflection, requirements arriving by drive-by shouting), Scrum installs a floor. Structure, cadence, protected focus, a forced conversation with stakeholders every two weeks. I’ve seen genuinely chaotic teams get visibly better in their first quarters of Scrum. Training wheels are a real technology. The argument of this part is about what happens when the wheels never come off, and about an industry that certifies the wheels and forgets the bicycle.

Third, the defense’s strongest move: that’s not real Scrum. The scoring-as-commitment, the standup-as-status-report, the zombie ceremonies — all “ScrumBut” (we do Scrum, but…), all violations of the Guide’s actual intent, which is empirical, lightweight, and humble. Perhaps. But I’ll enter now the reply the rest of this part will keep making: when a method is practiced “wrong” by the overwhelming majority of its practitioners, in the same direction, under the same pressures, for decades, the practice is the method. A design that reliably degrades into theater under ordinary organizational gravity is not a good design badly used. It’s a design that never accounted for gravity, and the next chapter is about what happens when the gravity really turns on.

The honest counterargument

The strongest reply comes from the opposite tradition, and it has real evidence: strong single deciders produce fast wrong decisions and fragile teams; the wisdom of the group, consensus, distributed decision-making — these aren’t naïve, they’re how the best engineering cultures actually run. I have to grant a lot of this. Important, irreversible, one-way-door decisions genuinely benefit from many minds, dissent, and time — ramming those through by fiat is how you get confident catastrophes. Consensus has a real domain, and the leader who decides everything alone is building both a bottleneck and a team of order-followers who’ve stopped thinking.

But notice I never argued for the leader deciding everything — I argued for someone able to decide when a decision is needed and not otherwise being made. The reframe is between reversible and irreversible decisions (the two-way vs. one-way door). Reversible decisions (most of them, especially in a small-batch world) should be made fast, by whoever’s closest, and corrected if wrong; agonizing over them in committee is the waste. Irreversible decisions deserve the group, the dissent, the time. The pathology isn’t “a leader decides” or “the group decides“; it’s applying the wrong mode: paralysis on the cheap reversible call (my day of nothing), or lone-fiat on the expensive irreversible one (the tyrant’s catastrophe). A good decider’s first skill is sorting which door they’re standing in front of, and then either moving fast or convening the room.

And the tyrant risk is real and must be fenced: authority fused with accountability, visible lines, the leader inside the team and subject to its trust, the safety for the team to push back, the no-yelling floor. A decider without those fences is just the informal-leader problem with a title. The argument is for accountable, visible, bounded authority — never for a throne.