The ‘Move Fast and Break Things’ Myth is Wrecking New Leaders

You’ve probably felt it. You step into the new role, the clock is ticking, and the pressure to prove yourself is suffocating. Everyone is watching to see if you’re worth the salary they’re paying you. The anxiety is real, and the urge to do something—anything—to show your impact is overwhelming.

So, you start wiggling things.

I saw this firsthand with a new CTO who came in like a whirlwind. Within days, he was migrating issue trackers, flipping staff to entirely new focus areas, and changing core workflows. He wasn’t fixing problems; he was desperately trying to prove he was in charge. He confused motion with progress.

The most dangerous thing a new leader can do is confuse motion with progress.

The standard advice tells you to have a “bias for action.” Move fast and break things, right? But when you’re new, moving fast without understanding the landscape isn’t brave. It’s reckless. You’re swinging a sledgehammer in a dark room full of load-bearing walls.

We assume the biggest danger for a new manager is moving too slowly and looking incompetent. That’s a lie we tell ourselves to justify our anxiety. The real danger is moving fast on things that look arbitrary to you, but are actually structural to the organization.

Most new leaders don’t change things because they’re broken. They change them because they desperately need to feel effective.

There’s an old principle called Chesterton’s Fence. It says you should never tear down a fence until you understand why it was put up in the first place. If you just see a fence in the middle of a field, it looks stupid. Why is this here? Tear it down. But if you don’t know it’s keeping the wolves out, tearing it down is a disaster.

In a new role, everything looks like an arbitrary fence. The deployment process feels clunky. The meeting cadence seems redundant. The tech stack feels outdated. Your instinct is to tear it all down on day one. But every single one of those things is a trade-off. Someone built that fence to keep a specific wolf out.

If you change things before you understand them, you will break something structural. And when you do, you won’t just lose momentum—you will lose the faith of your team. Trust is the currency of leadership, and uncalibrated action spends it faster than anything else.

Uncalibrated action doesn’t build trust; it erodes it faster than cautious observation ever could.

So, what’s the play? Calibrate before you accelerate. Your first job isn’t to change the system; it’s to map it. Find the load-bearing walls. Understand the trade-offs. Talk to the people who built the fences and ask them what wolves they were keeping out.

You can absolutely show impact early on. But that impact should come from understanding, not demolition. Make the small, reversible changes that prove you’re listening. Save the structural overhauls for when you actually know the blueprints.

You don’t prove your worth by how much you can tear down in your first month. You prove it by knowing exactly what to build next.

FAQ

Q: If I don't make changes quickly, won't my team think I'm useless?

A: No, they'll think you're observant. Your team knows their systems are messy. They respect someone who takes the time to understand the mess before making it worse. You can still make small, reversible improvements while you map the architecture.

Q: How long should this 'calibration' phase last before I start making real changes?

A: Long enough to identify the load-bearing walls. You don't need to map every single process, but you must understand the core trade-offs of the systems you intend to change. Once you know why the fence was built, you can start tearing it down.

Q: So I should just sit back and do nothing for three months?

A: Hardly. You should be aggressively learning, not aggressively breaking. There's a massive difference between active observation and passive complacency. Spend your energy mapping the system and building relationships, rather than swinging a sledgehammer blindly.

📎 Source: View Source