Ways of Working: The Operating System Your Team Never Designed

Ask any team "what are your ways of working?" and you will usually get a blank look, followed by something about a Monday meeting. But watch that same team for a week and you will see a rich, detailed operating system in full flight: who really makes decisions, where information actually lives, what "done" secretly means, which approvals are real and which are theatre. Every team has ways of working. Almost none of them ever chose them.

Your team's ways of working are the operating system everything else runs on, every tool, every project, every new hire. And like any operating system that was never designed, it is full of undocumented behaviour that only the old hands know.

That is not a culture problem or a people problem. It is a design gap, and it is one of the cheapest things in your business to fix.

The rules nobody wrote down

Unchosen ways of working grow the same way footpaths do, someone walked that way once, it worked, and now everyone does. The quote format that lives in Linda's head. The unspoken rule that nothing is final until the owner has seen it, even though three people have sign-off on paper. The job card that is "done" when the technician says so, or when the client signs, or when the invoice goes out, depending on who you ask. Each of these is a rule. None of them is written anywhere, and that is precisely what makes them expensive.

The cost shows up in two ways. The first is rework: when "done" means three different things, work bounces back, handovers drop details, and the same conversation happens four times because nobody knows where the answer was put. The second is key-person risk: when the rules live in heads, the people become the system. Lose the person, lose the system. We have seen businesses where one resignation letter effectively deleted the dispatch process.

Unwritten rules are still rules. You are paying to enforce them either way, the only choice is whether new people learn them from a page in ten minutes or from their mistakes over six months.

The six pieces worth designing

You do not need a process manual the size of a phone book. In our experience, six decisions cover most of what matters:

• Meeting hygiene. Which meetings exist, what each is for, and what each must produce. A meeting that does not produce decisions or actions is a podcast with worse production values.
• Decision rights. Who decides what, up to what amount, without asking. Most bottlenecks in a growing business are not capacity problems, they are decisions queueing outside one office.
• Definition of done. For your core work, what does finished actually mean, tested, documented, invoiced, client notified? Write the checklist once and the arguments stop.
• Handover rituals. What must be true before work passes from sales to ops, ops to invoicing, day shift to night shift. Most "dropped balls" are handovers with no agreed shape.
• Documentation habits. What gets written down, where, by whom, at the time, not at year-end in a panic.
• A single source of truth. For each kind of information, one agreed home. If the answer to "where is the latest version?" is a shrug and three folders, every other habit on this list is fighting uphill.

Design it in a day, honestly

The good news is that this is not a six-month transformation programme. The teams we work with get the bulk of it done in one structured day. Get the actual team in a room, not just managers, because the people doing the work know where the real rules are. Walk one piece of work end to end, a sale, a job, a project, and write down what actually happens, not what the org chart says should happen. Every time someone says "well, usually...", you have found an unwritten rule. Then decide, together, the six pieces above, and write each one down in a sentence or two.

Keep it light enough to survive

Here is where most attempts die: someone turns the workshop output into a 40-page process document, and within a month it is as unread as the last one. The discipline is brutal minimalism. One page or two, short sentences, kept where people actually work, not buried in a shared drive subfolder. And make it a living thing, when reality and the page disagree, change one of them deliberately instead of letting the page quietly become fiction. A ten-minute review once a quarter is enough.

Why this decides whether new tools stick

Here is the part that connects to everything else we write about. When businesses tell us "we bought the system but nobody uses it", or "we tried AI and it didn't take", the post-mortem almost never finds a technology problem. It finds a ways-of-working problem. The new tool assumed information would be captured at the time, but the habit was to reconstruct it at month-end. The AI assistant could have drafted every quote, but the quoting "process" lived in one person's head, so there was nothing to teach it.

Tools automate processes. AI amplifies processes. If the process is undefined, there is nothing to automate and nothing to amplify, just chaos at a higher speed. The teams that get real value from new systems are the ones who did this unglamorous groundwork first, agreed what done means, agreed where truth lives, agreed who decides. Design the operating system on purpose, keep it light, and everything you install on top of it, software, dashboards, AI, suddenly has something solid to run on.