This operating model has not been redesigned since the business was at 55 people. The five-team functional structure — Sales, Implementation, CS, Support, Engineering — worked at that scale because informal communication and a small headcount filled the gaps between teams. At 190 people those gaps have become structural breaks, and the business is losing 160 hours a week at three handoff points before anyone does billable work. NRR has slid from 112% to 98% in three quarters. Implementation is running at 2.7x its target cycle time.
Support is running at 3x. Engineering is spending half its week on reactive escalations. Headcount has doubled; ARR has not moved. The central finding is this: the backlog is not an Implementation problem. It is a Sales incentive problem that Implementation is being asked to absorb.
Commission closes at signature. By the time an account is crawling through an 82-day implementation or churning at renewal, the rep is three deals down the line and it is someone else's problem. Every other break in this org — the CS handoff, the Engineering escalation spiral — is downstream of the commitments Sales makes in the room with no one authorised to say no. The one structural change that shifts throughput most is a pre-sales Implementation review gate, combined with commission partially tied to go-live. That single intervention, properly enforced, recovers the majority of the 70 hours a week lost at the Sales-to-Implementation boundary and is the lever most likely to bring time-to-live from 82 days to the 40-45 day range needed to clear the backlog and stabilise NRR.
The business sells regulatory-reporting software to mid-market financial firms across the UK and Ireland. It has grown from 55 to 190 people in twenty months — a 3.5x increase that has outpaced the operating model's ability to scale with it. The org sits in five functional units — Sales, Implementation, Customer Success, Support, and Product & Engineering — each with a lead reporting to the CEO or COO. The structure was inherited from the 55-person org and has not been redesigned for the current scale.
The review was triggered by a board question the CEO could not answer cleanly: headcount has roughly doubled, but new-logo ARR delivered has not moved with it. NRR has slid from 112% to 98% over three quarters. A backlog of signed-but-not-live customers has accumulated. Engineering is in permanent firefighting mode. Support is buried. The burn rate is now a board-level conversation because the spend profile looks like a scaling company and the output does not.
The org is structured around functional ownership — each team owns its lane and passes work to the next. At 55 people this works because informal communication fills the gaps. At 190 people the gaps have become structural: there is no cross-functional accountability for the customer journey from signed to live, no handoff standard between teams, and no mechanism to stop bad commitments entering the pipeline. The business is structured to close deals and to build product. It is not structured to reliably deliver customers to value — and that is where NRR lives.
The org is structured around functional ownership — each team owns its lane and passes work to the next. At 55 people this works because informal communication fills the gaps. At 190 people the gaps have become structural: there is no cross-functional accountability for the customer journey from signed to live, no handoff standard between teams, and no mechanism to stop bad commitments entering the pipeline. The business is structured to close deals and to build product. It is not structured to reliably deliver customers to value — and that is where NRR lives.
| Action | Area | Rationale | Owner | By when |
|---|---|---|---|---|
| Reorganise | Sales-to-Implementation handoff | Introduce a mandatory pre-sales Implementation review gate. No contract goes out without Implementation sign-off on scope, custom integrations, and go-live date. This is the single change that stops undeliverable commitments entering the pipeline. Without it, every downstream fix — more Implementation staff, better CS handoffs, Engineering protection — is treating symptoms of a problem that keeps regenerating. The gate should be owned jointly by the Implementation Lead and COO, with CEO authority to enforce it against Sales pushback. | COO / with CEO sponsorship | Q3 2026 — this quarter. Process design takes days. The cultural enforcement is the work. |
| Reorganise | Sales compensation structure | Shift a portion of Sales commission — suggested starting point: 20-30% — from contract signature to customer go-live. Currently the incentive closes at signature and reps are structurally disconnected from delivery outcomes. Commission tied to go-live creates a financial reason for Sales to care whether the deal they closed was actually deliverable. This change should be implemented alongside the pre-sales gate, not instead of it — the gate blocks bad deals structurally; the comp change adjusts the incentive that creates them. | You | Q3 2026 for design; Q4 2026 for new contracts. Existing contracts require legal review. |
| Reassign | Support leadership | The current Support lead is a technically excellent individual contributor in a management role that requires different skills. Triage discipline is not happening, and 55 hours a week of senior engineering time is being lost as a direct result. The right move is to reassign the Support lead to a senior technical role — Solutions Engineer, escalation specialist, or similar — where the technical strength is an asset rather than a mismatch. A Support manager with operational discipline should be hired into the lead role. This is not a criticism of the individual; it is a structural correction. | COO | Q3-Q4 2026. Reassignment can happen immediately; the hire takes 6-10 weeks. |
| Document accountability | Implementation-to-CS handoff | Create a mandatory go-live record: configuration summary, open items, promise log, integration status. Implementation's definition of done must include CS being ready to serve the customer — not just the customer being technically live. This is a process change, not a hire. It costs Implementation time upfront and saves CS significantly more on the other side. NRR recovery depends partly on CS inheriting accounts it can actually manage. | You | Q3 2026. Template design takes a week. Enforcement starts on the next go-live. |
| Reorganise | Engineering intake and roadmap protection | Once Support triage discipline is restored under new leadership, introduce a formal Engineering intake filter: Support escalations require severity classification and reproduction steps before they enter the Engineering queue. Engineering gets protected sprint time — a minimum of 60-70% of each sprint ring-fenced for roadmap work. The VP of Engineering hire should not be made until the Support-to-Engineering break is fixed; hiring a VP to manage incoming chaos is an expensive way to not solve the problem. | Engineering Lead / with new Support Lead | Q4 2026, once Support leadership is in place. |
The operating model is not fit for purpose at the current scale. It was designed for a 55-person business and has not been structurally updated as the company has grown to 190. The five functional teams each perform their internal work competently — the breaks are at the seams, not inside the teams. But at this scale, seam breaks are structural failures, not coordination problems. The business is spending like a scaling company and producing the throughput of a broken one. NRR at 98% with a signed-but-not-live backlog and 160 hours a week of lost capacity at three handoff points is not a performance problem that more headcount will fix. It requires a redesign of how commitments are made, how work is handed off, and how incentives are aligned to delivery outcomes — not just deal closure.
What this is. This Operating Model Review was built through a guided conversation between Demo and Ren.
How it was built. All analysis reflects your own thinking — structured using established frameworks, sharpened, and presented clearly.
This report was produced by Ren, an AI advisor built by Renatus. It is based on information you provided during the conversation and established frameworks. It is intended to support — not replace — your own judgement. All conclusions should be reviewed before acting on them.
Renatus applies the underlying principles of established methods and credits their origin where relevant. Named frameworks, methods, and instruments are the property of their respective owners. Reference to them does not imply endorsement or affiliation.
3 frameworks were used to structure your thinking:
