Estimated reading time: 5 minutes
Not all work should move at the same speed.
Most organizations try to run transformation on the same clock that runs day-to-day operations. That sounds efficient, but it is exactly why transformation stalls. Business-as-usual runs on risk control, accuracy, and consensus. Transformation needs speed, bounded risk, and clear decision rights. When both run on the same clock, decisions queue behind operational work, priorities get re-opened, and teams wait for permission. The fix is not pushing harder. It is giving transformation a different clock: a cadence with faster decision cycles, explicit thresholds, and a clear escalation path. You are not accelerating people; you are designing a system where decisions close instead of reopening.
“Transformation is not about running the current business.
Michel Paquin
It is about changing it.“
Table of contents
There are two clocks in my kitchen
One is on the oven. One is on the microwave.
They never show the same time.
The oven is always three minutes slow. The microwave is always two minutes fast. And I never bother fixing either. I just adapt. If I’m cooking something sensitive, I use the timer. If it’s just reheating soup, I eyeball it.
Nobody is confused. We know which clock matters when.
It works because the clocks serve different purposes.
And every time I see that, I think about transformation work.
We treat all time as equal. That’s the mistake.
Inside companies, there is usually one clock: the business-as-usual clock.
It is designed for predictability, risk control, consensus, and quality. It is built to protect the business. It does that well.
But transformation is not about running the current business. It is about changing it.
When you try to run both on the same clock, something predictable happens:
Transformation gets pulled into the slow lane.
Not because people resist.
Not because teams are incompetent.
Because the system asks transformation decisions to move at the same speed as operational decisions.
And that speed is wrong for transformation.
Transformation needs a different cadence
Business-as-usual work is like a long freight train. It carries real weight. It should not turn quickly.
Transformation is more like a speedboat. It needs to change direction, test, learn, and correct fast.
Trying to drive a speedboat with freight-train controls is not discipline. It is friction by design.
When everything runs on one clock, transformation decisions queue up behind operational ones. The result is a constant restart loop:
- A decision is drafted.
- More information is requested.
- Stakeholders change.
- Priorities shift.
- The decision is reopened.
You are not moving slowly. You are reopening the same decision repeatedly.
That is not a people problem. It is a system design problem.
What’s really happening under the hood
Three hidden mechanisms create the drag:
1) Decision latency
Decisions wait for the next meeting, the next committee, or the next senior availability. Weeks pass without closure.
2) Approval loops
When ownership is unclear, everyone wants a say. That feels safe, but it creates long approval chains.
3) Risk misalignment
Transformation decisions are judged by operational risk standards. That means a “no” bias by default.
This is why your team can work hard and still feel stuck. The clock they’re running on is built to prevent movement.
The two-clock model (a practical frame)
You do not need to break your governance. You need two clocks.
Clock 1: Business-as-usual (BAU)
Purpose: protect stability
Speed: deliberate
Risk posture: minimize risk
Decision pattern: consensus, deep validation
Clock 2: Transformation
Purpose: enable change
Speed: fast iteration
Risk posture: bounded risk, not zero risk
Decision pattern: defined decision rights, rapid closure, time-boxed input
A simple way to install the second clock:
Decision rules for transformation:
- Time-box decisions (example: 10 working days max).
- Define who decides (single accountable owner).
- Limit reopens (only allowed with new material evidence).
- Escalation path defined in advance (who, when, how).
This is not chaos. It is controlled velocity.
When this does not apply
This model is not for everything.
If you are dealing with regulatory compliance, safety, or irreversible infrastructure, speed is not the goal. Those decisions should stay on the slow clock.
But for product launches, operating model changes, process redesigns, and digital programs, waiting for the slow clock is not safety. It is opportunity loss.
What to do this week
Do not start with a transformation charter.
Start with this:
- List your top five transformation decisions currently pending.
- Ask: which clock are they on right now?
- For each, define:
- Who decides
- By when
- What inputs are required
- What triggers escalation
If you cannot answer those four questions, the problem is not people. It is the missing clock.
FAQ
Isn’t faster risky?
Fast is risky only when it is unstructured. A faster clock with clear decision rights and guardrails is often safer than slow consensus, because decisions actually close and are not constantly reopened.
Why not just push teams harder?
Speed problems are rarely about effort. They are about decision flow. If decision rights, thresholds, and timelines are unclear, more pressure just increases frustration.
What if my organization is highly regulated?
Keep regulatory and compliance decisions on the slow clock. Use the fast clock for experiments, process design, customer experience changes, and technology pilots that do not introduce irreversible risk.
How do I know which clock to use?
Ask one question: “What is the cost of delay versus the cost of a wrong decision?” If delay costs more, use the fast clock with guardrails.
Executive takeaways
- One clock cannot serve two purposes.
- Transformation slows when forced into business-as-usual cadence.
- Design the system so decisions close, not reopen.
- Separate clocks reduce conflict and increase clarity.
More Reading
-
Most transformation delays are not caused by technology or lack of effort. They are caused by decisions that have no clear route, no defined owner, …
-
Transformation doesn’t slip because teams can’t deliver. It slips because decisions don’t close. Unclear ownership, vague guardrails, slow approvals, and informal exceptions quietly push timelines …
Michel Paquin is a Strategy and Management Senior Lead Consultant at Valtech, based in Montreal. He helps executive teams increase decision velocity by fixing the system around decision-making: governance, operating model, and the translation layer between strategy and delivery. He writes about business decision flows, transformation, and what actually makes change stick.
All new articles directly in your inbox? Subscribe to my Entreprise Transformation Newsletter
* Please note that I am unable to accept mandates outside of my engagement with Valtech.