The 90-Day Simplification Cycle:

Do Not Fix Your Business. Fix One Flow.

Ash Holliday
August 31, 2026

Table of Contents

Share this article

An applied SCALE cycle for founders and leaders who want to buy back their time, fewer workarounds, clearer ownership and less daily firefighting—without launching a transformation programme.

TL:DR

A 90-Day Simplification Cycle is a focused first use of the SCALE Cycle for founders, owners and senior leaders with the authority to change how their organisation works.

If growth has made the enterprise feel heavier, slower or more fragile—if too much depends on one person, routine decisions drift upward, or progress stalls without constant chasing—start with one value flow.

Use SCALE to define the future state, make the problem visible, assess what is creating the gap, test a proportionate intervention and embed what works.

The aim is not to fix everything in 90 days. It is to create evidence, reduce friction and decide the next best move.

The transformation trap

Most founders and leaders do not wake up and decide to make their enterprise complicated.

Complexity accumulates in more reasonable ways.

A customer, client or service user needs an exception, so you say yes.
A team member needs a fast answer, so you step in.
A process starts failing, so you add a meeting.
A spreadsheet no longer copes, so you buy a tool.
A decision goes wrong, so you add an approval.

Each response can make sense in isolation. The problem is what happens when those responses accumulate faster than the enterprise can absorb them. They become habits. Those habits form a new pattern. And that pattern can become the operating system.

Work becomes harder to see through the noise of busyness. Decisions become harder to make. The founder, owner or accountable leader becomes the place where context, judgement and exceptions go to be resolved. They can find themselves working in the enterprise more often than working on its future. The team works hard, but keeps reacting. Firefighting becomes another common pattern. The organisation looks busy, yet feels heavier to run than it did before.

This is the Complexity Wall: the point where accumulated complexity begins to constrain time, margin, decision-making, customer or service-user experience, capability, mission delivery and sustainable growth.

This pressure is not imaginary—and it is not limited to one market.

Regulation and administration are only part of the story. Inside an enterprise, unclear decisions, duplicated information, workarounds, unnecessary approvals and systems that no longer fit the work can create the same result: less capacity to serve well, improve meaningfully and lead with intent.

When leaders reach this point, the instinct is understandable.

They start a major systems project.

New software. New KPIs. New process maps. New reports. New meetings. New rules. New controls.

Six weeks later, they have added a transformation programme on top of the work they were already struggling to manage.

There is a simpler place to start.

Do not try to fix your business. Fix one flow for 90 days.

Planning is not the problem. Neither is software, measurement, process mapping or governance.

A growing enterprise needs appropriate systems. But adding systems before the enterprise understands the priority problem can treat visible symptoms rather than the conditions producing them.

Software, measures, process maps and governance may become part of the solution. The question is whether they are helping the enterprise change the condition that creates the problem—or simply adding another layer to manage it.

Before adding another tool, report, meeting or approval, the enterprise needs visibility, clear ownership, useful measures and reliable ways of working.

Start with the practical questions:

What problem and impact are we actually trying to solve?
Where does work really get delayed, duplicated or rescued?
Which person should make which decision?
What does a good outcome look like for the people we serve and the enterprise?
What evidence will tell us whether we have improved the situation?

Without those answers, another tool can become another place to update. Another meeting can become another interruption. Another report can become proof that activity happened rather than a trigger for better action.

The result is not better management.

It is more weight.

What a 90-Day Simplification Cycle is

The 90-Day Simplification Cycle is designed to avoid that pattern.

It is not a grand transformation programme. It is a focused SCALE cycle (figure 1 below) built around one important value flow: the route through which an enterprise creates, delivers or sustains value for the people it serves—while maintaining the capability and resources to keep doing so.

Figure 1: The SCALE Cycle

For a commercial enterprise, that might be lead to cash, quote to delivery or order to fulfilment. For a mission-led or public-purpose enterprise, it might be referral to support, application to decision, case intake to resolution, volunteer onboarding, grant administration or funding commitment to measurable impact.

The underlying questions are the same:

Does this flow improve the experience or outcome for the people we serve?
Does it help capable people do good work without unnecessary friction?
Does it use time, money, information and attention responsibly?
Can the enterprise sustain it without shifting delay, cost, risk or overload elsewhere?

A useful improvement does not merely make one team faster. It strengthens the enterprise’s ability to deliver value, enable capable people to do good work and remain viable, adaptable, resilient and sustainable over time.

This is the practical test of a Sustainable Enterprise.

The aim of a 90-Day Simplification Cycle is modest but powerful:

Create one cleaner flow that proves the enterprise can work with less friction and less leadership heroics.

