The End of Business as Usual: Rebuilding Every Department From Zero - Part 5

If I gave you 25 people and asked you to build a company that delivers the same output as your current 100-person organization, would you create the same departments?

Would you hire a VP (vice president) of Engineering, a VP of Product, a Head of Customer Success, a Sales Director, a Finance Director and then start building teams underneath them?

Would you create the same management layers, approval processes, reporting structures and meetings?

Probably not.

But a company can do exactly that with AI (artificial intelligence).

They take their existing organization, give each department access to AI tools and expect a fundamental transformation.

Engineering gets coding agents. Support gets chatbots. Sales gets automated prospecting. Finance gets AI-powered reporting.

Everyone becomes a little more productive.

The company still looks exactly the same.

In Part 4, I argued that AI needs to move beyond assisting employees and start executing work autonomously.

Now comes the uncomfortable question.

If AI can execute most of the routine work across your organization, why would you rebuild the departments that existed to perform that work?

That's what Part 5 is about.

Not making every department 20% more efficient.

Rebuilding the company without assuming those departments should exist in their current form.

Stop asking how AI can improve a department

Let's start with a hypothetical example.

A customer reports a problem.

Support investigates and determines that engineering needs to get involved.

Engineering discovers that the behavior is actually a product decision.

Product reviews the request, discusses priorities and sends it back to engineering.

Engineering implements the change.

QA (quality assurance) tests it.

Support communicates the resolution.

Six different functions may have participated in resolving one customer problem.

Everyone did their job.

But how much of that organizational structure was actually necessary to deliver the result?

What if an autonomous system could investigate the issue, identify the underlying cause, determine whether the expected behavior was already defined, implement a supported correction, validate it and communicate the outcome?

A human would become involved when the system encounters something that requires judgment or falls outside its authority.

That doesn't eliminate the need for engineering expertise, product decisions or quality assurance.

It changes how those capabilities are delivered.

The customer doesn't care which department solved the problem.

They care that it was solved correctly.

The company should be designed around delivering the result, not preserving the departments that currently participate in delivering it.

And if you apply that thinking across the entire business, the organization starts looking very different.

Engineering: Stop building teams around writing code

Let's start with engineering because it's one of the clearest examples of how dramatically AI can change the operating model.

Traditionally, software companies scale engineering by hiring developers.

More features require more developers. More developers require more engineering managers. More teams require additional coordination, planning and management.

We build an organization around managing the people who write software.

But what happens when autonomous coding agents can perform much of the implementation work?

A product requirement comes in.

An agent investigates the repository, understands the relevant architecture and proposes an implementation.

Other agents can implement changes, write tests, examine security concerns and prepare deployment artifacts.

Automated checks verify the changes against established requirements.

For well-defined low-risk changes, the delivery process may be able to proceed without routine human intervention.

For complex architectural decisions, unclear requirements or high-risk changes, engineers remain responsible for deciding how to proceed.

Now ask yourself whether you still need the same number of developers and managers to deliver the same amount of software.

Maybe not.

But replacing developers with coding agents isn't the whole transformation.

The real opportunity is replacing the traditional software delivery process with an autonomous software factory.

Instead of organizing engineering around teams of developers completing tickets, you organize around systems capable of continuously delivering verified changes.

Human engineers become responsible for architecture, product quality, system reliability and improving the software factory itself.

The strongest engineers may oversee several concurrent development workflows instead of personally implementing every change.

Management changes too.

If an engineering manager spends much of the week assigning tickets, collecting status updates and coordinating releases, which of those responsibilities still require a person?

There will always be difficult technical decisions and people to develop.

But managing code production is not the same responsibility as leading an engineering organization.

The people who succeed in this environment will be those who understand software deeply enough to direct and validate autonomous development.

Not those who simply manage the people writing it.

And we have to be careful about the measurement.

More generated code doesn't mean more business value. An autonomous software factory that creates defects faster than it resolves them isn't an improvement.

The target is reliable software delivered with less human effort.

Product: Stop managing backlogs and start making decisions

Product management has a similar problem.

Look at how much time product organizations spend collecting requirements, writing tickets, maintaining backlogs, preparing documentation and coordinating with engineering.

Those activities can consume an enormous amount of time.

But none of them are the actual reason product management exists.

The business needs to decide what to build, why it matters and whether it solved the problem.

Imagine an AI-native product function, designed around AI from the start.

