Business operations: the layer that decides whether growth holds

What business operations actually covers

Operations is not administration, and it is not project management. It is the set of decisions that determine how a company converts intent into delivered work: the operating model, the process design underneath it, the ownership rules that make outcomes attributable, and the reporting that tells leadership where the constraint currently sits.

In practice that means four things exist and stay current: a map of how work actually flows, a named owner for every step that can fail, a standard for what finished looks like, and a cadence where exceptions get seen before they become escalations.

Operating model

How the company is organised to deliver: teams, ownership boundaries, decision rights, and the sequence work follows from demand to delivery.

Process design

The specific steps, inputs, standards and exit conditions inside each flow — written at the level of detail a new hire could execute.

Accountability

One named owner per outcome, with the authority to act on it. Shared ownership is the polite version of no ownership.

Operating cadence

The recurring reviews where exceptions surface and decisions get made — daily for exceptions, weekly for pipeline and delivery, monthly for capacity and structure.

Operational reporting

The small set of numbers that change a decision. Everything else is context, and context belongs in an appendix.

The symptoms that bring me in

Nobody calls their problem an operating-model problem. They describe the symptom, and the symptom is almost always downstream of one of these:

• Delivery quality depends on which person picked up the work.
• Leadership finds out about slipping work from the customer rather than the system.
• Every new client or product line requires a proportional increase in headcount.
• The same three people are the escalation path for everything.
• Reporting explains what happened last month but never changes what happens next week.
• Teams are busy, and the throughput does not reflect it.

Why operations breaks as a company grows

Small teams run on shared context. Everyone can see the whole business, so the process lives in conversation and nobody needs it written down. That works, and it keeps working until one of three thresholds is crossed: a second team, a second market, or a volume level where the founder can no longer personally inspect the work.

At that point the informal system does not degrade gracefully. It fails at the boundaries first — between marketing and sales, sales and delivery, delivery and support — because those are the only places where the shared context was doing the real work. The result reads as a people problem and is almost never a people problem.

How I design an operating model

The sequence matters more than the artefacts. A beautiful process map for a flow nobody agreed on is decoration.

1. Map the real flow, not the intended one

   Trace three recent units of work — a lead, an order, a ticket — through every system and hand. Record wait time, not just touch time. The gap between them is where the money is.

2. Find the constraint

   One step governs throughput. Improving anything downstream of it changes nothing, and improving anything upstream of it increases the queue. Name it before designing anything.

3. Define ownership at the boundaries

   Every handoff gets a contract: trigger, owner, required input, standard, deadline, escalation. Most operating failures are missing handoff contracts, not missing effort.

4. Write the standard, thinly

   Document the decision rules and exit conditions, not the keystrokes. A short SOP that stays true beats a long one that stops being read in a month.

5. Instrument the exceptions

   Do not report on volume first. Report on the things that should not happen: breached response times, work sitting in a stage past its limit, records with no owner.

6. Set the cadence and hand it over

   A weekly review with a fixed agenda, run from live data, owned by the operating lead — not by me. If the system needs me in the room, it is not finished.

What the finished system contains

What good looks like

• A new hire can execute the core flow in week one using written material alone.
• Every open unit of work has exactly one accountable owner.
• Exceptions reach a human before they reach the customer.
• Leadership can name the current constraint without asking for a report.
• Adding volume changes cost sub-linearly, not one-for-one.
• The weekly review ends with decisions, not with status updates.

Mistakes that cost the most

• Documenting before agreeing. Writing the SOP for a process two teams still dispute freezes the dispute into a document nobody follows.
• Optimising the visible step. The loudest step is rarely the constraint. Speeding up work that then waits four days in a queue improves nothing except the report.
• Buying a tool as a strategy. A platform inherits whatever operating logic you bring to it. Ambiguity survives migration.
• Reporting activity instead of exceptions. Dashboards full of totals produce discussion; exception reports produce decisions.
• Making the operations lead the escalation path. If every deviation routes through one person, you have built a bottleneck and called it governance.

Where this connects

Operations sits underneath the other disciplines on this site. Automation is what you do once a flow is stable enough to deserve it. CRM architecture is where the revenue flow physically lives. Customer success operations applies the same discipline after the sale. If you want the practical version, start with the operations audit playbook or the SOP template.