The reality

A founder runs a 30 person fitout business and has the same problem at every project: the materials list from the design team does not match the order list from procurement, which does not match the delivery list from the site team. Every project has at least one variation order, one wrong delivery, and one missed deadline because of the mismatch. The team has been working around it for three years. Each project, the senior coordinator manually reconciles the three lists at week two, catches roughly 80 percent of the gaps, and the remaining 20 percent become the variations and missed deliveries the founder pays for at project close. The founder has fixed individual symptoms (the wrong delivery, the missed deadline) hundreds of times. The founder has never fixed the system that produces them. The cost across three years is an estimated AED 320,000 (USD 87,150) in variations, missed deadlines, and senior coordinator time spent reconciling. The same fix, applied to the system once, would have cost two weeks of work and saved the rest. Continuous improvement means fixing the system that produces the problem, repeatedly. Not a slogan.

Read this if

The team encounters the same problem at every project, every quarter, or every month
The founder has personally addressed the same kind of issue more than five times in the last six months
A senior team member has built a personal workaround for a system gap that has never been fixed
A new hire's first 90 days surface problems that the existing team has stopped flagging
The team has stopped raising operational issues because they have learned the issues will not be fixed
A monthly or quarterly retro happens and produces no system changes

What dysfunction costs

Recurring cost. A problem that recurs every project costs the business the cost of the problem multiplied by the number of projects. Across two or three years, the cost of a single unfixed system gap can exceed the cost of three or four senior team members.

Workaround cost. A senior team member who has built a personal workaround is producing the right output through the wrong path. When that team member leaves or is on leave, the workaround collapses and the system gap surfaces. The cost is paid as a crisis at the moment the team member leaves.

Trust cost. A team that has flagged the same problem three times and seen no system change stops flagging. The founder loses the early warning system the team would otherwise provide. Future problems surface later, when they are more expensive to fix.

Hiring cost. A new hire onboarded into a business with normalised workarounds spends the first 90 days learning the workarounds before they ever touch the actual work. The cost is the ramp-up time, plus the loss of the hire's outside perspective on the system gaps the existing team has stopped seeing.

What success looks like

When continuous improvement is a discipline:

A monthly retro reviews the recurring problems of the last 30 days and produces at least one named system change per month
Recurring problems are categorised (process gap, role gap, tool gap, skill gap) so the right kind of fix is applied
Each system change has a named owner, a defined deadline, and a follow-up review at 30 and 60 days
Workarounds are surfaced systematically rather than discovered when they collapse
A new hire's first 90 day observations are captured and reviewed as system improvement input
The founder can name three system changes shipped in the last quarter that produced measurable outcomes

The framework

Continuous improvement runs as four layers that move from symptom to system, repeatedly.

Layer 1: Surface the recurring problems

Every month the senior team lists the problems that recurred in the last 30 days. The boring repeating ones. The materials-list mismatch. The invoice cycle that always slips by 10 days. The same client conversation that the founder has to handle every month.

The list goes on a single page. Each item gets a frequency (how often it happened in the last 30 days), an estimated cost (in money, time, or trust), and a category (process, role, tool, skill).

The behaviour to adopt this week: ask each senior team member for their list. Combine into one page. Notice which problems appear on multiple lists.

Layer 2: Diagnose the system gap

For each top recurring problem, the team runs a 5 Whys diagnosis. Why did the materials list mismatch? Because procurement did not have the latest design version. Why? Because design does not version-control the materials list. Why? Because the materials list lives in a Word document on the design lead's laptop. Why? Because there is no shared system. Why? Because nobody has owned setting one up.

The 5 Whys takes 20 minutes. It produces a different fix than fixing the symptom would. The fix targets the system gap. The project where the symptom appears is the cost site. The fix lives upstream.

The behaviour to adopt this week: pick the top recurring problem. Run the 5 Whys with the senior team. Notice where the chain ends.

Layer 3: Ship the system change

The system change has a named owner, a defined deadline (usually 30 to 60 days), and a follow-up review at 30 and 60 days. The change is small enough to ship and large enough to make a difference. A shared materials list system. A defined invoice approval workflow. A standing rule that any client request above a threshold escalates to the founder before the senior team commits.

