The Knight's Armor

The Rusty Suit

Don Quixote spent days restoring his grandfather’s armor. He hammered out dents, polished plates, fashioned an elaborate visor from cardboard and iron. By the time he strapped it all on, he could barely turn his head. Walking was a negotiation with gravity. Running was out of the question.

The armor was supposed to protect him. It did the opposite—it made him slow, rigid, and vulnerable to anyone who could simply step aside.

Sancho wore a tunic and carried a blanket. He could run, duck, climb a fence, change direction mid-stride. When trouble showed up, Sancho moved. Quixote clanked.

But the armor was only the beginning. Quixote also carried the code of chivalry—an invisible weight of rules, rituals, and obligations he followed without question. A knight must fast before battle. A knight must accept every challenge. A knight must defend every lady’s honor, even if the lady objects. The code told him what to do in every situation, which meant he never had to look at the situation itself.

Two kinds of burden: the process that weighs you down, and the doctrine that thinks for you. Both are traps. Both show up in product management more often than we’d like to admit.

Act 1: The Weight of Process

I’ve watched teams suffocate under processes originally designed to help them. Each layer was added for a reason. None were ever removed. And over time, the cumulative weight became the primary obstacle to getting anything done.

The approval chain is a common culprit. Every decision needs sign-off from five stakeholders who each have different calendars and different priorities. By the time consensus is reached, the market window has closed. The process that was supposed to reduce risk has introduced the biggest risk of all: being too slow to matter.

Then there’s ceremony overload. Sprint planning, sprint review, sprint retro, backlog grooming, daily standups, weekly syncs, monthly reviews, quarterly planning. Add them up and you might find that a third of the team’s week is spent talking about work rather than doing it. No single meeting is the problem—the accumulation is.

Documentation shields are subtler. “We need to document everything for future reference” sounds responsible until you notice the documentation takes longer than the work itself, and the last person to open the confluence page was the person who wrote it. The shield protects no one.

And then there’s the risk mitigation fortress—every change requiring a risk assessment, a rollback plan, a contingency strategy, and sometimes a sign-off from legal. A two-day task becomes a six-week project. The organization has optimized for preventing mistakes at the cost of preventing progress.

Each of these started as a reasonable idea. A bad launch led to a review process. A miscommunication led to a documentation requirement. A missed dependency led to a new approval step. Layer by layer, the armor built itself. And nobody noticed when the protection became the problem.

The overhead test

Every hour spent on process is an hour not spent on product. That’s not an argument against all process—it’s an argument for treating process as a cost that needs to justify itself.

Try this: pick a recurring ceremony and cancel it for two weeks. Don’t make an announcement about it. Just skip it. If nothing breaks and nobody notices, it was armor. If something genuinely suffers, bring it back—but now you know its actual value, not its theoretical one.

Speed as safety

Quixote believed armor made him safe. Sancho understood that the ability to move quickly was better protection than any plate steel. The same principle applies to product teams. Fast feedback loops—ship small, learn fast, adjust quickly—are safer than heavy review processes that slow everything down. A team that ships weekly and course-corrects will outperform a team that ships quarterly after exhaustive review, because the weekly team encounters reality more often.

Adding process only when it hurts

Sancho didn’t dress for weather he hadn’t encountered yet. He’d get cold, then add a cloak. He’d get rained on, then find shelter. Each addition responded to a real problem, not a hypothetical one.

The equivalent for product teams: only add process to solve a specific, current pain. Not a pain you imagine might happen. Not a pain another company told you about at a conference. Your pain, right now. If you can’t name the incident that created the need, question whether the need exists.

Act 2: The Code That Binds

Process weight is visible—you can count the meetings, measure the approval time, tally the documents. The second trap is harder to see, because it disguises itself as best practice.

Don Quixote followed the code of chivalry to the letter. He fasted before battle even when fasting left him too weak to fight. He defended a lady’s honor even when she hadn’t asked and didn’t want it. He accepted a challenge from a windmill because the code said a knight never backs down. The rules were more real to him than the situation in front of his face.

Product management has its own codes of chivalry, and we follow them with similar devotion.

Agile orthodoxy insists on a daily standup even when the team is three people sitting next to each other, already talking constantly. Fifteen minutes of repeating what everyone already knows, performed because the methodology says so.

Framework worship takes the form of RICE scores applied with false precision—guesses for Impact multiplied by guesses for Confidence divided by guesses for Effort, producing a number that feels rigorous but is built entirely on assumptions. We’ve added math to our hunches and called it a system.

