100% Output. 25% Workforce - Your Company Is Overstaffed by Design - Part 1

Your company can be full of smart, hardworking people and still require far more people than the work should need. Both things can be true.

Someone spends half their week collecting updates because there is no reliable view of what is happening. Another person moves information between systems that don't talk to each other. A manager coordinates work between teams that each own a small piece of the same customer outcome.

Everyone is busy. Everyone has responsibilities. Remove any of them tomorrow and something probably breaks. But that doesn't prove the structure is right. It proves the company depends on it.

This series is called "100% Output. 25% Workforce." The question behind it is simple: If you had to rebuild your company with 25% of the workforce while delivering the same results, what would you refuse to rebuild?

You would still have to serve your customers, deliver your product and meet your quality standards. You wouldn't get to transfer the missing work to customers or ask the remaining employees to work nights and weekends. You would have to design a different company.

The 25% figure is a design constraint, not a claim that every business can achieve it. This series focuses on software companies and other businesses where much of the work involves information, decisions and digital systems. Whether a particular company can reach that target has to be demonstrated.

But taking the question seriously changes where you start. You stop asking which AI tools to buy and start asking why the company needs so much human effort to operate.

Your people are doing what the company requires

Consider a simple customer request. It arrives through support. Support asks product whether the request is supported. Product asks engineering what would be involved. Engineering asks for more information. Someone schedules a call, writes up the discussion and updates the ticket. A manager follows up because the customer is still waiting.

Each time one person or team passes the work to another, there is a handoff. There may be good reasons for some of those steps. But how much of that work actually resolves the customer's problem? How much exists because information, authority and responsibility are spread across the organization?

The customer didn't ask for seven internal conversations. They asked for something to work.

From inside the company, each person has done their job. Support escalated correctly. Product clarified the requirement. Engineering provided an estimate. Management kept things moving. From the customer's perspective, very little may have happened.

This is the kind of work I want to question. Not every handoff is waste. Not every approval is unnecessary. Some checks prevent expensive mistakes and some decisions genuinely need several people. A change to account access, for example, should not skip a permission check just because that would be faster.

But each step should have to justify its existence. Does it prevent a real mistake? Does it provide information needed for a decision? Or does someone have to ask another department because nobody has a clear record or the authority to act?

"We have always done it this way" is not enough. Neither is "that is what this department does." A job can be necessary inside the current process while the process itself is unnecessary.

That distinction matters. Otherwise, the conversation becomes an argument about whether employees are working hard enough. The more useful question is whether their effort is being spent on work the business should need in the first place.

Making everyone faster doesn't solve the whole problem

The obvious response is to give everyone AI tools. Let support draft replies faster. Let developers generate code faster. Let managers summarize meetings and finance prepare reports faster. Those improvements can be useful. They are not the same as redesigning the company.

Suppose an engineer finishes an implementation in a few hours instead of several days. The change still needs clarification from product, a review from someone who is unavailable, a test environment that is broken and approval for the next release window. The coding got faster. The customer may still receive the change on the same date.

Or suppose everyone involved in a weekly reporting process saves an hour. That is time worth recovering. But the company still collects the same updates, produces the same report and holds the same meeting. Nobody asked whether a reliable view of the underlying work could replace most of the process.

That is the difference between improving a task and removing the need for it.

A quarter of the workforce maintaining the same output means four times the output per employee. But that doesn't mean each employee must personally perform four times as many tasks. Some tasks should become cheaper. Some should run without routine human involvement. Others should disappear.

If ten people spend less time preparing information for one another, that doesn't automatically create ten smaller jobs you can neatly combine. They may still have separate responsibilities, different skills and obligations that require coverage throughout the week. An hour saved in each role does not tell you who can take responsibility for the remaining work.

To change staffing requirements, you need to change the work people are responsible for from beginning to end. That includes what they must know, which decisions they can make and when a specialist has to help.

Time saved inside a job is not the same as removing the need for that job. Confusing the two is how a company can report impressive AI productivity gains without changing how it operates.

Start with the result, not the department

Let's take customer onboarding at a hypothetical software company. Onboarding is the work that gets a new customer ready to use the product.

