Continuous Improvement: Core Work

Why this matters

Every business has problems. The ones that grow are not the ones with fewer problems. They are the ones that fix problems faster than new ones appear.

Founders with 10 to 80 staff often run on instinct. Something breaks, you fix it, you move on. That works until about employee 25. After that, the same problems start coming back. A client complaint you thought was sorted three months ago surfaces again. An onboarding step gets skipped for the fourth time. Your best project manager leaves and takes half the process knowledge with them.

The issue is not effort. You and your team work hard. The issue is that fixes stay in people's heads instead of being captured in systems. The ARCAS diagnosis maps this directly: the Behaviour audit catches repeated failure patterns, the Skills audit shows where capability gaps keep reopening, and the Five Levels model flags systems leakage when knowledge walks out the door with individuals.

Continuous improvement is a weekly practice with a specific structure, not a philosophy. Get the structure right and your team gets measurably better every month. Skip it and you stay on the treadmill.

A founder you might recognise

<!-- founder-review: confirm if this should be first-person witnessed -->

Last year, the founder of a facilities management firm in Abu Dhabi with 38 staff was running AED 7.2M (USD 2.0M) on maintenance contracts for commercial buildings across the city.

Every Monday, the founder opened WhatsApp to a stream of weekend complaints. A technician used the wrong sealant on a chiller unit. A supervisor forgot to log a safety check. A client received an invoice with last month's rates. The founder spent the morning putting out fires, then got back to actual work around 1 PM.

He once told the operations manager to "make sure this never happens again." She nodded, spoke to the team, and things improved for two weeks. Then the same pattern returned. The sealant issue came back with a different technician. The safety check was missed on a different building.

He was fixing symptoms. He never built the system that would fix the root cause once and prevent it from recurring. His WhatsApp was full of solved problems that kept un-solving themselves.

The improvement cycle for small teams

The Plan-Do-Check-Act cycle was designed for manufacturing floors, but the core logic applies to any service business. Here is the version that works for teams of 10 to 80.

Plan: Pick one problem. Write down what you think is causing it. Decide on one change to test. Assign one person to own it. Set a date to check the result.

Do: Make the change. Keep it small enough that you can reverse it in a day if it fails. Tell the team what you are testing and why.

Check: On the check date, look at the data. Did the problem reduce? Did something else break? Ask the person closest to the work what they observed.

Act: If it worked, make it the new standard. Update the checklist, the SOP, the Zoho workflow, whatever holds the process. If it did not work, write down what you learned and pick a different approach.

The founder behind ARCAS spent years applying Six Sigma methods at IKEA. The insight that transferred to small businesses was simple: the statistical tools are not what matters. What matters is the discipline of checking whether your fix actually worked. Most small teams skip the Check step entirely. They make a change, assume it worked, and move on. That is why the same problems keep returning.

The weekly review: 15 minutes that change everything

Hold this every week. Same day, same time. Standing up helps keep it short.

Who attends: The founder or GM, plus each team lead or supervisor. No more than six people present.

What you review:

• What went wrong this week that should not have gone wrong?
• Did last week's fixes hold, or did the problem come back?
• What is the one thing we will fix this week?

What comes out: A single action item with an owner and a check date, added to the improvement backlog. One thing, not ten.

The founder started this practice on Sundays at 8:15 AM. Within six weeks, the Monday WhatsApp complaints dropped by half. Problems had not disappeared. The team simply started catching them before clients did.

The monthly operating review

Once a month, the founder sits down for 60 to 90 minutes with the numbers. This is not the weekly stand-up. This is the strategic check.

What the founder reviews:

1. Revenue per employee compared to last month and the same month last year
2. Client complaints logged versus resolved (track the ratio alongside the count)
3. The improvement backlog: how many items were added, how many were closed
4. Any process that broke more than twice in the month (pattern detection)
5. One metric specific to your business (for this founder: first-time-fix rate on maintenance calls)

What data you need: A simple Excel sheet or Zoho report with the numbers above. If you do not have the data, that itself is the first item on your improvement backlog.

What decisions come out: Where to invest next month's improvement effort. Whether to promote, train, or reassign someone. Whether a process needs a full rebuild instead of another patch.

Running retrospectives that produce change

A retrospective is a structured conversation after a project, quarter, or incident. The goal is not to vent. The goal is to leave the room with one or two changes written down and assigned.

The format that works for small teams (45 minutes):

1. What happened: State the facts. No blame. Timeline on a whiteboard. (10 minutes)
2. What worked: Name the things that went well. People need to hear this. (5 minutes)
3. What did not work: Each person writes one thing on a sticky note. Read them aloud. Group similar items. (10 minutes)
4. Root cause on the top item: Ask "why" five times. Not literally five, but keep asking until you reach the system-level cause underneath the person-level cause. (10 minutes)
5. One change: Agree on one change. Assign an owner. Set a check date. Add it to the improvement backlog. (10 minutes)

The rule: if you leave a retrospective without a written action item and an owner, you wasted 45 minutes.

Fixing symptoms versus fixing systems

When a technician uses the wrong sealant, the symptom fix is to tell that technician to use the right one. The system fix is to label the sealant bins, add a photo reference to the job card, and test new technicians on material selection during onboarding.

