100% Output. 25% Workforce - The Death of the Org Chart: Replacing Departments With Outcomes - Part 2

Your head of sales can hit the sales target. Your implementation team can complete its checklist. Your support team can meet its response-time target.

The customer can still have a terrible experience.

Sales sold something the product doesn't quite support. Implementation configured what was written in the agreement. Support responded quickly but couldn't fix the underlying problem.

Everyone completed their part.

Nobody delivered the result.

In Part 1, I argued that a company can be full of capable people doing necessary work inside an unnecessary process. Making those people faster does not automatically fix the process.

Now we have to deal with the structure that keeps it in place.

If you were rebuilding the company with one-quarter of the workforce, would you recreate the same departments? Would you give each department its own queue, manager, priorities and approval process?

Or would you organize around the results the company needs to deliver?

The first structural change is this: stop treating departments as the permanent units of the business. Start treating outcomes that way.

That sounds straightforward until you realize what it requires people to give up.

Putting AI inside every department leaves the departments intact

Imagine a company that gives every function its own AI assistant.

Sales uses AI to prepare proposals. Product uses AI to write requirements. Engineering uses AI to implement changes. Support uses AI to draft responses.

But sales still hands work to product. Product still negotiates priorities with engineering. Engineering still waits for clarification. Support still waits for everyone else.

Each department may be doing its part faster. The work still travels through the same structure.

Now imagine leadership creates a cross-functional team. A salesperson, a product manager, an engineer and a support specialist attend the same weekly meeting.

That might improve coordination.

But if every meaningful decision still requires approval from their separate managers, you haven't replaced the structure. You have added another meeting to it.

The same applies to renaming departments.

Calling customer success the "customer outcomes team" changes nothing if its employees still spend most of their time chasing other departments for help.

The test is not what you call the team.

Can it deliver the result within clear limits without repeatedly asking the rest of the organization for permission?

If not, it still depends on the old structure.

Decide what the company must deliver

A department describes a category of expertise.

Engineering. Finance. Sales. Support.

An outcome describes a result someone needs.

A customer can use the product successfully. A recurring problem is resolved. An agreed product improvement reaches customers and works as intended.

Those are different ways of organizing responsibility.

"Process onboarding requests" is an activity.

"Get an eligible customer operational with the agreed configuration and usable data" is an outcome.

"Close support tickets" is an activity.

"Restore the customer's ability to complete the affected task" is an outcome.

The distinction matters because an activity can be completed without solving the original problem.

You can send the email, update the ticket and complete the checklist while leaving the customer exactly where they started.

An outcome needs a clear beginning and a clear definition of done. It also needs quality conditions. "Customer operational" means very little if their data is wrong or they need an employee beside them to use the system.

Be careful not to make outcomes so broad that they become slogans.

"Make customers happy" gives a team no useful boundary. "Own the customer experience" could mean almost everything the company does.

Choose something specific enough that you can assign responsibility, define authority and verify completion.

You are not eliminating the need to divide work. You are changing the basis on which you divide it.

One owner needs more than responsibility

A familiar response to a broken process is to appoint an owner.

Someone is now "accountable for onboarding."

But that person cannot change the configuration process. They cannot access the required information. They cannot approve a standard exception. They cannot influence the engineering work that keeps blocking customers.

They can only follow up more aggressively.

That is a coordination role with a better title.

An outcome owner needs authority over the routine decisions required to deliver the result. They also need control over how the workflow operates, what work it accepts and when it must stop.

That authority should have boundaries.

An onboarding owner might be able to approve supported configurations, prioritize eligible customers and change the standard sequence of work. They should not be able to promise an unbuilt feature or ignore a security requirement to meet a deadline.

The important part is deciding those boundaries in advance.

If every ordinary case requires a fresh negotiation between managers, the authority has not really been delegated.

Accountability without authority produces escalation. Authority without limits produces a different set of problems. You need both.