A sale closes. Sales passes the agreement to customer success. Customer success collects information from the customer. An implementation specialist configures the account. An engineer helps with the data import. Finance sets up billing. Support answers questions about what was configured. Each team has its own system, checklist and view of the customer.

Now imagine rebuilding that process without starting from those departments. The outcome is straightforward: the customer has a correctly configured account, their data is usable, their billing is accurate and they can begin using the product. What work is actually required to get there?

First, the company needs one reliable record of what was sold, what the customer needs and what has been agreed. That information should not have to be interpreted and retyped at every handoff. A difference between the agreement and the account setup should be visible before it becomes the customer's problem.

The system can then identify missing information and request it directly. Standard account configurations can follow approved rules. Data can be checked against a defined format. Proposed mappings, which match fields in the customer's data to fields in the product, can be prepared and tested before anything is imported into the live account.

Billing setup can follow the approved agreement. Access can follow established permissions. Progress can be visible without someone assembling a status report. These steps still need checks, but a person should not have to move the same information through each one.

AI could help interpret an unusual customer document, suggest a mapping between unfamiliar fields or explain a validation problem. A language model, the kind of AI that interprets and produces text, can help with this ambiguous information. Its suggestion should not bypass the checks needed before changing an account.

Ordinary software should handle the steps that are already predictable. There is no reason to put a language model in charge of a calculation that a formula handles reliably. The question is which method can do each part safely, not how many parts can be assigned to AI.

Human involvement would be concentrated where the process cannot safely proceed: conflicting contract terms, questionable data, unusual requirements or a customer who needs help making a decision. One accountable owner would be responsible for the completed onboarding, even when several specialists are needed for an exception.

This changes who does the work, when people become involved and how responsibility is assigned. It is not the same process with a chatbot added to each department.

It also does not prove that jobs disappear because several teams previously touched the process. Those people may have other responsibilities. Some customers may require extensive human attention. The new system itself needs to be built, maintained and checked.

That is what you would measure. How many customers can the new process onboard successfully? How many need intervention? How much human time does the full process consume? What happens when something goes wrong? The point is to test a different way of operating, not to assume the savings.

Before asking, "How can AI help the implementation team?" ask a more difficult question: "Which parts of implementation should require a team at all?"

Leadership doesn't get an exemption

It would be convenient to apply this thinking only to the people doing the day-to-day work. Leadership gets better dashboards. Managers get AI assistants. Everyone else gets a productivity target. That is not a serious redesign.

If a manager spends much of the week collecting updates, assigning routine tasks and chasing approvals, what happens when the system can provide those updates and make those responsibilities clear? Keeping the same reporting chain may preserve a role without preserving a useful reason for it.

That does not mean leadership disappears. Someone still has to make difficult tradeoffs, resolve conflicts, develop people and take responsibility when the available information is incomplete. Someone has to decide what the company will pursue and what it will stop doing.

Those responsibilities should not be confused with the work of repeatedly asking people what is happening. A reliable view of the work can remove the need to collect updates without deciding which customer promise should take priority. The judgment remains even when the information gathering changes.

A smaller organization may need fewer management layers. It may need different managers or people who understand an entire customer outcome rather than one narrow function. Those are questions about what the work needs, not rewards for holding a title today.

The same applies to executives. A transformation that questions every role except the roles of the people leading it has already set its own limits. You cannot insist that the future must preserve your current title, reporting structure and authority, then describe the exercise as rebuilding from zero.

Be precise about "100% output"

The title of this series sounds simple. The measurement is not. What counts as output?

For an engineering organization, it should not be lines of code, code changes submitted for review or tickets closed. Those are activities. You can increase them without delivering anything customers value. For support, a closed conversation is not necessarily a resolved problem. For sales, more messages do not necessarily mean more business.

For finance, producing a report faster is not an improvement if someone has to spend longer checking it. Speed at one step can conceal extra work somewhere else. Before changing the workforce, define the results the company must continue delivering.

That includes quality, reliability and the commitments made to customers. It also includes the work whose value becomes visible only when it is neglected: maintenance, security, documentation and the ability to handle an unexpected failure. A process that works today still needs people or systems to keep it working when conditions change.

A company that ships the same number of features while accumulating defects has not maintained the same output. A company that closes the same number of support tickets while customers give up has not maintained the same service. Neither has a company that performs well only while its remaining employees are constantly available.

