Imagine you have a rockstar on your team.

Give them a task they have done a hundred times, and they can probably finish it in 30 minutes.

Now you introduce a new system.

The same task takes 20 minutes in the system.

You might think that is a clear productivity improvement.

But the customer says:

“I used to do it in 30 minutes. The system takes 20. Where is the productivity?”

At first, it sounds like a fair question.

But perhaps we are measuring the wrong thing.

Because the 30 minutes the person remembers may have been the time spent on the core task itself. It may not have included everything that had to happen around that task to get the work from start to finish.

They had to identify which version of the document was the right one.

They had to locate and open it.

They may have checked what changes had already been made.

They may have manually verified the output.

They had to move the file to the next person.

They may have sent an email to let someone know it was ready.

They may have updated a tracker or recorded the status somewhere else.

They may have checked that the correct version was being used downstream.

Each of these activities took time.

For an experienced person, perhaps only a few minutes here and a few minutes there. Because these steps were routine, familiar and often spread across the working day, they may never have been thought of as part of the “30-minute task.”

But they were still part of the work.

And that time matters when we measure productivity.

The system, on the other hand, may take 20 minutes to perform the visible task. But at the same time, it may also ensure that the correct version is being used, capture the activity, maintain the workflow state, preserve the audit trail, update the status, and make the result available to the next person without another round of manual coordination.

Those activities do not disappear.

They are simply being performed by the system instead of the person.

And because they happen automatically, they become even easier to overlook.

This creates an interesting problem when we talk about productivity.

We often compare:

30 minutes of an expert’s manual task

with

20 minutes of the system’s task

and conclude that the productivity gain is only 10 minutes.

But that may not be the real comparison.

Perhaps the manual process was actually:

30 minutes to perform the task

· time to find and verify the correct file

· time to check previous changes

· time to validate the output

· time to update the tracker

· time to communicate the status

· time to hand the work over

· time to make sure the correct version moved downstream.

Some of these activities may take only a minute or two. Others may take longer. Some may happen immediately, while others happen later in the day.

Individually, they look insignificant.

Collectively, across hundreds or thousands of tasks, they are not.

So the better question is not simply:

How long did the person spend performing the task?

It is:

What did it take the organization to get the work from the starting point to the final usable outcome?

That is a very different measurement.

And there is another dimension.

The experienced person may be incredibly fast because they have developed their own shortcuts over years.

But can everyone do it in 30 minutes?

Can a new employee?

Can someone who is less familiar with the process?

Can they reliably find the correct version?

Will they know what has already been completed?

Will they remember every routine check?

Will they know who should receive the work next?

Will they update the right tracker?

Can someone else immediately pick up where they left off?

And can the organization prove what happened six months later?

This is where the value of a system becomes much more significant.

A system is not productive simply because it performs one visible task faster than a person.

It is productive when it reduces the total effort required to complete the process.

It is productive when actions that previously required separate manual effort happen automatically as part of the workflow.

It is productive when fewer people need to spend time finding files, checking statuses, sending routine emails, updating trackers, coordinating handoffs and resolving version confusion.

And it is productive when the process becomes more reliable, repeatable and less dependent on individual memory and experience.

This brings us back to the rockstar.

A rockstar can make a 30-minute task look like a 30-minute process.

But perhaps it never was.

Perhaps the rockstar was silently carrying several additional responsibilities around that task, spending small amounts of time throughout the day making sure everything continued to move correctly.

Those minutes rarely appear in productivity calculations.

But they exist.

Multiply five minutes of unmeasured coordination by 20 tasks a day.

Then multiply that by a team.

Then multiply it by a year.

Small amounts of invisible work can become a substantial amount of organizational effort.

That is why productivity cannot always be measured by putting a stopwatch against a single activity.

There is also a second productivity gain that is even harder to measure.

The rockstar knows the process.

They know where things are.

They know what to check.

They know what usually goes wrong.

They know who needs to receive the work next.

They have accumulated this knowledge through experience.

Without a system, much of the process may therefore exist inside the heads of experienced people.

With a well-designed system, some of that knowledge becomes part of the workflow itself.

The system knows the current state.

The system knows the version.

The system knows what needs to happen next.

The system maintains the history.

The system provides the next person with the work and the context they need.

That changes the productivity equation again.

The gain is no longer simply:

30 minutes → 20 minutes.

It becomes:

“One person knew how to make the process work” → “the process itself helps people work correctly.”

That is a much bigger shift.

The goal of a good system is not to make the rockstar slower.

It is to make the rockstar’s expertise less fragile, more scalable and more reusable.

And if we design it well, something even better happens.

The system raises the floor.

The average person can perform at a reasonable level without needing years of experience simply to navigate the process.

And the rockstar gets to raise the ceiling.

Instead of spending their expertise on finding versions, checking routine steps, moving work between people, updating trackers and answering the same operational questions repeatedly, they can spend it on the problems that actually require exceptional judgment.

So perhaps the better question is not:

“Did the system complete this task faster than my best person?”

It is:

“What did the system take off the person’s plate that we were not measuring before?”

That is where productivity often hides.

It hides in the five-minute email that no longer needs to be sent.

The tracker that no longer needs to be updated manually.

The file that no longer needs to be searched for.

The version that no longer needs to be verified.

The status that no longer needs to be checked with another person.

The handoff that no longer needs someone to coordinate it.

The mistake that no longer needs to be corrected.

And the knowledge that no longer needs to exist only in one experienced person’s head.

So, when we evaluate productivity, perhaps we should stop measuring only the visible task.

We should measure the work around the work.

Because sometimes the biggest productivity gain is not making a 30-minute task take 20 minutes.

It is eliminating all the additional minutes surrounding that task that nobody was counting in the first place.

And at scale, it is making sure that the right work, in the right version, reaches the right person, at the right time, with the right context, without depending on a rockstar to make it happen.

That is productivity at scale.