And the owner remains a person.

"The agent did it" is not an acceptable explanation for a result the company cannot defend. Someone must be responsible for the workflow's rules, performance and recovery when it fails.

What this looks like in practice

In Part 1, I used customer onboarding as an example of work spread across several departments.

Now consider how you would organize it differently.

The outcome is that an eligible customer becomes operational with the product they purchased.

The workflow begins when an accepted agreement and the required customer information are available. It ends when the configuration, data and access have passed the agreed checks and the customer can complete the essential tasks.

Notice what does not count as completion: an internal checklist saying that each department has done its part.

The outcome owner works with a small group whose responsibilities cover the full process. The exact staffing depends on the workload, but three kinds of human work need explicit ownership.

Someone must understand the customer and make decisions about unusual requirements. Someone must maintain the systems that execute and check the work. Someone must handle difficult cases that the standard process cannot resolve.

Those are responsibilities, not necessarily three separate job titles. They are also not proof that three people are enough.

Routine execution belongs in the workflow wherever it can be handled reliably.

Existing software can create accounts, apply approved settings and run validation checks. AI can help interpret customer material or propose a mapping between unfamiliar data fields. Actions with greater consequences can require explicit approval.

The people should not have to coordinate every ordinary step.

They should become involved when the work needs judgment, when a limit is reached or when evidence suggests the process is not working.

Before this unit begins operating, it needs a simple written agreement covering what it accepts, what counts as done, which actions are allowed and which decisions require escalation.

That agreement also needs to say who handles a failed import, how the system recovers and who communicates with the customer.

Without those details, "end-to-end ownership" is just an ambition.

With them, it becomes something you can run and test.

Keep expertise. Remove unnecessary handoffs.

The obvious objection is that departments exist for good reasons.

You need engineering expertise. You need people who understand security. You need financial controls, hiring standards and reliable infrastructure.

Agreed.

Replacing departments as the default path for work does not mean pretending specialist knowledge is unnecessary.

It means separating two questions that are often combined:

Who maintains the company's expertise and standards?

Who delivers a particular outcome?

A security specialist might define access rules, review unusual cases and improve the controls used across several workflows. That does not mean every standard account setup must sit in a security queue waiting for individual approval.

An experienced engineer might maintain shared systems and review changes with a large potential impact. That does not mean every routine configuration requires an engineering ticket.

Some controls must remain independent. The person trying to complete a transaction should not automatically gain the power to bypass the checks on that transaction.

But independence does not require a manual handoff at every step. Where the rules are clear, the workflow can enforce them and retain evidence that it did so.

The aim is to make specialist knowledge available without requiring specialists to repeat the same decisions all day.

There is a second danger here: creating several outcome teams that each build their own tools, data copies and automation.

That is not a smaller operating model. It is duplication with a new structure.

Shared systems still matter. So do common definitions, permissions and records.

An outcome team should own its result without having to build a private version of the entire company.

The remaining handoffs need rules

No team will own everything.

A customer moving from a buying decision to onboarding creates a boundary. An onboarding problem that requires a product change creates another.

The goal is not to pretend those boundaries disappear. It is to make them explicit and dependable.

Take the transition from sales to onboarding.

Sales should not be able to declare its work finished by dropping an incomplete agreement into another team's queue.

The onboarding workflow needs defined acceptance conditions: the purchased scope is clear, required information is available and nonstandard promises have been addressed.

The receiving team should acknowledge acceptance. Until then, responsibility for the transition stays with the sender.

Otherwise, work can sit between teams while both believe the other owns it.

There should also be a named person responsible for the customer-facing case while internal dependencies are being resolved. That person does not have to perform every task or control every specialist. They do have to ensure that the customer is not left managing the company's internal confusion.

This is where the difference between an outcome model and renamed departments becomes visible.

In the old arrangement, transferring the ticket can count as progress.

In the new arrangement, a transfer only counts when someone has accepted responsibility for the next defined result.