Customer feedback, support issues, product usage and sales requests are continuously analyzed.

Related problems are grouped together. Evidence is collected. Potential solutions are proposed.

For work that follows established product rules, the system can prepare a complete implementation request and route it into the software delivery process.

When a genuine product decision is required, a product leader receives the relevant context, alternatives, tradeoffs and likely impact.

They decide.

The system continues.

No need for five people to rewrite the same requirement in different formats.

No need for endless meetings to establish information that already exists in the business.

And no reason for a basic decision to remain unresolved for days simply because it is waiting in someone's backlog.

This doesn't make product judgment less important.

It makes it more important.

When implementation becomes cheaper and faster, the ability to decide what should be built becomes a greater competitive advantage.

A bad product decision can now be implemented very efficiently.

That's not progress.

The AI-native product organization should spend less time managing the work and more time deciding which work deserves to exist.

Support: Stop building a business around tickets

Customer support is probably one of the first departments where this transformation becomes obvious.

Today, many support organizations are measured by ticket volume, response time, resolution time and customer satisfaction.

When the number of tickets increases, we hire more support employees.

But why are we organizing the business around processing tickets?

A ticket is simply the record of a customer having a problem.

The objective should be to solve the problem, ideally before the customer needs to report it.

Imagine a support operation where autonomous agents continuously investigate incoming requests.

They have access to the product configuration, relevant logs, customer information, documentation and approved corrective actions.

They can resolve supported configuration problems, identify known defects and answer questions using verified information.

When a problem requires engineering, the investigation is already complete and the necessary evidence is attached.

For well-understood issues, the system can potentially initiate a verified correction through an approved engineering workflow.

But we can go further.

If an agent identifies the same problem affecting hundreds of customers, why wait for hundreds of tickets?

The system should detect the pattern, identify affected customers and initiate the appropriate response within its authority.

The focus moves from processing customer complaints to preventing and resolving the underlying problems.

What happens to the support team?

People focus on complicated situations, important customer relationships, unusual failures and improving the automated system.

Some issues still require empathy and direct human involvement. Some require technical investigation that the system cannot complete safely.

But routine ticket handling should no longer automatically define the size of the support organization.

The best support ticket is the one the customer never needed to create.

If we can eliminate the problem or resolve it autonomously, why build an entire workforce around managing its symptoms?

Sales: Stop paying people to perform administrative work

Sales is another department where we confuse activity with value.

Look at how much work surrounds a typical sales process.

Researching prospects. Updating CRM (customer relationship management) records. Preparing outreach. Scheduling meetings. Summarizing calls. Creating proposals. Following up on unanswered emails. Preparing forecasts.

Many companies hire sales development representatives and sales operations employees to handle large portions of this work.

Some of it requires genuine judgment and relationship building.

Much of it doesn't.

An AI-native sales operation should continuously identify relevant prospects, research their businesses and determine whether they fit the company's ideal customer profile.

It can prepare personalized outreach, maintain accurate CRM information and coordinate follow-ups within appropriate communication and privacy rules.

After a customer conversation, it can capture requirements, identify unresolved questions, prepare a proposal and coordinate the next steps.

Salespeople should spend their time where human involvement creates value.

Understanding customers, building trust, negotiating complex agreements and making commercial decisions.

Not manually moving information from a meeting into a CRM.

But this doesn't mean we should build autonomous systems that flood the internet with generic sales messages.

Sending 100,000 emails instead of 1,000 is not automatically better.

Measure qualified opportunities, conversion rates, customer acquisition costs and revenue.

If the automated process creates more activity without improving results, it hasn't achieved anything meaningful.

The objective is not to automate every sales activity.

It's to remove the administrative workload that prevents salespeople from actually selling.

Finance: Stop hiring people to reconcile information

Finance organizations are full of processes that exist because information is distributed across different systems.

Invoices arrive through email. Employees enter information into accounting systems. Someone checks the amounts against contracts. Someone else reviews the transaction.

Reports are assembled from multiple sources and managers spend time explaining discrepancies.

A lot of that work follows predictable rules.

An AI-native finance operation can collect invoices, extract relevant information, match records and identify inconsistencies.

Routine reconciliations can happen continuously rather than waiting for someone to manually prepare them.

Financial reporting can use verified transaction data instead of requiring people to repeatedly copy information between spreadsheets.