Shipping is the work. A perfectly designed system that does not ship changes nothing. An imperfect system that ships and gets refined produces improvement.

The behaviour to adopt this week: take the top diagnosis from layer 2. Define the system change. Assign owner and deadline. Ship in the next 30 days.

Layer 4: The monthly retro

A 60 minute monthly retro with the senior team. Standing agenda: review the recurring problems list from last month, review the system changes shipped (did they work, what is still broken), surface the new recurring problems for the next month, ship one to two new system changes.

The retro is short, structured, and ends with named actions. The discipline is the cadence. A retro that runs for one month and stops produces no improvement. A retro that runs every month for a year produces 12 system changes, which is enough to meaningfully change the operating reality of a 30 person business.

The behaviour to adopt this week: schedule the first monthly retro. 60 minutes. Standing agenda. The senior team comes prepared with their last 30 days of recurring problems.

A founder you might recognise

A founder runs a 32 person events business in JLT. AED 12M (USD 3.3M) last year. Through 2024 and 2025 the team had been running quarterly retros that produced long lists of complaints and very few changes. The senior team had stopped surfacing operational issues because they had learned the issues did not get fixed.

In Q1 2026 the founder shifted the retro to monthly with a different structure. Each senior team member came with a list of problems that had recurred in the last 30 days, with frequency and estimated cost. The senior team picked the top one or two. They ran the 5 Whys diagnosis. They shipped one system change with a named owner and a 30 day deadline.

The first month's change was a shared event production checklist that replaced four separate documents the different functions had been maintaining. The second month was a defined client briefing template that closed the gap between sales-stage commitments and delivery-stage planning. The third month was a finance approval workflow that closed the invoice cycle gap.

By the end of Q2 2026 six system changes had shipped. The senior team reported the retro feeling worth attending. The recurring problems list was getting shorter. The estimated annual cost saving from the six changes was AED 280,000 (USD 76,250) in reduced rework, faster cash collection, and senior team time freed up. The cost had been six hours of senior team time spent on the retros. The output had been a business that was actively repairing itself.

Working through it

Run the recurring problems exercise with the senior team. Each person lists the problems that recurred in the last 30 days. Frequency, cost, category. Combine into one page.
Pick the top one or two recurring problems. Run the 5 Whys for each. The diagnosis ends at the system gap underneath the symptom.
Define the system change. Named owner. 30 to 60 day deadline. The change is small enough to ship and large enough to matter.
Schedule the 30 and 60 day follow-up reviews. Did the change ship? Did it work? What is still broken? Refine.
Install the monthly retro cadence. 60 minutes. Standing agenda. Recurring problems, system changes, named actions. The cadence is what holds the rhythm.

Common mistakes

Fixing the symptom instead of the system. A wrong delivery fixed once is a wrong delivery handled. A wrong delivery fixed every project is the system that produces it not getting addressed.
Running the retro and producing no changes. A retro that produces a list and no shipped changes trains the team that the retro is theatre.
Letting the change owner be "the team". A team owner is no owner. A named individual with a deadline is what produces a shipped change.
Skipping the follow-up reviews. A change that ships and is never reviewed drifts back. The 30 and 60 day reviews are what hold the change.
Letting the recurring problems list grow without ever shrinking. A list that only grows is a list nobody reads. Items come off as they get fixed.

Self-assessment

Y or N for each.

Does a monthly retro happen with the senior team that produces at least one named system change per month?
Are recurring problems surfaced systematically with frequency and estimated cost?
Is each system change owned by a named individual with a defined deadline?
Are 30 and 60 day follow-up reviews scheduled for each change?
Has the founder shipped at least three system changes in the last quarter that produced measurable outcomes?
Are workarounds surfaced and addressed before the team member who built them leaves or is on leave?
Does the senior team experience the retro as worth attending, with a track record of shipped changes behind it?

Five or more "yes" answers means continuous improvement is doing the work it is supposed to do. Three or four is the band where the rhythm exists in part but the discipline of shipping has not taken hold. Two or fewer means the same problems will recur next quarter, with the same costs the business has been carrying for years.

Continuous Improvement