Automation Creates Capacity. Who Gets It?

The dumbest sentence in most automation plans is that the technology will “give people time back.”

It will not.

Automation removes demand from a workflow. Then somebody decides what happens to the capacity that is left. The worker can absorb more volume. The company can cut a shift. The team can attack a backlog. The person can spend Friday learning a new system, caring for a kid, building something they own, or looking for another job. The business can keep every dollar. The worker can share in the gain. Usually nobody makes the choice explicit, which means the choice gets made by whoever already has the most control.

That is the real automation question.

Not can the AI do the task?

Who gets what the task used to consume?

Eight hours appeared. Now what?

Imagine an operations coordinator at a distributor spends ten hours a week reconciling inventory counts that disagree between the warehouse system and the sales system. The official process says one thing. The actual work involves three systems, a spreadsheet, a Slack message to the warehouse lead, six judgment calls, and a list of exceptions living in her head.

She helps map it. She explains which fields lie, which SKUs are usually on a truck rather than missing, and where a seemingly safe automation would write off stock that is still in transit. A builder turns that knowledge into a workflow. It is tested against real cases. The ten hours becomes two.

Eight hours of weekly capacity now exists.

Who owns it?

The company has a real claim. It paid for the original ten hours. It paid for the software and implementation. It owns the customer promise and eats the loss when the automation is wrong. If the business cannot capture a return, it will stop funding automation.

The worker has a real claim too. The workflow was not sitting in a manual waiting to be digitized. A meaningful part of it was her accumulated judgment. She helped expose it, correct it, and make it reusable. If her reward is eight more hours of discrepancies to clear—or eight fewer hours on next month’s schedule—she has learned something very rational: hide the next workflow.

That is not resistance to technology. That is incentive design working exactly as designed.

There is no rule that says every saved hour must become paid time off or that every worker who explains a process deserves equity in the company. There is also no serious version of worker participation where “help us automate your job” means “hand over the operating knowledge, trust us, and we will tell you later what happens to you.”

Both sides need the gain. The work is designing the split before everybody starts lying to each other.

Capacity is not a benefit until somebody decides who gets it

I have spent years working on systems that observe how work actually happens. The same pattern keeps showing up: the most valuable automation opportunities are usually buried inside workarounds, handoffs, repeated decisions, and personal systems that management cannot see from the org chart.

That makes the person doing the work essential to discovery. It also creates a strange transaction. We ask someone to turn private operating knowledge into a company asset, then act surprised when they want to know what they get in return.

The usual answer is “higher-value work.” Sometimes that is true. Often it means the same pay, a denser day, more ambiguous responsibilities, and a performance target that ratchets up after the baseline disappears.

Name the work. Name the authority. Name the compensation. Name what the person will be able to prove afterward.

I think about this as five capacity decisions. They are choices every automation project makes whether the company admits it or not.

• Returned hours. What work disappeared, how many hours actually returned, and whether those hours become more volume, different work, a shorter schedule, or fewer roles.
• Upside. Who receives the economic gain: the company, the customer, the worker, the team, or some combination—and through what mechanism.
• Proof. What evidence records the worker’s contribution to mapping, testing, exception handling, and the final result.
• Portability. What the worker can carry forward without taking company data: a verified skill, a sanitized artifact, a credential, a reference, or a measurable outcome.
• Decision rights. Who can approve the automation, stop it, override it, change the role, allocate the returned capacity, and challenge a bad result.

If you cannot answer those five questions, you do not have an automation plan. You have a technical demo attached to an unspoken power decision. The technical side is a separate problem; building a useful closed-loop automation requires its own sequence.

Do not measure activity. Prove the change.

This is where proof of work matters, and not in the crypto sense.

Before the automation, record the real baseline: volume, time, quality, wait states, rework, exceptions, and customer outcome. Record who mapped the process and who supplied the judgment. Afterward, record the same things. Keep receipts for what the system did, where a human intervened, and whether the claimed gain survived contact with the actual workflow.

Do not turn this into a keyboard-activity contest. Time in an app is not output. A person staring at the same screen for an hour may be solving the exception that keeps the company out of court. Proof should make value visible, not make surveillance look scientific.

Good proof protects both sides. The company can see whether the investment returned anything. The worker can show that she did not merely “use AI”; she mapped a broken reconciliation process, identified six failure modes, helped cut weekly handling time by eight hours, and held write-off errors inside an agreed boundary.

The company may own the workflow, the customer data, and the code. That does not require the worker’s contribution to disappear. A portable record can be specific without exposing private information.

This is the part most companies miss. If the proof stays entirely inside the employer, the worker helped create leverage but cannot use it. If all the proof walks out the door, the company has a security problem. The answer is not pretending the conflict does not exist. The answer is designing a bounded, verifiable record both sides can live with.

Connect, challenge, assist

Go2 is built on three strategic pillars: Connect, Challenge, Assist. They are useful here because automation fails when any one of them is missing.