That proof matters. It gives the team a shared experience of a different way of operating. It gives leaders evidence that simplification is not theoretical, and that meaningful improvement does not always require a major restructure.

Choose one value flow

A value flow is the path work follows as it creates, delivers or sustains value.

It is not necessarily a factory-style process.

In a service organisation, it may include conversations, decisions, information, handovers and expectations as much as it includes tasks. In a public-purpose setting, it may include eligibility, assessment, service coordination, accountability and outcomes. In a commercial business, it may include customer contact, quotation, delivery, invoicing and payment.

Examples include:

Lead to cash: A prospect makes contact, receives a response, is qualified, quoted, converted, invoiced and pays.
Quote to delivery: A customer agrees to the work, the team plans it, delivers it, manages changes and closes the loop.
Request to resolution: A customer, member, employee, supplier or service user raises an issue; the right person understands it, makes a decision and resolves it.
Referral to support: A person is referred, assessed, matched to appropriate support, receives the service and experiences an outcome.
Hire to productive team member: A candidate is recruited, onboarded, trained, given clarity and becomes able to contribute.
Order to fulfilment: An order is received, checked, prepared, delivered and confirmed.

A flow can also be a decision pathway.

For example: how a pricing exception is approved, how a customer complaint is escalated, how a case is prioritised, how a delivery issue is resolved or how a funding decision is made.

The test is simple:

Does this flow materially affect the people we serve, the enterprise’s capability, its sustainability or the accountable leader’s time?

If the answer is yes, it may be the right place to start.

Do not choose every problem

The first discipline of the cycle is restraint.

Your enterprise may have ten areas that need attention. That does not mean ten areas should be worked on at once. Not every problem is equally important.

Choose one flow that meets at least three of these criteria:

It directly affects the experience or outcome of people served.
It affects financial sustainability, funding assurance, timely payment or the responsible use of resources.
It creates recurring stress, rework, late nights or leadership intervention.
It relies on knowledge held across multiple stakeholder groups.
It crosses multiple people, roles, systems or handovers.
It is operationally critical: a significant interruption would materially disrupt the day’s work or service.
It happens frequently enough for the team to learn within 90 days.
The enterprise can influence it without redesigning the entire operating model.

These criteria do more than identify an irritating problem. They help identify where a better flow could create meaningful value across the enterprise.

A commercial business may begin with lead to cash when sales are healthy but invoicing and collections are slow. Another may start with quote to delivery when work is won but delivery is inconsistent, expensive or dependent on one experienced person.

A mission-led or public-purpose organisation might begin with referral to support when people wait too long for help, or application to decision when delay and unclear ownership are undermining trust and outcomes.

What not to choose

Do not choose:

Every business process or enterprise problem.
The loudest issue simply because it is loud.
A quick win that relieves a symptom but distracts from the priority problem.
A new technology purchase as the starting point.
A vague goal such as “improve operations”.
Multiple improvement streams that require the same people at the same time.

A quick improvement can still be useful when it creates capacity, reduces an obvious risk or tests an important assumption. Just do not confuse temporary relief with a solved system problem.

You are not choosing the entire enterprise to fix.

You are choosing one flow where a practical improvement can reveal the pattern underneath the friction.

The goal is not to prove how much needs fixing.

It is to make one meaningful part of the enterprise easier to run.

Run SCALE through the flow

Figure 2: UEM & SCALE Cycle

The 90-Day Simplification Cycle uses the SCALE cycle:

Simplify
Clarify
Assess
Leverage
Embed

SCALE is not a once-only, linear project. It is a continuous enterprise-learning and simplification cycle.

The stages describe the main jobs in the cycle. In practice, new evidence may send you back to Clarify. A test in Leverage may reveal that the original assumption was wrong. Embedding a change may expose a deeper structure or mental model that needs another round of learning.

That is not failure. It is the discipline of learning before adding another layer.

1. Simplify: simplify the view first

Do not begin by cutting people, products, meetings, technology or process steps. Begin by simplifying how you see the issue.

The UEM diagram in figure 2 above, is not asking you to diagnose every part of your enterprise today. It is a starting map: a way to look across the building blocks of the enterprise and notice where work is repeatedly becoming harder than it should be.

Start with the experiences people can already see.

You may be hearing that customers receive inconsistent information, team members are unclear about who decides, work keeps returning for rework, leaders are pulled into routine issues, or cash, capacity and confidence are under pressure despite everyone being busy.

You are looking for a recurring pattern, not an isolated bad day.

Use the UEM diagram and ask:

Where is the enterprise repeatedly creating confusion, delay, rework or dissatisfaction for the people it serves, the team or its leaders?