OKR religion demands that everything ladder to a Key Result, which means the bug frustrating 40% of users sits in the backlog because it doesn’t fit neatly into a quarterly objective. The framework has overridden the team’s judgment about what obviously matters.

And then there’s the pilgrimage to someone else’s org chart—a 30-person startup reorganizing into tribes, squads, and guilds because Spotify did it. Never mind that Spotify had 4,000 employees and a completely different set of problems. The model is borrowed wholesale, context ignored, because the code says this is how modern product organizations work.

In each case, the methodology has replaced thinking. The team follows the practice and stops asking whether the practice fits.

Borrow, don’t belong

Sancho picked up useful habits from Quixote—courage, persistence, a willingness to take the road less traveled. He left behind the useless ones—fasting before battles, fighting windmills, swearing oaths to peasant women reimagined as princesses.

The same principle applies to methodologies. Take the retrospective from Scrum if retrospectives help your team improve. Take continuous delivery from Lean if frequent releases reduce your risk. Take customer interviews from Design Thinking if you need to understand your users better. But don’t adopt an entire framework as an identity. The moment you say “we’re a Scrum team” instead of “we use some Scrum practices,” you’ve crossed from pragmatism into orthodoxy.

Results as the only doctrine

Sancho judged everything by a single standard: does this help us get to the next town alive? He didn’t care which book recommended a practice or which famous knight endorsed it. He cared whether it worked, here, now, for them.

If a practice isn’t contributing to better outcomes—faster shipping, happier users, clearer decisions—it doesn’t matter how many thought leaders recommend it. Drop it and try something else. The methodology won’t be offended.

When Armor and Code Combine

These two traps often coexist, and they reinforce each other. Heavy process creates the need for a framework to manage the process, and the framework adds its own rituals, which add more process. A team drowning in approval chains adopts Scrum to bring structure to the chaos—and now they have approval chains plus sprint ceremonies plus Scrum-of-Scrum meetings. The armor gets heavier. The code gets longer.

Watch for these signals:

• Meetings about meetings—planning the planning, retros about the retro process.
• Defending practices you can’t justify beyond “that’s how we do it” or “that’s what the framework says.”
• Approval chains longer than the work they govern—three weeks of review for two days of code.
• Guilt about skipping ceremonies, as though missing a standup is a moral failure.
• Copying another company’s process without adapting it to your context, team size, or stage.

If you recognize three or more of these, you’re likely carrying both burdens—process weight and methodological dogma—simultaneously.

The process audit

Before your next planning session, run through this checklist for every practice, ceremony, and process your team follows:

• I can name the specific problem this practice solves for our team right now
• If we stopped doing this tomorrow, something concrete would break
• We adopted this based on our context, not because a book or company recommended it
• Our situation hasn’t changed significantly since we started doing this
• The time it costs is justified by the value it delivers

Any unchecked box is worth a conversation. Two unchecked boxes is a strong signal. You might be wearing armor you don’t need, or following a code that doesn’t fit your quest.

This Week’s Experiment

Pick one from each act and try them before Friday.

From Act 1—lighten the armor:

1. Cancel one recurring meeting for a week. Don’t announce a policy change—just skip it. See if anyone notices. See if anything breaks.
2. Ship one small change with half the usual approvals. Take the shortest path from decision to deployment. Note what you skipped and whether it mattered.
3. Archive one process document nobody has opened in 90 days. Put it somewhere retrievable. See if anyone asks for it.

From Act 2—question the code:

1. Take one practice your team follows religiously and ask: “What specific problem does this solve for us right now?” If no one can answer concretely, run without it for a sprint.
2. Identify one framework element you adopted from another company. Write down three ways your context differs from theirs. Decide whether the practice still makes sense.
3. Find one decision that’s stuck because it doesn’t fit neatly into your prioritization framework. Make the decision based on judgment instead. See what happens.

If none of these experiments feel safe to try, that itself is a diagnosis. The armor is too heavy, and the code is too rigid.

Traveling Light, Thinking Clearly

Sancho finished the adventure. He survived bandits, enchantments, beatings, and the general chaos of following a man who believed windmills were giants. He survived because he could move when he needed to and think when the situation demanded it.

Quixote had the armor and the code—and he kept getting knocked off his horse.

Your processes should be light enough to carry and flexible enough to drop. Your methodology should be a toolkit you reach into, not a religion you convert to. Strip what slows you down. Question what tells you to stop thinking.

The road is hard enough without dragging rusty armor and an ancient rulebook behind you.

Put this into practice

Run the process audit with your team this week—five checkboxes per practice, honest answers only. The Decision Log helps you track what you keep, what you cut, and what you learn from both.

Get the Template →