Stop Starting More Work. Start Finishing More Work.

What The Phoenix Project taught me about Flow, WIP, Feedback, and Continuous Learning

One of the most interesting lessons I have been learning from The Phoenix Project is that being busy is not the same as creating value.

In technology teams, it is very easy to fall into the trap of starting more and more work.

A new project comes in.

Then another.

Then another.

Before long, the team is working on seven projects simultaneously.

Everyone is busy. Everyone has a long task list. Everyone is attending meetings, writing code, testing, reviewing, fixing issues and reporting progress.

But there is a problem:

How much of that work is actually delivering value to the business?

This is where the concept of Work in Progress (WIP) becomes extremely important.

A simple example: Seven projects

Suppose your team has seven projects, and each project requires approximately 24 hours of work to complete.

You have two choices.

Option 1: Work on one project at a time

You complete Project 1 in 24 hours and put it into production.

Then you move to Project 2.

After another 24 hours, Project 2 goes live.

Then Project 3.

And so on.

The flow looks something like this:

Day 1 → Project 1 LIVE

Day 2 → Project 2 LIVE

Day 3 → Project 3 LIVE

Day 4 → Project 4 LIVE

Day 5 → Project 5 LIVE

Day 6 → Project 6 LIVE

Day 7 → Project 7 LIVE

The important thing is that the business starts receiving value after Day 1.

Project 1 could already be generating revenue, improving customer experience, reducing operational cost, eliminating a manual process or solving a business problem while the team works on Project 2.

Option 2: Work on all seven projects simultaneously

Now consider the alternative.

The team starts all seven projects at the same time.

Everyone works on Project 1, Project 2, Project 3, Project 4, Project 5, Project 6 and Project 7.

After six days, all seven projects are still in progress.

On Day 7, they are finally completed and launched.

The result?

Seven projects were in progress for seven days, but none of them delivered value until the end.

This is the fundamental problem with excessive WIP.

The hidden cost of Work in Progress

Work in progress looks harmless.

After all, starting work feels like progress.

But unfinished work consumes resources.

People have to remember where they left off.

Requirements may change while the project is being developed.

Testing environments may be occupied.

Infrastructure may be provisioned.

Management attention is required.

Meetings are needed.

Dependencies have to be coordinated.

People switch between projects.

And every time someone switches from one project to another, there is a cognitive cost.

The work may be 80% complete, but until it is actually finished and delivered, the business may receive zero valuefrom it.

That is why one of the most important principles I have taken from The Phoenix Project is:

Don't measure progress by how much work you have started. Measure progress by how much valuable work you have finished.

The power of smaller batches

The solution is not necessarily to work harder.

It is to reduce the amount of work moving through the system at one time.

Instead of creating a large batch of work, break it into smaller batches.

Instead of having seven projects in progress, finish one and move it into production before starting the next where practical.

This creates a very different flow:

Start → Finish → Deliver → Learn → Start the next

rather than:

Start → Start → Start → Start → Start → Start → Start → Finish everything

The first approach creates value continuously.

The second approach creates a large inventory of unfinished work.

The benefits of a serialised approach

A serialised approach — finishing one piece of work before moving to the next — can provide several important benefits.

1. Faster value delivery

The business doesn't have to wait until every project is finished.

The first completed project can start delivering value immediately.

2. Earlier revenue and ROI

If a project generates revenue, reduces costs or improves productivity, those benefits can begin as soon as the project goes live.

3. Lower WIP

Fewer projects are consuming resources simultaneously.

This reduces the amount of unfinished work sitting in the system.

4. Greater focus and productivity

The team can concentrate on completing the current priority instead of constantly switching between projects.

5. Faster feedback and learning

Once something is in production, you can observe how customers and the business actually use it.

That information can then influence the next project.

6. Lower risk and easier course correction

Problems are discovered earlier.

If requirements change, you can adjust the next piece of work before investing heavily in it.

7. Better visibility of progress

There is a major difference between:

Seven projects 80% complete

and

Seven projects completed and delivering value.

The second represents actual business outcomes.

But this is bigger than simply "one project at a time"

This is where The Phoenix Project becomes particularly interesting.

The idea of reducing WIP is not an isolated productivity trick.

It is part of a much bigger philosophy known as The Three Ways.

The Three Ways provide a way of thinking about how technology and business work should flow through an organisation.

They are:

1. The First Way — Flow
2. The Second Way — Feedback
3. The Third Way — Continual Learning and Experimentation

And these three ways are connected.

The First Way: Flow

The First Way is about optimising the flow of work through the entire system.

Think about the complete journey:

Business Demand → Development → Testing → Operations → Customer

The objective is not to optimise one department in isolation.

It is to optimise the entire system.

