Please like ❤️ and restack 🔁 this article so others can find it, too. Thank you!
In 1944, the CIA published a classified manual on how to destroy an organization from the inside.
No explosives. No special training. No risk of detection. Just ordinary people, in ordinary roles, doing ordinary things slightly worse than they needed to. They called it “simple sabotage.” It was designed for occupied territories and enemy regimes.
It reads like your last all-hands meeting.
That is the uncomfortable part. Not that someone is deliberately sabotaging your product org. Almost certainly, nobody is. But when you read the specific behaviors the OSS prescribed to grind an enemy operation to a halt, something clicks. You have seen this. You have sat in this room. You may have done some of this yourself, without ever realizing it had a name.
The effect is the same whether the sabotage is intentional or not. Decisions slow to a crawl. Good people burn out and leave. Momentum dies quietly, meeting by meeting, approval by approval, committee by committee. And everyone wonders why it is so hard to just ship something.
Here is where it happens.
In the meeting room
The conference table is where most organizational sabotage takes place. It does not look like sabotage. It looks like due diligence, stakeholder alignment, and responsible governance.
Everything through channels. Requiring three levels of leadership sign-off before a PM can speak to a customer. Discovery dies before it starts.
Committee capture. Routing every roadmap decision through a cross-functional steering group that meets monthly and decides nothing.
Approval multiplication. Legal, security, finance, and the VP all need to approve a two-week experiment that touches no customer data.
Re-opening settled decisions. Relitigating Q3 priorities in every Q3 sprint review because one stakeholder wasn’t in the room when the call was made.
Wordsmithing theater. Forty minutes debating whether the OKR says “increase” or “improve” instead of discussing what would actually move the metric.
Performative caution. Someone urging the team to “slow down and think this through” when the research is already six weeks old and the window is closing.
Irrelevant issue injection. A stakeholder derailing a prioritization meeting with a competitor feature they saw in a demo that has nothing to do with the quarter’s goals.
Speech-making. The executive who opens every product review with a ten-minute vision monologue before anyone can share actual progress.
The 1944 manual said it plainly: refer all matters to committees. Advocate caution. Bring up irrelevant issues as frequently as possible. It was written as enemy strategy. It describes Tuesday’s meeting.
In the manager’s chair
Management dysfunction is harder to spot. It wears the costume of leadership. These behaviors feel like rigor and accountability.
They are not.
Written order demand. Refusing to let engineering start until the PRD is formally signed off, even when the problem and solution are already aligned and documented.
Perpetual misunderstanding. A stakeholder who keeps asking for “just a little more clarity” as a way to avoid committing to any delivery date.
Unimportant work first. The most capable PM assigned to internal tooling cleanup while a real market opportunity sits without an owner.
Perfectionism on the wrong things. Demanding pixel-perfect designs for an admin panel used by three people while a broken onboarding flow ships to thousands of paying customers.
Unhelpful promotions. Promoting the loudest PM rather than the most effective one, then wondering why team dynamics deteriorate quarter after quarter.
Among individual contributors
Individual contributors, including PMs, are not just victims of dysfunction. They participate in it. Often without knowing it.
Strategic slowness. Always one more thing to validate before writing the spec. A permanent discovery-to-delivery bottleneck with a human face.
Skill hoarding. Senior PMs who never document their stakeholder context or domain knowledge, making themselves indispensable and their teams fragile.
Tool-blaming. Attributing every delivery problem to Jira or the sprint cadence rather than the conversation nobody is willing to have.
Fake compliance. Going through the motions of OKR-setting while privately treating the roadmap as a fixed feature list. The OKRs become theater from day one, and everyone knows it.
In the culture
Some sabotage operates at the level of morale. It is the slowest kind. Also the most damaging. By the time you notice it, the best people are already gone.
Watermelon reporting. Status decks that are green across the board until the week before a missed deadline, when everything turns red overnight.
Rewarding dysfunction. Celebrating the PM who heroically shipped at 2am while ignoring the PM who prevented the crisis through good planning three weeks earlier.
Rumor spreading. Leaking a potential reorg to the team before leadership has communicated anything, creating anxiety that kills focus for weeks.
Deliberate vagueness. Strategy kept vague enough that any outcome can be claimed as success and any failure blamed on someone else’s interpretation.
So what do you do about it?
The OSS manual worked because these behaviors are invisible from the inside. They feel normal. They feel careful. They feel like exactly the right thing to do given the constraints everyone is working under.
Naming them is the first move. Not to assign blame. To create a shared vocabulary for what is actually happening. When you can say “we are re-opening a settled decision” or “this is approval multiplication” and have the people in the room nod in recognition, you have already broken part of the spell.
The second move is harder. Ask yourself which of these you are doing right now. Not because you are malicious. Because the org rewards it. Because it feels safer than the alternative. Because nobody ever gave it a name until now.
Further Reading (it’s fun)
If you want to read this from an Engineering perspective, I highly recommend.
What I read
As usual, I will list some of the best articles I read on the Internet. I will keep a list of the best articles (currently >900) at https://www.digital-product-management.com. These are today’s picks:
How To Stop Losing the Best Evidence of Your Own Work: Document personal decisions, growth, and professional judgment during projects to improve performance reviews and career development.
Build to Learn vs. Build to Sell: Distinguish between using AI coding tools for rapid prototyping and discovery versus building production-grade software for commercialization.
Taste Over Haste: Creative vision and personal taste serve as the primary differentiators for designers in an era of AI-driven automation.
Benefits
Save 20 USD when subscribing to Proton: Secure, end-to-end encrypted email, calendar, drive and more.
Save 10% on the first month when subscribing to Krater.ai: Every AI You Need.
One Subscription.