Management has to change with the work

A smaller organization cannot preserve every management position by giving each manager a smaller team.

Some management responsibilities will remain important. Hiring well, developing people, setting direction and resolving difficult tradeoffs do not disappear because routine execution is automated.

But a manager whose main job is to distribute work, collect updates and chase approvals needs a different role when those activities no longer require constant intervention.

The manager should be asking why cases fail, whether the workflow's authority is appropriate and where customers are receiving poor results.

They should be improving the system of work rather than becoming the person every case has to pass through.

Otherwise, the proposed structure has an obvious limit: one manager personally reviewing everything that a large number of automated workflows produce.

You haven't removed the coordination problem. You have concentrated it in one person.

Leadership also needs to change what it rewards.

An outcome owner should not lose standing because their workflow needs fewer people. A manager should not have to preserve unnecessary work to justify their position.

Judge them by the results their unit delivers, the resources it consumes and how reliably it operates.

The same scrutiny applies to executives.

If every department is negotiable except the ones represented in the leadership meeting, you are not rebuilding from first principles. You are protecting the existing distribution of authority.

Don't draw a 25-person org chart and call it a plan

It is tempting to take a 100-person company and sketch a replacement with 25 people.

Four people here. Three people there. A few executives. Some shared specialists.

The numbers add up. The operation may not.

You cannot establish staffing needs from a diagram. You have to understand how much human work remains after the new process is functioning.

Consider a hypothetical workflow handling 1,000 cases a week.

Suppose 90% complete without intervention. That leaves 100 cases requiring people.

At 15 minutes each, those cases require 25 hours of human work. At two hours each, they require 200 hours.

Both workflows can claim a 90% autonomous completion rate. Their staffing requirements are very different.

And neither calculation includes maintaining the workflow, investigating mistakes, helping customers or covering absences.

This is why the 25% workforce figure has to remain a design challenge until the evidence supports it.

The structure should follow the demonstrated workload. The workload should not be hidden to make the structure look viable.

Start by proving that one complete outcome can be delivered with substantially less total human effort while maintaining the required quality.

Then establish how that performance holds up under real demand.

Only after that should you decide how many people the operation requires.

Replace one workflow before reorganizing the company

A company-wide announcement is not the best first test.

Choose one outcome with a clear boundary. Appoint an owner who has enough authority to change how it is delivered. Bring together the people who understand the work and the people who can build the replacement.

Map the actual cases, including the ones that go wrong.

Decide which steps can disappear, which can run automatically and which still need human judgment. Establish the acceptance conditions, controls and recovery process.

Then test the new arrangement on real work within a defined scope.

During the transition, make clear which process owns each case. Two teams both assuming the other is responsible is not a controlled experiment.

Once the replacement works, remove the old requirements for that workflow.

Retire the duplicate queue. Stop producing the status report that nobody needs anymore. Remove the approval that has been replaced by an enforced rule.

Do not make the new team deliver the outcome while continuing to satisfy every coordination requirement of the previous structure.

That would leave the company paying for both models.

The goal is not to maintain a successful pilot beside an unchanged business. It is to replace a proven part of the old operation.

The org chart stops deciding how work happens

You will still need reporting relationships.

People need to know who supports their development, who makes staffing decisions and who has authority when priorities conflict.

The org chart does not disappear because nobody has a boss.

It stops determining the path every piece of work must take.

Your company should not need a sales handoff, an operations handoff, an engineering handoff and a management escalation simply because those departments exist.

The result should determine the necessary work. The work should determine the systems, expertise and human judgment required.

Then you organize around that.

A company built this way will not necessarily reach 25% of its current workforce. But it will have a much more credible way to discover what staffing it actually needs.

It will also force a harder conversation than "Which team should get an AI assistant?"

For each result the company promises, who owns it, what can they decide and why does delivering it still require everyone else?

Until you can answer that, the old org chart is still running the business.