Journal

I write about design, product growth, team facilitation and methods that enable and support self-managed teams (in short: teamwork), and occasionally AI.

Substack

Change takes at least six months. Or not.


Time to read:

3–4 minutes

It’s the unwritten rule among leaders: change takes six months. That’s partly true: organizations are built to preserve yesterday’s wins; they encode them in processes, incentives, and identity. Your new idea walks in, and the antibodies show up.

Sometimes the rule is wrong. When the right levers line up — and people already half-believe the new idea — the system jumps to a better state. Call it alignment.

Donella Meadows’ Leverage Points explain why timing varies. Not all interventions are equal; some touch the surface, others reset the core.

Small levers: quick, brittle

Tweak the dials; the system stays the same. This is the land of tool swaps, new dashboards, and the periodic reorg. It’s tempting because it’s fast, visible, and reversible — you ship this week and the line goes up. Then the system settles back. More cash or capacity buys calm, not direction. Faster cycles remove waiting, not confusion. Use small levers to buy time or signal, not to pretend the system has changed.

How to know you’re here: wins fade without constant push; metrics move before behavior; your calendar says “launch/rollout/all-hands” more than “decision/trade-off.” Stop pushing and it stops.

Durable levers: slower, compounding

Change the rules and routes; the system starts driving itself better. Here you change how decisions get made: who sees reality (information flows), what gets rewarded (rules), and who decides (self-organization with guardrails). It’s slower because trust, habits, and status need a few cycles to reset — but the gains hold. You also need to strengthen the balancing loops (error budgets, QA gates, spend caps) so the new behavior doesn’t melt under pressure. Give these changes a runtime longer than your slowest loop — maybe a hiring cycle, a product release, or a customer renewal — so you’re measuring reality, not noise.

How to know you’re here: people cite user signals unprompted; teams decide without escalation; quality holds after the fanfare; you delete meetings and nothing breaks. If you stop pushing, progress continues — sometimes it speeds up.

Transforming levers: slowest, decisive

Change the goal; the system rewires itself. This is where you rename what “winning” means (goals) and what counts as competence (mindset). From “ship fast” to “solve the right problems.” From “break things” to “build trust.” Everything else — roadmaps, meetings, promotions — reshapes to match. Done poorly, it’s slogan theater. Done well, you mourn the old story and see what’s next. Build reinforcing loops around the new aim — what you celebrate, promote, and fund — and pair them with brakes, so momentum compounds without drift.

How to know you’re here: zombie projects die; what gets celebrated changes; who gets promoted changes; debates shift from “how fast” to “which problem.” Some people opt out because the story no longer fits — that’s evidence, not failure.

Three rules of timing:

1 Built-in waits in your system set the timing. Think release cycles, approvals, onboarding, renewals. They set the clock. Change stays slow until feedback, learning, and social proof pass through those loops. It speeds up when information, rules, and goals align AND the culture doesn’t resist.

2 Capacity sets the pace. Buffers (time, attention, runway) determine how quickly new behavior can land. Buy time first (reduce WIP, add margin), then change rules.

3 Progress is less about speed, more about the right order of moves. Install brakes before engines: strengthen balancing loops (quality gates, SLOs, spend caps) before amplifying reinforcing loops (growth, incentives). Stage it: time/signal → rules → goals, or you get oscillation instead of progress.


If you’re pivoting (again): pick the most powerful lever you can influence, hold, and reinforce with smaller levers before the system snaps back. Name the delay. Run small, safe-to-fail experiments — not to optimize, but to learn the system’s structure. And don’t change the method while the signal’s still traveling.