Build a System That Keeps Getting Better

The people closest to the work often understand its friction best.

They know:

Leaders should not treat improvement as something designed only by executives and imposed on the team.

Invite the people doing the work to identify and test improvements.

Ask:

Operational improvement becomes stronger when the people affected help design it.

Large changes carry more risk and take longer to produce feedback.

A small improvement can be tested quickly.

For example, instead of redesigning the entire onboarding process, test:

Then examine whether the result improves.

A useful improvement should define:

Continuous improvement does not mean changing everything constantly.

When a better approach works, make it the new standard.

This may involve updating:

Without standardisation, the improvement remains dependent on memory and individual effort.

The purpose of a standard is not to prevent future change.

It creates a reliable baseline from which the next improvement can occur.

A company is a network of connected activities.

A change in one area can create consequences elsewhere.

For example:

A local improvement can weaken the overall system.

That is why founders need to examine the complete value flow rather than optimising each department independently.

The goal is not:

It is:

Systems produce feedback.

Some feedback reinforces the current direction.

Cause and effect are not always immediate.

A hiring decision may take months to improve capacity.

Poor onboarding may not appear as churn until renewal.

Reduced product quality may not affect revenue until customers lose trust.

A marketing change may require several sales cycles before its impact becomes clear.

These delays can lead founders to make the wrong conclusion.

They may stop a useful change too early or continue a harmful practice for too long.

Define:

Every system has a constraint that limits its current performance.

It may be:

Improving work outside the constraint may create more activity without improving the total outcome.

For example, generating more sales leads will not help when onboarding capacity is already overwhelmed.

The founder should ask:

Then concentrate improvement there.

Once the constraint moves, reassess the system.

Choose one important recurring workflow.

Examples include:

Map:

Do not begin by documenting the ideal process.

Map what actually happens.

The difference between the documented process and real behaviour often reveals the most valuable improvement opportunities.

Every handoff creates risk.

Context may be lost. Ownership may become unclear. Work may wait in another queue. The receiving person may need to repeat earlier discovery.

Common handoffs include:

For each handoff, clarify:

A handoff is complete only when the next owner has accepted the work and has enough context to continue.

Work often spends more time waiting than being actively completed.

Waiting may occur because:

The founder should distinguish between:

Reducing waiting can improve speed without asking people to work faster.

Ask:

Starting more work can create the feeling of momentum.

But too much work in progress slows completion.

When people divide attention across many priorities:

Apollo recommends limiting the amount of active work.

Finish meaningful work before continually starting more.

Work can remain almost complete for long periods when the definition of completion is unclear.

“Launch the new onboarding process” may mean different things to different people.

A stronger definition might include:

A clear definition of done reduces ambiguity and prevents work from lingering indefinitely.

Examine the people, incentives, dependencies, constraints and feedback producing the result.

Make the work, ownership, handoffs, waiting and bottlenecks visible.

Choose one focused improvement where it can produce the greatest effect.

Turn the proven improvement into the new operating practice.

Check whether speed, quality, cost, reliability or customer value improved.

Understand what happened and what the evidence suggests.

Choose the next improvement.

Heroic effort can save a customer, recover a deadline or resolve a crisis.

But heroics become dangerous when they are required repeatedly.

After every rescue, ask:

When something goes wrong, identifying the responsible person can feel decisive.

But blame often ends the investigation too early.

A stronger review asks:

Accountability and systems thinking should work together.

Work becomes difficult to manage when it exists mainly in:

Important work should make visible:

Operational excellence can sound like a major future project.

The company plans to redesign every process, replace its systems or restructure the organisation once it has more time.

That moment rarely arrives.

Kaizen offers a better approach.

Improve one recurring problem now.

A new tool can create excitement because it offers a visible response to an operational problem.

But tools do not create clarity by themselves.

Before adding software, define:

Then decide whether technology is required.

Every handoff introduces a point where work can slow down or lose context.

A reliable handoff should define:

Excessive work in progress causes:

Limit active priorities and make a deliberate trade-off before adding another.

A team may improve its own efficiency while weakening the wider system.

Before improving one area, ask:

Meetings are useful when people need to:

They are less useful when their main purpose is for everyone to report status.

Automation can improve speed, consistency and cost.

It can also make a bad process fail faster.

Use this sequence:

A proven operating standard may need to be captured as:

Every recurring process should have an owner and a reason to exist.

Ask:

Begin with the result the workflow exists to create.

Define:

Document the current workflow from beginning to end.

For each step, record:

A visible workflow should answer:

Identify the single part of the workflow that most limits the outcome.

Ask:

Define:

Useful operational measures may include:

Update the relevant:

At the end of the improvement, ask:

What happened this week?

Look for:

What part of the system produced the outcome?

Consider:

What small change can we test?

Who owns the change?

If it works, how will it become the new standard?