Here is how to tell the difference:

• If the fix depends on one person remembering something, you fixed a symptom.
• If the fix changes a checklist, a label, a template, or a training module, you fixed a system.
• If the problem comes back within 90 days, you fixed a symptom.

The founder learned this after the sealant issue returned three times. The operations manager finally created a visual job card with photos of every material for each building type. She laminated them and attached them to each technician's toolkit. The problem stopped.

The improvement backlog

Keep a shared spreadsheet (Excel, Google Sheets, or a Zoho sheet) with five columns:

Sort by impact times effort. High impact, low effort goes first. Review the backlog every monthly operating review. If an item sits untouched for three months, either do it or delete it.

This is a list of things your business has learned but not yet acted on, not a project management tool. The gap between what you know and what you have fixed is where leakage lives.

Common mistakes

Trying to fix everything at once. Pick one problem per week. Your team can absorb one change at a time. Stack changes too fast and none of them stick.

Skipping the check step. You made a change. Did it actually work? Go look. Talk to the person doing the work. Check the numbers. Founders typically assume their fix worked because nobody complained. Silence is not evidence.

Holding retrospectives that produce feelings without actions. A good conversation about what went wrong is worthless if it does not end with a written change and an owner. Write it down. Put a date on it.

Making the founder the bottleneck. If every improvement flows through you, you have built a queue. Your supervisors should own fixes in their area. You review and approve at the monthly operating review.

Confusing busy with better. Activity is not improvement. Sending more WhatsApp messages, creating more reports, adding more steps to a checklist: none of that counts unless the problem actually stops recurring.

When to move on

You are ready to move on from this chapter when:

• You have held four consecutive weekly reviews without skipping one
• Your improvement backlog exists and has at least five items with owners
• At least three items on the backlog are marked "Done" with a verified check date
• You have run one retrospective that produced a system-level change beyond a person-level fix
• Your Monday morning feels different because problems are being caught upstream

If your backlog is empty, you are not looking hard enough. If it has 40 items and none are done, you are collecting problems instead of fixing them. Aim for a backlog of 8 to 15 active items with steady throughput.

Where to focus by team size

• 10 to 19 people: Start with a weekly 15-minute team check-in. Keep it simple: what worked, what did not, what changes.
• 20 to 34 people: Add a monthly operating review. At this size, you need a rhythm that catches problems before they accumulate.
• 35 to 50 people: Team leads should run their own improvement cycles. The founder reviews the improvement backlog monthly.

---

Working prompts

People

• Who on your team notices problems but does not raise them? What is stopping them?
• Which supervisor has the best instinct for spotting patterns? Can they lead the weekly review?
• When someone makes a mistake, does the team treat it as a learning event or a blame event?

Systems

• How many of your current processes were designed intentionally versus grew by accident?
• Where does your team rely on memory instead of a written reference?
• If your best performer left tomorrow, which processes would break first?

AI

• Could a simple Zoho or Excel formula flag when a metric crosses a threshold?
• Is there a recurring report you build manually that could be automated with a template?
• Where would a dashboard showing last week's data change the conversation at the weekly review?

Founder exercise

Part A: Build your improvement backlog (30 minutes)

Open a new spreadsheet. Create five columns: Problem, Root Cause, Proposed Fix, Owner, Status. Now walk through the last four weeks mentally. Write down every problem that happened more than once. For each one, ask yourself: did we fix the symptom or the system? If the answer is symptom, write the system-level root cause in column two. You should have at least five rows.

Part B: Run your first weekly review (15 minutes next week)

Pick a day and time. Invite your team leads. Use the three questions: What went wrong that should not have? Did last week's fixes hold? What is the one thing we fix this week? After the meeting, add the chosen item to your improvement backlog with an owner and a check date.

Part C: Schedule your first monthly operating review (60 minutes, end of month)

Gather the five data points listed in the monthly review section above. If you cannot find one of them, that gap is your first improvement item. Sit down for 60 minutes and answer: where will we spend next month's improvement effort?

ARCAS lens

The diagnosis engine scores your business across seven audits. Two of them, Behaviour and Skills, directly measure your team's ability to learn and adapt. A low Behaviour score often means problems recur because fixes depend on individual memory instead of system updates. A low Skills score means capability gaps keep reopening because training is informal and inconsistent.

In the Five Levels model, systems leakage surfaces when knowledge is trapped in people instead of processes. Every item on your improvement backlog that converts a person-dependent fix into a system-level fix moves your score upward and reduces leakage.

The weekly review and monthly operating review are not extra work layered on top of your business. They are the mechanism that converts your diagnosis results into actual operational change. Without them, the diagnosis tells you what is broken but nothing gets repaired.

Start now: Quick self-assessment

Score each row from 1 (not happening) to 5 (consistent and effective).

Your total: ___ / 30

• 25-30: Your improvement system is working. Focus on speed and delegation.
• 18-24: The structure is there but inconsistent. Pick the lowest-scoring row and make it your next weekly review focus.
• 10-17: You are fixing symptoms, not systems. Start with Part A of the founder exercise and build the backlog this week.
• Below 10: This is the chapter to work through carefully. Begin with the weekly review. Everything else builds on that habit.