Most founder-led businesses I walk into have already bought the system. The CRM is in. The project management tool is paid for. The reporting dashboard exists. The same problems are still there, pipeline isn’t trusted, handovers fail, leadership can’t see what’s happening, decisions get stuck. The instinct is always to blame the tool or the adoption. It’s almost never the right diagnosis. The real problem is that the operating model how the business actually runs was never defined before the technology was bought to support it.

I work inside businesses turning over typically £500k to £15M, embedded as both COO and CRO. The single most common pattern I see is this: a founder has hit a wall, knows something needs to change, and reaches for a system to fix it. New CRM. New PM tool. New reporting platform. Six months in, nothing meaningful has shifted. The pipeline still isn’t reliable. Handovers still fail. The team still works around the system rather than through it.

The reason is structural. Software is the layer that supports an operating model. If the operating model isn’t defined, the software has nothing to support so it gets used inconsistently, configured around whoever shouts loudest, and ends up reflecting the chaos rather than fixing it. The tool isn’t the problem. The absence of the layer underneath it is.

An operating model isn’t a document. It’s the answer to four questions, made explicit and shared across the business. How does work actually flow from a lead arriving to cash hitting the bank? Who owns each stage, and what decisions are theirs? What does good look like at each handover? And how does leadership see whether it’s working without having to ask? Until those four answers exist in writing, every system you buy is configured against a moving target.

When I start an engagement, the first month isn’t about technology. It’s about truth. We map the lead-to-cash process as it actually runs not as it’s described in the team meeting. We identify where work stalls, where it duplicates, where quality depends on one person’s judgement. We name the single points of failure and the decisions that are sitting with the wrong owner. None of that requires software. All of it determines whether software will ever work.

Once the operating model is clear, the technology question becomes simple. You know what the system needs to do because you know what the business needs to do. You configure to a defined process rather than hoping the process will emerge from the configuration. Adoption stops being a training problem and becomes the natural consequence of a tool that fits the work.

There’s a sequence that works, and it’s worth being clear about: define the operating model, install the rhythm and reporting that holds it accountable, then choose the systems that make it scale. Done in that order, technology multiplies what’s already working. Done in reverse, it locks in what’s broken.

If you’re a founder reading this and the CRM conversation has been on the table for six months, ask one question before signing anything. Could three people in this business draw the same picture of how a deal moves from first contact to paid invoice? If the answer is no, the operating model is the work. The system comes after.

That’s where Catalyst12 starts every engagement. Operating model first. Systems second. In that order, every time.