For example, imagine Development can produce 100 features, but Operations can only deploy 20.

Development producing more features doesn't improve the overall system.

It simply creates a bigger queue.

That queue is WIP.

So rather than constantly pushing more work into the system, we need to identify the constraints and improve the flow.

Practices associated with Flow include:

• Reduce work in progress.
• Reduce batch sizes.
• Identify bottlenecks.
• Remove constraints.
• Avoid passing defects downstream.
• Focus on completing work.
• Improve the speed and reliability of delivery.

The ultimate objective is simple:

Move valuable work from idea to customer as quickly and safely as possible.

The Second Way: Amplify Feedback Loops

Getting work into production is not the end.

It is the beginning of another important process:

Feedback.

Once something is running, we need information coming back from the system.

What are customers experiencing?

Are there errors?

Is performance acceptable?

Are transactions failing?

Are customers using the feature?

Are there operational problems?

Is the solution actually solving the problem we intended to solve?

This creates a feedback loop:

Development → Testing → Operations → Customer → Feedback → Development

The faster and more accurate that feedback becomes, the faster the organisation can detect and correct problems.

Benefits include:

• Problems are detected earlier.
• Defects are corrected sooner.
• Less rework is required.
• Quality improves.
• Recovery from failures becomes faster.
• Development becomes more closely aligned with operational and customer needs.

This is why monitoring, telemetry, automated testing, customer feedback and operational visibility are so important.

They are not merely technical tools.

They are feedback mechanisms.

The Third Way: Continual Learning and Experimentation

The Third Way takes the organisation another step forward.

Once we have flow and feedback, we need to learn from what happens.

We should not simply repeat the same process over and over.

We should ask:

What worked?

What didn't work?

Why did it happen?

What can we change?

What can we experiment with?

This creates a continuous cycle:

Experiment → Measure → Learn → Improve → Experiment again

Failure is not necessarily wasted effort if we learn from it and use that knowledge to improve the system.

The objective is to create an organisation that becomes better at delivering value over time.

Benefits include:

• Continuous improvement.
• Faster organisational learning.
• More innovation.
• Greater resilience.
• Better ability to adapt to change.
• Increasing technical and operational mastery.

The Three Ways are connected

The Three Ways should not be viewed as three independent ideas.

They reinforce one another.

1. Flow

We reduce WIP and get work delivered.

↓

2. Feedback

We receive information from production, operations and customers.

↓

3. Learning

We use that information to experiment, improve and adapt.

↓

Better Flow

The improvements make the next cycle of work flow even better.

And the cycle continues.

FLOW → FEEDBACK → LEARNING → BETTER FLOW

That is the bigger picture.

Bringing it back to our seven projects

Let's return to our original example.

We have seven projects, each requiring 24 hours.

If we work on all seven simultaneously, we may have:

7 projects in progress

7 sets of requirements

7 sets of dependencies

7 sets of testing

7 sets of operational considerations

7 competing priorities

And potentially:

0 projects delivering value until Day 7.

Now compare that with completing one project at a time.

After Day 1:

Project 1 is live.

We get feedback.

We learn.

We improve our process.

Then Project 2 goes live.

We get more feedback.

We learn again.

Then Project 3.

And so on.

We are not only delivering projects.

We are continuously improving the system that delivers projects.

That is a much more powerful way of thinking.

The real goal is not "do everything sequentially"

There is an important nuance here.

The lesson is not that every organisation must literally have only one project running at a time.

Real organisations have multiple teams, dependencies, urgent incidents, regulatory requirements and projects that can legitimately run in parallel.

The deeper principle is:

Reduce the size of the batches moving through the system, limit WIP, finish work, deliver value, get feedback and continuously improve.

Sometimes that means one project.

Sometimes it means a small number of projects.

The important question is:

Are we starting more work than the system can effectively finish?

If the answer is yes, we are creating a queue.

And queues create delay.

Start Less. Finish More.

One of the most powerful changes a technology team can make is to stop celebrating the number of things it has started.

Instead, celebrate the number of valuable things it has finished and delivered.

There is a big difference between:

"We have seven projects underway."

and:

"We delivered seven valuable improvements to the business."

The first describes activity.

The second describes outcomes.

That distinction is at the heart of reducing WIP.

A simple message for the team

If I had to summarise the lesson for my team in a few words, it would be:

Start less. Finish more. Deliver value sooner. Learn faster. Improve continuously.

Or even more simply:

Flow. Feedback. Learning.

Reduce WIP.

Deliver in small batches.

Get feedback quickly.

Learn from the results.

Improve the system.

Then do it again.

Because ultimately, the objective of technology is not to keep people busy.

The objective is to move valuable work through the system and get that value into the hands of the business and the customer as quickly, safely and reliably as possible.