Common places to look include:

Vision, mission and purpose: People are busy, but cannot explain what the enterprise is trying to achieve, which trade-offs matter or what “good” looks like.
Products, services and experience: Customers, clients or service users receive inconsistent promises, exceptions multiply, delivery quality varies or the experience does not match the intended value.
Knowledge and systems: Information is difficult to find, lives in a few people’s heads, arrives too late to support a good decision or must be entered into several tools.
Communication: Teams repeat conversations, discover important information too late or rely on unnecessary meetings to compensate for unclear flow.
Leadership and teams: Routine decisions drift upward, capable people wait for permission, expectations are unclear or leaders become the permanent escalation point.
Financial engine and cash flow: The enterprise is busy, but margin, cash, funding confidence or resource capacity does not improve or may be in decline over a period of time.
Legal structure, governance and viability: Rules, reporting or approvals are unclear, duplicated or so heavy that they slow sensible decisions.

Do not try to solve the pattern yet.

Your job in Simplify is to choose one area worth understanding better.

Then set a future state. Define the priority boundary. Identify what must be protected while you improve the flow.

Ask:

What would better look like for the people we serve, the team and the enterprise?
Why does this matter now?
What is the most valuable issue or opportunity to address first?
What is within the boundary of this 90-Day Simplification Cycle?
What must we protect while we make changes?
What urgency, assumption, activity or noise is distracting us?

The output is not a detailed project plan.

It is a short, shared statement of direction.

For example:

Within 90 days, we want customised projects to begin with a clear, commercially viable and operationally realistic scope, so delivery teams can protect quality, margin and customer confidence without relying on founder intervention.

The key principle is:

Start by simplifying how you see the problem—not by immediately simplifying the enterprise.

2. Clarify: make the flow and problem visible

Now map the flow as it actually happens today. Not the policy-document version. Not the ideal version. Not the version that exists in the leader’s head.

The real version.

Ask the people who touch the flow:

What happens first? What happens next?
Where does work wait?
Where is information entered more than once?
Does information arrive too early or too late to support a better decision?
Where do people have to chase another person for an answer?
Where do customers, service users or other stakeholders experience delay, confusion or inconsistency?
Which steps exist because of a past problem that may no longer be relevant?
Which decisions are unclear, escalated or routinely overridden?
Does critical knowledge reside with only a few people—and what happens if they are unavailable or leave?
What assumptions are we making that may not be true?

You do not need a large process-mapping workshop. A shared one-page view of the flow and its visible friction is enough to begin.

Look for visible friction:

Long waits in the workflow.
Duplicate data entry.
Repeated information requests.
Unnecessary approvals.
Multiple tools doing the same job.
Handoffs with no clear owner.
Workarounds that have become normal practice.
Meetings held because nobody is confident enough to decide or confident the work will flow without them.

Then form a short Problem-and-Impact Statement.

A useful format is:

[Who] is experiencing [what problem] in [where or when], which is affecting [the people served, team, enterprise or leader outcome]. If unresolved, it will result in [specific consequence].

For example:

The delivery team is regularly starting customised projects with incomplete or commercially unrealistic scopes agreed during sales. This occurs most often on complex projects and affects delivery margin, project timing, customer confidence and leadership capacity because exceptions are escalated to the founder. If unresolved, the enterprise will continue to lose margin, overload its most capable people and reinforce the belief that the founder must personally control every exception.

The core question is:

What is happening, where, to whom, and why does it matter?

Clarify does not produce a perfect diagnosis. It creates a specific problem and impact worth assessing.

3. Assess: understand enough to make a sound next decision

Most teams can list many symptoms.

“We are too busy.”

“Clients keep changing their minds.”

“The handover is poor.”

“Everything takes too long.”

“People do not communicate.”

Those may all be true.

But they are not yet a diagnosis.

Assess means using evidence, observation and stakeholder insight to understand the conditions that are sustaining the problem. The aim is not to force every problem into one neat root cause. Enterprise issues can involve interacting causes, incomplete information, trade-offs and legitimate competing needs.

You might look at:

How long work waits at each stage.
Where requests get returned or reworked.
How often exceptions occur.
Which decisions repeatedly escalate.
Which customer, service-user, case or work categories create disproportionate friction.
Where the accountable leader is repeatedly pulled into the flow.
What people experience when work goes wrong.
Which rules, incentives, information gaps or assumptions make the pattern likely.

This does not require a data warehouse or a sophisticated dashboard.

Start with the evidence you have. Listen to the people doing the work. Watch the flow where it happens. Check a small sample of recent cases. Look for patterns rather than anecdotes.

