A company is one product. And every bad process is its technical debt.

Most companies were never designed. They grew. First came a founder and one spreadsheet, then a salesperson with their own contact list, a bookkeeper with their own software, production with its own planning. Every one of those decisions was defensible at the time. Their sum, ten years on, almost never is.

A more useful model is this: a company is one product. It has users, interfaces, flows, databases, legacy, defects and a user experience. And just like a software product, it carries technical debt on which interest is paid, even though no chart of accounts records it.

This is not a metaphor for effect, it is a working model that changes where you look for the problem. If the company is a product, slow invoicing is not a departmental failure but a defect in the flow. And a defect is not fixed by training, it is fixed by redrawing the flow.

The company did not appear all at once, it grew layer by layer

Departments are born in response to pain. One person can no longer keep up, so two are hired, each with their own tool and their own metric. From that moment on, every department optimises whatever it is measured on: sales counts signatures, production counts capacity utilisation, finance watches days sales outstanding, support watches first response time. Each of those metrics is perfectly sensible on its own.

Yet the local optimum of one layer almost always creates extra work in the layer next door. A textbook example: a salesperson agrees non-standard payment terms because contracts are what gets counted. Finance then processes a manual exception, production is handed a deadline nobody planned for, and support explains why the invoice does not match the quote. Nobody made a mistake. The system is badly designed.

From the customer's point of view there is only one company

The customer does not know where sales ends and invoicing begins. They see one chain of touchpoints and experience it as one thing. Customer experience, meaning the customer's experience across the whole relationship with the company, is not the average of those touchpoints. It sits closer to the weakest link in the chain: people remember a failure better than a smooth ride, and they judge the entire relationship by it.

That is why a process is measured along its full length, not department by department. The question is not how fast the warehouse works, but how many hours pass between order and delivery, and where the shipment is simply sitting still.

Three groups of users of the same product

Each group uses a different part.

• The customer uses the public interface: the website, the quote, the order, the invoice, support.
• The employee uses the internal interface: systems, forms, approvals and spreadsheets that nobody ever designed, they simply accumulated.
• Management uses the layer of data and reports it makes decisions from.

Budgets rarely mirror this. The public interface has an owner and a metric, the internal one usually has neither, so nothing is invested in it until it catches fire. And yet employee experience, meaning what it feels like to work with your own company's tools and rules, feeds straight into performance. According to 2017 research by the MIT Center for Information Systems Research, based on a sample of 281 senior managers, companies in the top quartile of employee experience were twice as innovative as companies in the bottom quartile, measured by the share of revenue from new products and services, and they posted 25 percent higher value on an industry profitability metric. These are correlations drawn from managers' own assessments, not proven causation. Even so, time spent working around your own system creates value for nobody.

A process is a user flow, only nobody ever drew it

In product design, a user flow is the sequence of steps a user goes through to reach a goal. Every unnecessary step costs time and raises the chance of error. A business process is the same thing, only nobody ever tested it.

Friction can be priced with a formula we call Cost of Friction: the time of one repetition multiplied by frequency, by the number of people involved, by hourly cost. A step that takes only a moment, but is performed daily by an entire department, tends to cost more than a project handled once a year. Without that calculation, priorities go to whoever shouts loudest. We set out why design is a tool for saving time and money in Good design is not decoration.

Internal systems are the company's interface, the brand is only its cover page

In our model a company has five layers: Brand, Experience, Systems, Automation, Intelligence. The brand is the external interface, the promise. Internal systems are the interface through which somebody actually delivers on that promise. When the two diverge, the promise always loses: a company can have an immaculate visual identity and still send order confirmations from a warehouse worker's personal inbox.

The reverse holds too: an internal system nobody wants to use is not a discipline problem, it is a design problem. People route around company tools for the same reason customers abandon a bad checkout. The path is longer than it needs to be.

Data is infrastructure, not reporting

If the same customer exists in five systems in five different versions, the company does not have a customer. It has five assumptions. Data architecture, meaning the agreement about where the truth about a customer, an order and a price comes into being, is infrastructure in the same way electricity is. You do not see it until it goes down.

That is why the Automation and Intelligence layers cannot be built before the Systems layer. Automation on inconsistent data does not make a company faster, it only reproduces the error faster. We described this in AI will not fix a broken process.

A legacy process is technical debt and it charges interest

Ward Cunningham coined the technical debt metaphor in 1992, and his original meaning is more precise than the way it tends to be quoted today: debt is not a synonym for poor work, it is a deliberate temporary simplification that speeds the work up, provided it is repaid soon by rewriting. The borrowing is not the danger, failing to repay is. Every minute spent working with not quite right code is, in Cunningham's terms, interest.

Translated into a company: a legacy process is a procedure that has outlived its own reason. The report goes out every Monday because a manager who no longer works here asked for it years ago. Nobody stopped it, because it does not hurt anyone loudly enough.

The interest is measurable. According to a longitudinal study by Besker, Martini and Bosch, in which 43 developers logged their work for seven weeks, developers lose an average of 23 percent of their time to technical debt. These are the participants' own estimates, not objective measurement. The study also shows a second property of debt: in roughly a quarter of the situations where they hit debt, developers are forced to introduce more of it. Debt reproduces itself, exactly like a process in which one exception is resolved by another exception.