Unusual transactions can be flagged for review.

But finance also demonstrates why autonomy requires clear limits.

An AI agent shouldn't be able to invent an approval because an invoice looks legitimate.

Payment authorization, separation of duties, auditability and financial controls still matter.

For some transactions, independent human approval is necessary.

The opportunity is to automate the preparation, checking and routine execution while preserving appropriate controls over consequential decisions.

A finance professional should spend less time reconciling predictable transactions and more time understanding what the numbers mean for the business.

The company may need fewer people preparing reports.

It will still need people responsible for financial integrity, planning and decisions.

HR: Stop building administrative processes around every employee

Human resources (HR) is often discussed last in AI transformation.

It shouldn't be.

Recruiting, onboarding, employee administration, policy questions and performance processes all involve substantial amounts of coordination.

Think about hiring.

Someone prepares a job description. HR publishes it. Candidates submit applications. Recruiters coordinate interviews. Managers exchange feedback. Someone prepares an offer. Another person manages onboarding.

There are important decisions throughout that process.

There is also a lot of administration.

An AI-native people operation can automate scheduling, documentation, routine policy assistance and the administrative steps involved in onboarding.

Employees should be able to get reliable answers to standard questions without waiting for an HR representative.

Managers should have access to the relevant information needed to support their teams without requesting another report every week.

But hiring decisions, employee evaluations, disciplinary actions and other decisions affecting people's livelihoods require careful human accountability.

AI can help organize information. It should not become an unaccountable decision-maker for people's careers.

The objective isn't to remove the human element from HR.

It's to remove repetitive administration so people can focus on recruiting effectively, developing employees and resolving complex human issues.

And here's an uncomfortable question.

If your company genuinely moves toward a much smaller workforce, why would you preserve an HR operation designed for a workforce four times larger?

The requirements will change.

The organizational structure should change with them.

What happens to all the VPs and directors?

This is where the conversation usually becomes uncomfortable.

It's easy for an executive to announce that every department needs to become AI-native.

It's much harder to acknowledge that their own department might not need to exist in its current form.

If engineering becomes an autonomous software factory, product decisions are handled by a small group of accountable leaders and support resolves most routine issues automatically, what happens to the traditional leadership structure?

Do you still need the same number of directors and managers?

Do you need a separate executive responsible for every historical function?

Or could a smaller leadership team oversee several outcome-driven operations supported by shared autonomous systems?

The answer depends on the company.

But we should stop treating today's management structure as untouchable.

Leadership exists to deliver business results through people, systems and decisions.

If the operating model changes, leadership roles need to change with it.

A leader in an AI-native company should understand the business deeply enough to redesign how it operates.

They should be comfortable working with autonomous systems, measuring their performance and taking responsibility for their failures.

They need enough technical understanding to challenge whether the proposed automation actually works.

A leadership role that exists primarily to coordinate several layers of managers deserves the same scrutiny as any other role.

If you're willing to automate the work of your employees but refuse to question the structure of your leadership team, you're not transforming the company.

You're protecting the org chart.

So what does the 25% company look like?

Let's make the thought experiment more concrete.

Imagine a hypothetical software company with 100 employees.

Today, it might have a large engineering organization, separate product and support teams, a sales organization and smaller finance, HR and operations functions.

I'm not going to pretend there's one perfect formula for reducing those 100 employees to 25.

There isn't.

A company with complex enterprise implementations will have different requirements from a self-service SaaS (software as a service) business.

A company handling regulated financial transactions will need different controls from one selling a simple productivity application.

And some responsibilities require coverage, specialist expertise or independent oversight regardless of how much routine work is automated.

But I would not begin by asking each department to reduce its workforce by 75%.

That would be the wrong approach.

I would begin by asking what outcomes the company must continue delivering.

For example:

Acquiring and retaining customers.

Delivering reliable product capabilities.

Resolving customer problems.

Getting customers operational.

Maintaining financial and regulatory integrity.

Developing the people and systems responsible for those results.

Then I would design the operating workflows around those outcomes.

Some might be executed almost entirely through software.

Others would require small groups of specialists working with autonomous agents.

Certain responsibilities would remain independent because the business needs checks and balances.

The company would still need leadership, technical expertise and human relationships.

But it might not need a separate operational hierarchy surrounding every function.

The architecture of the company would determine its workforce requirements.

Not the historical allocation of headcount between departments.