Then ask:

Are we treating the recurring symptom—or what keeps producing it?

The answer might be a vague handover, an unclear customer promise, a decision that nobody owns, a capability gap, a poorly designed rule, a late information flow or a tool that obscures rather than supports the work.

The goal is not to find someone to blame. It is to understand enough to make a sound, proportionate next decision.

When evidence is insufficient, do not pretend certainty. Ask a better question, gather the next most useful evidence, adjust the boundary of the flow or run a proportionate experiment to learn more.

Move into Leverage when you understand enough about the problem, its impact, the likely causes or constraints and the material risks to make a sound next decision.

4. Leverage: test the smallest credible intervention

This is where many enterprises reach for the biggest intervention. A new platform. A restructure. A major hiring round. A new layer of approval. Sometimes those things are necessary. But they should not be the automatic answer.

Before adding, first ask whether the existing design can be simplified, clarified or stopped. A leverage point is a place where a proportionate change can create the greatest practical effect.

It might be:

A clearer customer or service-user qualification rule.
A simpler offer with fewer custom variations.
A defined decision right for a team leader.
A better handover between commercial and delivery teams.
A change to what information is collected at the start.
A customer communication that prevents avoidable follow-up.
A revised role or responsibility.
A simple automation after the process is understood.
The removal of a report, meeting or approval that adds no value.
A shared team understanding of the flow and what success looks like.

Ask:

Which change is most likely to close the gap without adding another layer or creating unacceptable harm elsewhere?

Then make the intervention testable.

A practical hypothesis format is:

If we [change, introduce, remove or redesign] X, then Y should improve because Z is the relevant cause or constraint. We will know it is not creating unacceptable harm if [side-effect indicators] remain within agreed limits.

For example:

If we introduce a 20-minute delivery review for customised proposals above an agreed threshold before the customer commitment is made, then scope changes after sale should fall within eight weeks, because the current constraint is missing cross-functional scope validation. We will know the change is not harming sales performance if quote turnaround and conversion remain within agreed limits.

Leverage is where the enterprise executes a bounded, learnable test in real conditions.

Pilot it. Observe it. Learn from it. Adapt it.

This is often the hard part. Do not seek perfection; aim for a pragmatic improvement that can be tested, learned from and strengthened. A useful intervention is not necessarily the biggest change. It is the smallest credible change that can test the team’s understanding of the problem and move the flow towards its future state.

5. Embed: make what works survive normal pressure

A change is not complete because it was agreed in a workshop or delivered as a pilot. It is complete enough to keep when it survives ordinary operating pressure. Embed means making a proven change the normal way the enterprise works.

That requires more than a new process, tool, template or dashboard. It may require clearer roles, decision rights, measures, information flows, capability, communication and leadership behaviour.

Ask:

Who owns the new practice?
How have we communicated Why the change is important?
What decision or behaviour needs to change?
What information do people need, and when?
What will help people use the new approach confidently?
Which useful measures will show whether it is holding?
Where might the old workaround return?
What would make the new practice easier than the old one?

Review the flow weekly. Keep the review short and useful.

Thirty minutes can be enough.

What did we observe in the flow this week?
What friction has reduced, returned or shifted elsewhere?
What decision is needed now?
What will we test, stop or clarify before next week?
Who owns the next action?

If the review cannot lead to a decision, a learning or a practical next step, simplify the review itself. Embed also means paying attention to the human side of change.

A technically sound process will not hold if people still believe the founder will override it, that raising an issue will attract blame, that speed matters more than quality, or that the customer must always be told yes.

The question is not only “What has changed?”

It is also:

What must people understand, believe, feel safe to do or stop believing—and why does that matter for this change to work as intended?

A practical 90-day rhythm

This is not rigid project management. It is a simple rhythm that gives an already busy enterprise enough time to set direction, see the flow, test a useful change and embed it under normal pressure.

Timing	SCALE focus	Practical Outputs
Days 1–14	Simplify and Clarify	A future-state statement, a defined cycle boundary, a one-page view of the flow as it really works, and a working Problem-and-Impact Statement
Days 15–30	Clarify and Assess	A shared view of the priority problem, evidence of patterns and impacts, one or two likely causal mechanisms or constraints, and clear learning questions
Days 31–60	Assess and Leverage	A proportionate intervention hypothesis, named owners, a small test plan, success
Days 61–90	Leverage and Embed	A real-world test, weekly learning reviews, adjusted intervention design, and the beginnings of an embedded normal practice
Day 90	Embed and return to Simplify	A decision to stop, adapt, retest, standardise, improve the same flow again, choose the next flow or enter a broader redesign cycle

