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 (spaghetti, tape, 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

Let me argue against myself before someone does it for me: familiarity is not a disease — it’s the asset you spent years buying. The engineer who’s lived in a codebase for three years navigates it at a speed no fresh-eyed newcomer can touch; his pattern-matching is usually right, which is the only reason it’s dangerous when wrong. And fresh eyes have their own failure mode, one this book already warned about: the newcomer who can finally see all the ugliness — and concludes, with perfect five-percent-free clarity, that the whole thing should be rewritten. You know where that ends. Her sight is real, but the weird branches she sees are not all rot; many are knowledge: the customer who called, the edge case that burned someone.

So the goal is not to trade experience for innocence, or to install permanent self-doubt. It’s a division of labor: let familiarity do what it’s good at (speed, navigation, instinct for where the bodies are buried) and let instruments do what it’s bad at — actually seeing. The pilot doesn’t distrust his hands because he flies on instruments at night. He just knows which conditions his eyes were built for, and which they weren’t.

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 twenty years, 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 defense’s best reframe is genuinely strong: suspension is a feature, not a bug. Scrum (the argument goes) is a steady-state cadence, never meant to govern a production fire — of course you drop the standup during an incident; you’d drop a regular meeting too. The framework organizes normal flow and gracefully yields to crisis management when crisis comes. Fair. But notice how much of software is the exception: the blocked dependency, the fuzzy requirement, the late veto, the collision are not rare storms; on the teams I lived through they were most Tuesdays. A method that governs only the calm intervals between the hard parts is governing the part that didn’t need governing. If you must remove your process for everything that’s actually difficult, ask what fraction of real work that leaves it managing.

Second, fairly: not every red sprint is Scrum’s fault, and I must not let the framework become the universal scapegoat. Sometimes the team genuinely under-delivered. Sometimes the estimate was lazy rather than impossible. Sometimes the dependency was foreseeable and someone dropped it. Blaming the process for human and organizational failures is its own evasion, and worse, it’s convenient, because “the process failed” indicts no one in the room. Several of this chapter’s four deaths were also leadership failures, ownership failures, communication failures. That’s my point, though, turned around: those are the failures that decide outcomes, and they are the failures Scrum is silent about. The framework isn’t guilty of causing them. It’s guilty of drawing the team’s eyes elsewhere — of being a detailed, busy, certified answer to questions nobody was failing on, while the questions that sank the work went unnamed because the map had no symbol for them.

Third, and sharpest: if the reason is people, isn’t your whole critique just “hire good people, and any process works“? I have to concede the core of it: a great team will succeed in spite of almost any process, and a broken team will fail inside the best one. People dominate. Always. But follow the concession one step further, because it doesn’t acquit the framework — it reframes the charge. If people decide outcomes, then the value of a process is how much it helps the people do the human work: surface the real requirement, resolve the cross-team conflict, grow the shared understanding, put decisions where the knowledge is. Judged by that standard, Scrum scores poorly, because it spends the team’s scarcest hours on ceremonies that organize the mechanical work while leaving every human tension exactly where it found it. A process can’t replace good people. But it can get out of their way and even amplify them, or it can tax them and misdirect them. That’s a real axis, and Scrum sits on the wrong end of it. For a junior team with no instinct for any of this, its mechanics can be a scaffold while the human skills grow; the trouble is the scaffold that’s never removed: teams that needed the human skills were sold a calendar instead, and everyone was certified in the calendar.

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.

The honest counterargument

The strongest reply is one I have to take seriously: management is a real, hard, valuable skill, and dismissing it as “a suit” is the engineer’s arrogance this book keeps warning against. True. Hiring, growing careers, navigating org politics to shield a team, handling the underperformer with dignity, the emotional labor of carrying people through a bad quarter: these are genuine skills, often harder than the technical ones, and the good engineering manager is precious. I am not saying management is fake or beneath engineers. I’m saying two narrower things: that it’s a different profession (so auto-promoting engineers into it wastes one talent and fakes another), and that technical decision-making specifically must not drift away from technical contact. A great people-manager who partners with an in-the-code technical leader is a fine structure — that’s the split done right, two real jobs held by two real specialists. The disease is the blind technical decider, not the existence of managers.

Second: not every senior developer can or should lead, and “PO should be a senior dev” can produce a brilliant coder who’s a disastrous product owner — no domain feel, no stakeholder patience, no personality (king, per above). The proposal isn’t “any senior dev“; it’s “a senior dev who also has the business knowledge and the human capacity,” which is a high and rare bar. Where that person genuinely doesn’t exist, a strong non-technical PO tightly paired with an in-team technical lead is the honest fallback (translation layer and all), and far better than forcing the wrong person into the fused role. I should also say that I have never seen the heresy practiced: every product owner I ever worked with was a middle manager, and when the developers had complaints, the stakeholders backed the manager. (How feedback travels between developers, middle management, and the floor above is a separate problem, and a big one; it is not this chapter’s.) The fusion is what I’d build. The fallback is what I’ve lived.

Third, the player-coach trap is real: ask one person to both lead and code and they often do both badly — the code blocks the leading, the leading fragments the code, and the “some coding” becomes either zero (drift) or too much (neglect). The balance is genuinely hard and context-dependent, and some weeks the right answer is to put the keyboard down. The principle is contact, not a fixed percentage — enough hands-on to stay sighted, not so much that the leading suffers. Anyone who gives you an exact number is guessing.

The honest counterargument

The obvious and serious attack: “grow your own process, no fixed framework, use judgment” is a recipe for chaos in the wrong hands, and most hands are the wrong hands. A junior team with no instincts, handed “figure it out from the work,” will figure out a mess: no rhythm, no reflection, decisions dropped, the strongest personality bullying the rest, and none of the guardrails a prescriptive framework provides for free. This is real, and it’s why I kept conceding that Scrum is genuine training wheels for teams without the muscle. The honest scope of my proposal: it’s for teams with enough experience and enough of the people chapters' health (safety, trust, a real decider) to run without rails; and for those teams, the rails are now a cage. A team without that maturity should earn its way to this, using lightweight structure as scaffolding while the judgment grows, removing rails as the muscle replaces them. “No framework” is a destination, not a starting line, and pretending otherwise would be its own dogma.

Second: this demands more, not less — and that’s a cost, not a feature, for many organizations. Scrum’s genuine virtue is that it’s teachable and uniform: you can staff a thousand-person org with interchangeable people who all know the ceremonies, and that legibility has real value at scale that “every team grows its own process” sacrifices. A large organization may rationally prefer a uniform mediocre process it can hire and audit against, over a sea of bespoke excellent ones it can’t. I think that’s usually the wrong trade, but it’s a real trade. The most honest version of my claim: most teams are smaller, and more capable, than the heavy uniform process assumes, and they’re paying its tax for a scale they don’t have. And a grown process has a cost the uniform one doesn’t: it lives in the heads of the people who grew it, and heads leave. You know what to do about that, and it applies here — write the answers down, rotate, never let the way of working become one more thing only Stefan understands.

And third, turn the weapon on this chapter, because no-dogma requires it: these seven principles can themselves become dogma. A team that rejects all up-front planning on principle, refuses any fixed iteration on principle, sneers at Scrum on principle — has just adopted my heresy as a new orthodoxy and learned nothing. If you find yourself defending “pay as you go” against a context that genuinely needs planning, you’ve made my framework into the cage. The only principle that survives contact with every context is the last one, and it forbids its own worship.

The honest counterargument

First and most important: some interruptions matter, and total unreachability is its own failure. A teammate blocked on you for an hour because you were in “deep focus” with everything off is not a productivity win: it’s you optimizing your own output by making yourself the queue everyone else waits in. Collaboration is real work, and a team where everyone defends their attention so totally that no one can reach anyone has stopped being a team. And for some roles — the on-call engineer, the lead, the person whose job is to unblock others — “turn everything off and disappear for four hours” is malpractice; responsiveness is their work, and honorable work. The resolution is rhythm, not walls: protected deep blocks and reliable available windows — unreachable for ninety minutes, then properly responsive, so colleagues know when they’ll get you — with the proportions set by what your role actually is this week.

Second, turn it on the chapter: rigid focus can become avoidance. “I’m in deep work, don’t interrupt me” is sometimes a defense of attention and sometimes a sophisticated way to dodge a hard conversation, an awkward collaboration, or the messy human parts of the job that don’t fit in a twenty-five-minute block. The hyper-optimized solo focuser who is unreachable, un-collaborative, and slowly becoming the obnoxious genius has mistaken a tool for a virtue. Attention is for doing the work that matters, and sometimes the work that matters is the interruption: the colleague who needs you, the conversation you’ve been avoiding behind a timer. Defend your attention fiercely; just be honest about whether you’re defending the work or hiding from it.

The honest counterargument

First, the necessary honesty: “balance” and “self-care” can become excuses for not doing hard things. The engineer who won’t push through a demanding stretch, who treats every effort as a threat to their well-being, who invokes “keeping my shit together” to avoid the difficulty that growth actually requires: that’s not health, it’s avoidance with a wellness vocabulary. Real accomplishment sometimes demands hard, depleting pushes; some seasons of a career or a project legitimately ask for intensity, late nights, real sacrifice, and that’s not a failure of balance. It’s life having seasons. The claim of this chapter is not “never work hard” or “never be tired.” It’s “don’t run permanently in the red, don’t treat the unsustainable as the baseline, and don’t sacrifice the foundations (sleep, body, people, meaning) on the altar of an output that won’t matter if you collapse.” Sprint when a sprint is real. Just don’t call a decade-long sprint a career.

Second, fairly: I am not a doctor, and this is not a health chapter. “Move your body, check your health, sleep” is the wisdom of a colleague, not a clinician, and real health, physical and mental, sometimes needs real professional help that no engineering book can provide. If keeping your shit together is beyond what sport and sleep and friends can fix (and for real conditions, it often is), the strong, un-heroic move is to get actual help, the same way you’d call in an expert for a problem outside your domain. There’s no shame in it; there’s only the same good engineering judgment you’d apply anywhere: know the limits of your own expertise, and route to the specialist when you’re past them.

And third: fulfillment is not constant, and demanding that work feel meaningful every day is its own trap. Even the best work has tedious stretches, grinding weeks, parts that are simply unpleasant. “The method must give fulfillment” is a judgment about the whole, over time — not a demand that every Tuesday sparkle. The test is the trajectory and the sum, not the moment; a job that’s fulfilling overall will still have empty days, and reading every empty day as proof the work is meaningless is the panic about drift, aimed at an afternoon. Judge the arc, not the afternoon.