Don't reduce the workforce before reducing the work

There's an important distinction between building a company that requires 25 people and cutting a 100-person company down to 25 employees.

Those aren't the same exercise.

If you eliminate 75 positions tomorrow and leave the underlying workflows unchanged, the remaining employees inherit the work.

That's not an AI-native transformation.

It's an organization operating with insufficient capacity.

The right order is to change how work gets completed and demonstrate that the replacement works.

Start with one outcome.

Build the autonomous process around it.

Run it against real business demand.

Measure its quality, reliability, full operating cost and remaining human workload.

Once it can consistently deliver the expected result, remove the redundant steps from the old process.

Then examine how responsibilities and staffing should change.

Repeat across the company.

This is also where leadership has to be transparent about the consequences.

Some employees will move into different roles. Others will need new skills. Some positions may no longer be required.

Companies should be honest about those possibilities rather than claiming AI transformation will never affect employment.

At the same time, the benefits of automation do not have to be realized only through layoffs.

A growing company might maintain headcount and expand without additional hiring. Another might use natural attrition. Others may choose to restructure.

Those are business and leadership decisions.

The principle is that workforce changes should follow demonstrated changes in the work, not assumptions about what AI might eventually accomplish.

The biggest mistake is letting departments own the transformation

There is one final problem with asking every department to reinvent itself independently.

Each department naturally optimizes the work it already owns.

Engineering builds better development agents.

Support builds better ticket agents.

Sales builds better prospecting agents.

Finance automates reporting.

All useful.

But nobody necessarily removes the handoffs between those departments.

Nobody challenges whether an entire process could operate without some of those functions participating at all.

And few department leaders are naturally incentivized to propose eliminating part of their own organization.

That's why the transformation needs ownership above the individual department.

Someone must be accountable for the end-to-end business outcomes and have the authority to change how work moves across organizational boundaries.

That person needs to understand both the business and the technology well enough to challenge existing processes.

They need to be able to ask why a task exists, whether it can disappear and what happens to the operating model when it does.

Without that authority, an AI transformation can become a collection of disconnected departmental improvements.

The company spends money on tools.

Employees become more productive.

But the organizational cost structure barely changes.

You cannot rebuild a company if every department has the right to preserve itself.

The company you would build today

Imagine starting a software company tomorrow.

You have access to capable AI models, autonomous coding systems, automated customer support, integrated business applications and the ability to build agents that execute workflows.

Would you immediately hire 20 engineers, 10 support employees, five product managers and several layers of management?

Or would you first build the systems that allow a much smaller group of people to deliver the required outcomes?

You would still need talented people.

You would still need expertise, accountability and leadership.

And the systems would need real investment to build, maintain and operate safely.

But you would have the opportunity to design the company around automation from the beginning rather than adding automation to an organization designed around manual work.

That's the challenge facing established companies.

Their competitors don't necessarily have to inherit the same departments, processes and management structures.

A new competitor can design its operating model around capabilities that didn't exist when the established company was built.

Whether it succeeds is another question.

But if it can deliver comparable quality and customer value with substantially less human effort, the competitive implications are significant.

A company that requires 100 people to deliver a result may eventually find itself competing against one that needs 25.

And that competitor won't necessarily be working harder.

It may simply have built a different company.

The uncomfortable conclusion

We have spent years treating organizational growth as evidence of business success.

More employees. More managers. More departments. Bigger teams.

We celebrate the ability to build large organizations.

But what if the next generation of successful companies is measured by how much it can accomplish without continuously adding people?

What if the advantage isn't having the biggest engineering department or the largest support operation?

What if it's being able to serve more customers, deliver better software and operate more reliably with a fraction of the organizational complexity?

That requires more than AI adoption.

It requires the willingness to rebuild engineering, product, support, sales, finance, HR and leadership around the outcomes they are supposed to deliver.

Some departments may become much smaller.

Some responsibilities may merge.

Some existing jobs may disappear while new ones emerge.

And some traditional organizational boundaries may stop making sense altogether.

The goal isn't to eliminate people for the sake of reaching an arbitrary percentage.

The goal is to create a company where every person is doing work that genuinely requires human involvement and everything else is handled by reliable systems.

Stop asking how many people each department needs.

Start asking why the department needs to exist in its current form.

Because if your goal is 100% output with 25% of the workforce, you cannot keep rebuilding the same company.