Connect the people who know the work to the people who own the outcome and the people building the system. Put them on the same map. Let the worker see and correct what is being inferred from their work. Connect the baseline to the claimed result. Connect the capacity created to a named destination.

If the builder only talks to the executive sponsor, the company automates the official process. The official process is usually not the process.

Challenge the task before automating it. Does it need to exist? Is the policy creating the work? Is the handoff there because two managers will not make a decision? Then challenge the proposed allocation. If the worker saves ten hours, why does the new target assume twelve? If leadership says the capacity will fund development, which development, by when, and who protects the time?

Challenge has to run both ways. Workers should not get a veto over every change because they understand the current process. Management should not treat silence as agreement because speaking up feels unsafe. A real challenge mechanism has evidence, an owner, a deadline, and a way to disagree without ending the conversation.

Assist means giving people the tooling, coaching, permissions, and runway to operate at the next level. It does not mean emailing a course catalog after announcing a reduction.

If someone helps automate inventory reconciliation, the next step might be owning exception design across the whole warehouse. It might be learning to build and maintain the workflow. It might be moving into supplier negotiation, where the judgment is harder to automate. It might be taking Fridays back. Different people want different things. The point is to make a real path possible.

Connect without challenge creates consensus around a bad process. Challenge without assist turns improvement into punishment. Assist without connection builds tools nobody trusts.

Keep each business lane honest

The right allocation depends on the actual situation.

A growing company with a six-month order backlog may use every returned hour to serve more customers. That can be a good outcome. Say so. Show the worker the growth, protect quality, and define how contribution changes pay, authority, or advancement.

A business with ninety days of cash may need automation to survive. Some roles may disappear. Do not insult people with a fake promise that everybody is being “freed for strategic work.” Tell the truth early. Share the proof they helped create. Give notice, transition support, severance where possible, and a portable account of the value they produced.

A stable, profitable company may choose to return some of the gain as time: a four-day week, shorter shifts, predictable flexibility, or protected build time. That is not charity. Retention, knowledge, trust, and better automation participation have economic value too. Measure them.

A contractor or offshore service provider creates a three-party problem. The client wants lower cost. The provider funds management, recruiting, continuity, and compliance. The worker supplied the operating knowledge. If the client captures the full saving, the provider has no reason to improve. If the provider captures it all, the client will replace the provider. If the worker captures none, the worker will protect the remaining manual work. The allocation has to acknowledge all three parties or one of them will quietly break the loop.

And an owner automating their own business is in a different lane again. If you own the company and save yourself Friday, you already receive the time and equity upside. Do not use that experience to tell an employee that automation is obviously liberating. Your ownership did the liberating.

These are different deals. Treating them as one inspirational AI story is how trust gets burned.

A capacity agreement you can use

Before a worker helps automate a recurring task, put one page in front of everyone involved. It can be revised. It cannot be imaginary.

1. What are we trying to remove? Name the task, its current cost, the quality boundary, and the parts that should be deleted before they are automated.
2. Who is contributing what? Record the process owner, the workers supplying judgment, the builder, the budget owner, and the person accountable when the system fails.
3. What counts as proof? Agree on the before-and-after measures, the test period, the exceptions, and the receipts each contributor will retain.
4. Where does the capacity go first? Backlog, growth, reduced hours, new responsibilities, cost reduction, or some split. Put percentages or hours on it where possible.
5. How does the worker participate in the upside? Pay, bonus, schedule, promotion path, ownership of the new function, learning budget, revenue share, or portable proof. “Future opportunity” is not an answer.
6. What can be carried forward? Define the sanitized evidence, credential, reference, or work sample the contributor can keep.
7. Who has decision and override rights? Name who can ship, pause, correct, appeal, and revisit the allocation when the result differs from the estimate.
8. When do we review the deal? Automation compounds. The allocation should not freeze after the first win while the system keeps returning value.

This is small enough to use on one workflow next week. It is also enough to expose whether the project is serious.

We are active in our own rescue

One of the lines inside the Go2 protocol is: We are active in our own rescue.

For workers, that means do not wait for a perfect corporate program. Map the recurring work you understand. Track the volume, the time, the exceptions, and the result without taking data you do not own. Learn what can be deleted, what can be automated, and what still requires judgment. Bring a proposal with an explicit ask for the capacity you help create.

That is what owning a role looks like. Ownership does not mean donating every improvement and hoping somebody notices. It means being accountable for the result and building evidence that increases your options.

For businesses, “active in your own rescue” is not permission to move the entire burden of adaptation onto the worker. If you want people to reveal the work, fund the experiment. Protect genuine opt-in. Give them access to their own evidence. Make the decision rights and downside explicit. Do not ask for ownership behavior while reserving every form of ownership for the company.

Every automation that actually works creates capacity. Some of it will become cheaper products. Some will become profit. Some will become more work. Some will become time. Some will eliminate jobs, and some will give one person the reach of a company.

The technology does not decide that allocation. We do.

So stop saying automation gives time back.

Say where the time goes.