The sequence is deliberately flexible. If you discover on Day 40 that your original problem statement was too narrow, go back to Clarify. If a test reveals that the presumed cause was wrong, return to Assess.

Looping back is not wasted effort.

It is how SCALE prevents a confident but poorly understood solution from becoming the next layer of complexity.

What success looks like

Success is not a perfect process map. It is not a glossy transformation deck. It is not a new software platform that nobody uses properly.

Success may look like:

Fewer handovers and less duplicate work.
Clearer ownership and decision rights.
Fewer workarounds and less rework.
Faster response, quoting, delivery, invoicing, payment, referral, decision or case-resolution times.
Better customer, service-user, member or stakeholder experience.
Better visibility of demand, capacity, risk or value.
Less leadership intervention and fewer emergency rescues.
A team that can see the next issue and solve it with greater confidence.
A flow that improves outcomes without shifting cost, delay, risk or overload elsewhere.

The core result is simple:

One cleaner flow that proves the enterprise can work with less leadership heroics.

That is the beginning of a Scalable Engine.

Not because one improved flow solves every challenge in the enterprise, but because it changes the organisation’s belief about what improvement can look like.

Instead of adding layers, the enterprise learns to define the future state, understand the flow, assess the real conditions, test proportionate changes and embed what works.

The aim is to make the complex simple—not to pretend a real enterprise is simple.

The risk of drifting back

A 90-Day Simplification Cycle will not fix every issue in your enterprise. It gives you a safer place to start: one important flow, one shared view of reality and proof that the organisation can work with less friction. The deeper work is learning how to repeat this across the operating system without adding back the complexity you have just removed. That is where founder and leadership mental models matter. If you have improved a flow before—only to watch the enterprise slowly return to workarounds, firefighting and extra layers—the issue may not be the process alone.

It may be:

The assumptions shaping decisions under pressure.
A leader who says yes to every exception can drift back into complexity.
A founder who wants freedom but remains the source of every important decision can recreate dependency.
A leader who reaches for more reporting and approvals can rebuild corporate bureaucracy inside a smaller enterprise.

A deliberately designed enterprise takes a different path. It develops leaders who can act, teams who can see the flow and systems that make the right work easier than the workaround.

This is the role of a Simplification Champion: not someone who makes the enterprise simplistic, but someone who continually challenges unnecessary complexity while protecting the complexity that genuinely creates value.

Read more about the assumptions that shape enterprise design in How Founder Mental Models Shape Your Enterprise.

Start with one flow

You do not need to launch a transformation programme this quarter.

You do not need to map every process.

You do not need to buy another platform before you understand the problem.

Choose one flow.

Simplify the view.

Clarify the problem.

Assess what is really creating the gap.

Leverage a proportionate intervention.

Embed what works.

Then return to Simplify and decide the next best move.

That is how a founder or leader begins to move from Daily Firefight to Scalable Engine: not by carrying more, but by making the enterprise clearer, easier to run and more capable of creating sustainable value without constant rescue.

Curious where your enterprise sits on the Complexity Wall? We have a Business Complexity & Scale Readiness scorecard. The Scorecard takes five minutes and gives you a clearer view of where complexity is constraining your business. This scorecard will help you identify your next 90-Day Simplification Cycle focuss.

Take the free 5 min
Business Complexity & Scale Readiness
scorecard.

This is only the starting point

If this article has helped you see that the issue may not be effort, people or one broken process—but the way the enterprise is currently designed to produce its results—then you are already asking the right questions.

Making the Complex Simple is my upcoming practical field guide for founders and leaders who want to understand their enterprise, reduce unnecessary complexity and build a business that can grow without consuming the people inside it.

Join the waiting list to receive the book first—and to follow the ideas as they are developed.

Join the
Making the Complex Simple
Waitlist

About the Author

Ash Holliday is the founder of Pragmatic People and a Simplification Architect who helps founder-led SMEs move from Daily Firefight to Scalable Engine. His systems-thinking work spans Defence, aviation, healthcare, government and 15+ industries; he also teaches Systems Thinking, Strategic Alignment and Leadership in the Adelaide University's MBA program.

Editorial and source notes

The Europe statistic refers to the European Commission’s 2025 Eurobarometer research on SMEs, start-ups and scale-ups.
The UK administration figure and Australian compliance figure should be linked to the final verified source pages in the website CMS or converted into endnotes before publication.
Maintain the existing Complexity Wall Scorecard CTA if this article continues to target founder-influenced SMEs as its primary conversion audience.
The article intentionally uses “enterprise” and “people served” as shared terms, while retaining customer, cash-flow and margin examples where commercially useful.