Your software stack is not your operating system

Ask most established businesses how they run and you will be handed a list of software. A CRM, a project tool, a shared drive, an email platform, a scheduler, an accounting package, a chat app, and a spreadsheet that everybody agrees is critical and nobody wants to own. The list is usually accurate. It is also not an answer to the question.

Your software stack is the set of tools you pay for. Your operating system is the logic governing how people, information, decisions and tools work together. They are not the same thing, and only one of them determines what it is like to be a customer of yours.

The distinction sounds academic until you watch what happens when a business tries to fix the second by buying more of the first.

The upgrade that changes nothing

A company has five tools that do not talk to each other. Work falls between them. Someone proposes consolidating onto one platform that does all five things. The migration takes four months and costs more than the licences it replaces. At the end of it, the same work still falls over.

Nothing was fixed, because nothing that was broken was ever about the tools. Nobody had said who owns a new enquiry. Nobody had decided what makes something ready to hand over. Nobody had defined what done means for a piece of work, so nothing could be reliably finished. Those gaps were not in the software. They were in the operating system, and the migration carried every one of them across intact.

Replacing five subscriptions with one platform does not fix an undefined process. It concentrates the confusion.

This is the part that gets missed. Consolidation feels like progress because it reduces the number of things on the list. But the list was never the problem, and a shorter list of tools running an undesigned process is simply the same mess with fewer places to hide.

What an operating system actually consists of

Every business already has one. It is rarely written down and almost never designed; it accumulates, one decision at a time, usually under pressure. But it exists, and it has parts you can name.

• Ownership. For every kind of work, exactly one person who is responsible for it moving. Not a team, not a channel, a person. Where two people could each reasonably think it was the other's, it will stall, and it will stall silently.
• Information. What has to be known before a decision can be made, and where that lives. If the answer is somebody's head or somebody's inbox, the system runs at the speed of that person being available.
• Decisions. The points where the work forks, and the rule for choosing. Most businesses have never articulated theirs, which is why the same question gets re-argued monthly and answered differently each time.
• Handoffs. The moments work changes hands, which is where almost all of it is lost. A handoff with no defined ready state is not a handoff, it is a hope.
• Outcomes. What the work is supposed to produce, stated precisely enough that you could tell whether it happened.

Software touches all five and defines none of them. A CRM will hold your enquiries; it will not tell you who is accountable for answering one, or what makes an enquiry worth a call. That is your decision to make, and if you have not made it, the tool will faithfully store the consequences.

What we are building, and what it is not yet

Office Studio is being built the way it argues businesses should be built, which means the same distinction applies to us and it would be dishonest to pretend otherwise.

The studio's stack is short: a website, a service that delivers form submissions as email, an inbox, and a CRM that will exist when there is enough volume to justify one. Written as a list, that is unremarkable. Anyone could assemble it in an afternoon.

What takes the work is the layer the list does not show. Which enquiries are worth a diagnostic call, and on what basis. What the person enquiring should experience in the first hour, the first day and the first week. What research happens before a reply is written, and what it is for. What is recorded when we decline, so that declining teaches us something instead of just ending a conversation.

None of that is a feature of any tool in the list. All of it had to be decided, and it stays decided whether we keep the current stack or replace every part of it next year. That is the test of whether something belongs to your operating system: if swapping the software would destroy it, it was never really designed.

Where the fault is usually visible first

The website, almost always. Not because websites matter more than the rest, but because the website is where an outsider meets the system with no help from anybody inside it.

Internally, an undesigned process is survivable. People compensate. Someone remembers to chase, someone knows to check the other inbox, someone has a feel for which enquiries are real. That compensation is invisible from the outside and completely absent from it. A prospect gets the system as designed, and if it was never designed, they get exactly that.

This is why we start with the website even though the work is rarely only about the website. It is the shortest path to seeing what the rest of the system actually does when nobody is compensating for it.

How to tell which one is broken

A useful test, and it takes about a minute. Pick something that recently went wrong. Not a disaster, an ordinary miss: a reply that took nine days, a document nobody could find, a customer who was asked the same question twice.

Now ask what would have had to be true for it not to happen. If the answer is a feature you do not have, it is a tool problem, and there is a good chance the tool you already pay for has it. If the answer is somebody deciding something, and that decision has never been made, it is not a tool problem, and no amount of software will supply it.

In our experience it is almost always the second, and the reason it gets treated as the first is that buying software is a decision you can make on a Tuesday, and designing an operating system is not.

The tools are the easy part. They are also the part everyone starts with, which is why so much money gets spent to arrive back where it started.

None of this is an argument against good tools. It is an argument about sequence. Design the way the work moves, then choose the tools that carry it. Do it the other way round and you will keep buying, and keep being disappointed, and never quite be able to say why.

An Office Review is where we look at the operating system your business is already running on.