The workforce number needs equal scrutiny. If you reduce employees from 100 to 25 but replace them with 50 contractors, you have changed the employment arrangement. You have not achieved the premise.

If customers now spend hours fixing their own imports, some of the labor has moved outside the company. If a new automation requires a large team to review every result, that review work belongs in the calculation. So does the time spent repairing failed runs and answering the questions they create.

Fewer people does not automatically mean a cheaper operation. You still need to account for software, infrastructure, implementation, maintenance and the cost of mistakes. The test is the full cost and human effort required to deliver an accepted result.

Anything less invites the company to report a success that its customers and employees do not experience.

Cutting first is not rebuilding

There is a bad version of this idea. Leadership announces that AI will make everyone more productive. Headcount is reduced immediately. The remaining employees inherit the same processes, the same commitments and most of the same work. Then they are told to figure out how to use AI.

That is a cost reduction decision based on an unproven operating assumption. If you remove the people before removing the work, the work still has to go somewhere. It can become a backlog, overtime, a service failure or a responsibility that stops being handled without anyone noticing at first.

The order matters. First, understand the work. Then remove unnecessary steps. Build and test the replacement process. Establish what it can handle reliably and where it still needs people. Only then can you make a credible decision about staffing.

That process has real consequences for employment. There is no honest version of a 25% workforce argument that avoids them. Some roles may disappear. Some people may move into different responsibilities. A company may reduce hiring, use normal turnover or make layoffs. Another company may keep its workforce and use the increased capacity to grow.

Those are choices leaders have to own. A tested process can inform a staffing decision, but it does not decide how the company should treat the people affected. Leaders cannot assign that responsibility to an AI tool or a productivity target.

Employees deserve a clear explanation of what is changing and what it means for them. Asking people to document their work and train a replacement process while pretending their roles could never be affected is not honest leadership. People should know the possible consequences of what they are being asked to help build.

But neither is protecting every existing role by refusing to examine whether the work is still necessary. The commitment should be to a fair process, clear communication and responsible decisions. It should not be a promise that the organization will never change.

The first move is smaller than the ambition

You do not need to redesign the entire company next week. Start with one complete workflow, meaning the steps from an initial request to a finished result. Choose something with a clear result and a manageable cost of failure.

Customer onboarding could be one. So could a defined category of support request, a recurring internal report or the investigation of a specific class of software issue. The important part is to choose a workflow, not a job title.

"Make the support team more productive" is too broad to test properly. "Resolve these account configuration requests without routine handoffs while maintaining the current resolution quality" gives you something concrete to build and evaluate.

Follow the work from the original request to the accepted result. Examine actual cases, not just the process diagram. Find where people wait, where they copy information and where they have to ask someone for context. Identify the decisions that follow stable rules and the decisions that require judgment.

Then design the smallest reliable process that can deliver the result. Give it a named owner. Define when it must stop and ask for help. Make its actions visible so someone can understand what happened. Keep a recovery path when it makes a mistake, including a way to correct or undo a change where needed.

Measure it over a period that includes ordinary work and difficult cases. A successful demonstration is not evidence that a workflow can operate reliably through a busy month, an outage or an unusual customer request. Test the exceptions as part of the process rather than treating them as someone else's problem.

Include the effort required to keep it running. The people fixing the automation at night are part of the workforce too. A process that needs constant repair has not removed that human responsibility just because customers cannot see it.

Once the process works, change the responsibilities around it. Do not keep the old handoffs indefinitely just because the departments still exist. That would preserve the structure after removing the reason for it.

What would you refuse to rebuild?

I am less interested in whether a company calls itself "AI-native", meaning built around AI from the start, than in what has actually changed. Which work no longer needs to happen? Which outcomes can be delivered without repeated human coordination?

Where do people now apply judgment that the system cannot provide? And can the company prove that those changes have improved its ability to deliver? Those questions matter more than the tools it has bought or the tasks it can complete faster.

The radical part of this series is not the percentage. It is the willingness to question whether the current organization should exist in its current form.

Your employees may be doing exactly what you hired them to do. Your managers may be running exactly the processes you asked them to run. The problem may be what the company requires from all of them.

Before asking which people you can operate without, ask which work you would never create again. That is where the rebuild starts.