The CISQ consortium puts accumulated technical debt in software in the United States at roughly 1.52 trillion dollars. The report itself concedes that this is an inflation adjustment of an older estimate and that it has no good estimate of the interest yet. The consequence is the instructive part: technical debt has become the single biggest obstacle to change in existing code. Inside a company the same sentence sounds much simpler: “that cannot be changed here.”

Silos are not a cultural problem, they are an integration problem

In 1968 Melvin Conway formulated the observation we know as Conway's law: organisations that design systems are constrained to produce designs that copy their own communication structures. A breakdown in the organisation, he argued, shows up in the structure of the system. This was not an empirical study but an essay drawn from practice.

Confirmation came later. Researchers from Microsoft Research and the University of Maryland analysed the development of Windows Vista, specifically 3,404 binaries and more than 50 million lines of code. Metrics of organisational structure predicted the failure-prone parts of the system with 86.2 percent precision and 84.0 percent recall, beating code churn, complexity and test coverage. The authors caution that this is one company and one product, yet how the people were arranged predicted defects better than the properties of the code. The study by MacCormack, Rusnak and Baldwin adds a mirroring effect to this: in financial software, changing a single file could affect an average of 7.74 percent of the system in a loosely coupled organisation, against 47.14 percent in a tightly coupled one.

Two things follow. If two departments send work to each other by email, your data integration will look exactly like that. And it can be turned around: the practice known as the Inverse Conway Maneuver deliberately changes the structure of teams so that the desired architecture emerges from it. According to the 2022 DORA report, high performing teams that meet their reliability targets were 40 percent more likely to be built on a loosely coupled architecture, meaning one where a team can ship a large change without waiting for other teams. This is a correlation from a self-reported survey of more than 1,350 professionals.

Redesigning a company works the same way as redesigning a product

The sequence is the same as for a product, and none of it can be skipped.

1. Research. Conversations with the people who actually do the work, not with their managers. We are after reality, not the policy document.
2. Mapping. One process from beginning to end, with every wait, rekeying and exception.
3. Prioritisation. Cost of Friction plus the question of where a small change has a large effect. Donella Meadows calls such places leverage points and names the corporation directly as an example of a complex system. She quotes Jay Forrester on this: people usually find the leverage point correctly, they just push it in the wrong direction.
4. Prototype. The new procedure on one team, with measurement, not a company-wide rollout.
5. Implementation. Only here does the tool arrive. Technology is the last decision, not the first.
6. Measurement. The same metric before and after. Without it, all you have is an opinion.

One hard order of operations sits above the whole sequence: eliminate, simplify, automate, augment. First remove what is not needed, then simplify what remains, only then automate, and finally augment human capability with tools, AI included. Anyone who starts at step three is buying a more expensive version of the original problem. We set out what a company would look like if it were built from scratch in our piece on building a company without an admin army.

What never to automate without understanding people

Do not automate a process you do not understand in detail, one that is full of exceptions, or one you have never watched being done live. Automation is concrete: it sets in exactly the shape you give it, deformities included.

Undocumented workarounds are information, not sabotage. They mark precisely the spot where the system is bad. W. Edwards Deming estimated that around 94 percent of problems belong to the system and are the responsibility of management, while the remaining 6 percent are special causes. He framed it as a personal estimate from experience, not as a measured quantity. Even so, it captures exactly why replacing people rarely helps. According to the notes of a participant at his 1993 seminar, he put it more bluntly still: a bad system will beat a good person every time.

One more thing you rarely hear in our trade: not every problem needs its own software. Some processes are fixed by scrapping a report, by one shared form, or by an off-the-shelf tool costing a few tens of euros a month. Custom development only makes sense where the process is genuinely specific and its friction outweighs the price of both building and maintaining it. Anyone offering development before they have understood the process is selling a tool, not a solution.

A company is not a set of departments. It is a system

Systems thinking means one discipline: judging the behaviour of the whole, not the performance of the parts. A company with five excellent departments and five bad handovers between them is a slow company. Delays and errors do not arise inside departments, they arise in the handovers between them, where the process has no owner.

Once you accept that a company is one product, the questions change too. Instead of “who broke this” comes “where in the flow does it arise”, instead of “let us buy a system” comes “which step does not need to be here at all”. And instead of one grand transformation comes a series of small interventions at the points of greatest leverage. The first step is not a purchase or a reorganisation, it is an honest diagnosis of one specific flow.

Key takeaways

• Pick one process that touches the customer and map it from first contact to paid invoice, waiting time included.
• Calculate the Cost of Friction: time multiplied by frequency, by the number of people, by hourly cost. Only then decide the order of changes.
• Build a list of legacy processes with a single question to the team: what do we do only because it has always been done this way? Anything without a valid reason is debt now due.
• Hold the order: eliminate, simplify, automate, augment. Automating a bad process is only a more expensive version of the same problem.
• Before buying a tool, answer which step it removes. If there is none, you are not buying a solution, you are buying another layer.