What does 'operating model design' actually mean in practice?

Operating model design is the work of deciding how a business organises itself to deliver its strategy: its structure, its spans and layers, how decisions get made, what work sits where, and how the functions and technology layer connect to the value-creation thesis. In practice, it means making explicit decisions that most businesses have left implicit, often for years, and that have hardened into dysfunction. The diagnostic phase surfaces what those decisions actually are, which is usually different from what the org chart suggests.

How is this different from a restructure?

A restructure is one possible output of operating model work. The diagnostic might conclude that the structure is fine and the problem is actually decision rights: who is accountable for what, and where authority sits relative to where information sits. Or that the structure needs to change in a specific part of the organisation, not across the whole business. Operating model work starts with the diagnostic question; restructuring is one of several tools available in response to what the diagnostic finds.

How do you handle the spans and layers question?

Spans and layers analysis looks at how deep the management hierarchy runs and how wide each manager's direct reports extend. Most mid-market businesses have more layers than they need and narrower spans than they can sustain, particularly below the senior leadership level. The diagnostic identifies where the layers are creating latency, slowing decision-making, buffering information upward, or fragmenting accountability, and designs the minimum viable hierarchy against the actual complexity of the work.

What is decision rights work and when does it matter?

Decision rights work maps which decisions belong to which roles and at what level of the organisation. It matters most in two situations: when a business is scaling and informal decision-making patterns from the early stage have not been replaced with clear accountabilities; and when a new leadership team has inherited an organisation where the informal operating model is significantly different from the documented one. In both cases, the gap between nominal and actual decision authority is usually the thing driving the conflict, the slowness, or the duplicated effort the client is experiencing.

Does AI change how this work gets done?

AI is changing the capability density question: fewer people can do more complex work, which has direct implications for spans, layers, and where decision-making sits. In AI-augmented workflows, the supervision and coordination overhead assumptions that justified the existing hierarchy often no longer hold. The operating model diagnostic now routinely includes an assessment of where AI adoption has already changed the actual work (as opposed to the documented process) and what that means for the design.

How long does operating model diagnostic work usually take?

For a single business unit or a mid-market business with under 500 people, four to six weeks from briefing to written diagnostic output is typical. For a portfolio company during a 100-day plan window, the diagnostic is often run as a parallel workstream to the commercial and financial review, with outputs structured to inform the VCP. For more complex situations, including multi-entity, post-acquisition, or businesses with significant geographic spread, six to ten weeks is realistic.

Operating model design and diagnosis.

Diagnostic and design work for organisations where structure, decision rights, and the operating architecture have stopped fitting the business.

What this means

The org chart is a record of reporting lines. The total operating model is everything the org chart does not show: where authority actually sits versus where it nominally sits, how the management layer spends its time, what decisions get made at what level, and what the technology layer has made possible that the structure has not yet been redesigned to absorb. Most of those decisions are implicit. Most have never been documented, let alone tested against the strategy. Operating model design is the work of making them explicit and resolving the gaps between what the structure says and what the business requires.

The total operating model: structure, decision rights, and capability layers beyond what the org chart shows

When this work shows up

The business has grown through a period of rapid headcount addition and the management hierarchy has accumulated layers that no longer correspond to actual decision complexity.

A new leadership team has inherited an organisation where the informal operating model, meaning who actually decides what and how work really gets done, is significantly different from the org chart.

A PE sponsor has acquired a business against a value-creation plan that requires operating model change and needs a structured 100-day plan that goes beyond the commercial and financial review.

Decision-making is slow, conflicted, or duplicated across the senior team. The same decisions keep re-emerging. Accountability is unclear even when the org chart appears to assign it.

AI adoption has changed the actual work in parts of the business, but the spans, layers, and role design of the operating model have not been updated to reflect the new capability density.

How we approach it

Diagnostic: the actual operating model

Most businesses have a documented operating model and an actual one, and they are rarely the same. The gap between them is where the dysfunction lives. The diagnostic maps the actual model: how decisions really get made, where work gets created and where it stalls, what the management layer is genuinely supervising versus what it is nominally accountable for. The work is done through structured interviews across the leadership population, a review of the governance and delegation framework, and an analysis of where friction and latency show up in the operational data. The output is a written framing of which gaps are cosmetic and which are load-bearing.

Spans, layers, and management architecture

The layers in most mid-market businesses were not designed. They accumulated, added during growth phases when it felt safer to insert a management tier than to design against one, and they persist because nobody has had the standing or the data to challenge them. The spans analysis identifies where layers are creating cost without creating decision quality, absorbing information rather than acting on it. Design work then establishes the minimum viable hierarchy against the actual complexity of the work, the maturity of the leadership population, and the scale ambition in the plan.

Decision rights and accountability mapping

The most reliable diagnostic signal that a business has a decision rights problem is that the same decisions keep re-emerging. They surface in the SLT, get resolved, and reappear three months later wearing a different coat. The issue is that nobody with the authority to make them definitively actually did. In a scaling business, the early-stage pattern of founder-proximate decision-making tends to harden as headcount grows: the founder is no longer in every conversation, but the organisation has not been redesigned for a world where they are not. In a PE-backed business, the question typically sits at the interface between the portco leadership team and the sponsor: how much authority actually resides with the MD, and under what conditions the sponsor re-enters. The design work makes those accountabilities explicit and documented.

Capability mapping and the AI layer

AI has changed the capability density calculation more than most operating models have been updated to reflect. In a business where parts of the technical or analytical workforce are running AI-augmented workflows, the supervision and span assumptions built into the current hierarchy were calibrated for a lower-productivity baseline. Capability mapping now involves two distinct questions: what capability the new operating model requires from human workers, and where AI has already changed the answer without the structure having caught up. The output is a gap analysis against the new model, with a build, buy, or borrow assessment for each critical gap.

From the casebook

Fintech Operating Model Spans & Layers

Operating model redesign for a fintech scale-up post-Series B

A fintech business had grown from 40 to 180 people across an 18-month period following a Series B raise. The headcount growth had been led by the engineering and product functions. The operating model had not been redesigned since the seed stage, and a set of structural problems that had been manageable at 40 people had become acute at 180: decision-making was slow, accountability for commercial outcomes was diffuse across a senior team that had added four new hires in twelve months, and the management layer below the SLT was thin, overloaded, and losing retention battles with better-capitalised competitors.

The engagement began with a six-week diagnostic phase covering the full leadership population and a sample of the management layer below. The diagnostic identified three load-bearing problems: the organisational structure had replicated a matrix that made sense at 40 people but was creating significant cross-functional decision latency at 180; the decision rights between the founding CEO and the newly hired commercial and operations leaders had not been renegotiated after the B round, leaving the commercial team without the authority needed to execute the growth plan; and the spans in the engineering organisation were running at 3:1 in the middle of the hierarchy, creating a management layer that was supervising rather than building.

The redesign moved the business from the seed-stage matrix to a product-led operating model with clear P&L accountability at the product level. Decision rights were documented and agreed across the founding and hired leadership team, with particular attention to the commercial authority question. The engineering spans were restructured from 3:1 to 7:1, removing two layers of middle management and reinvesting the headcount cost into senior IC roles with an AI-augmented workflow that reduced the supervision need. The AI augmentation assessment was part of the engagement scope; it identified three areas where the business had already adopted AI tooling in ways that changed the supervision requirement but had not updated the management structure to reflect it.

The engagement ran twelve weeks in total. The redesign was implemented over the following quarter, with advisory support during the transition. The structural changes reduced the headcount cost in the middle management layer by 15% and were absorbed without a material retention event in the senior IC population, because the redesign had been framed explicitly as an investment in the technical career path, which was part of the engagement design.

Related advisory work

Advisory

Advisory overview

The full scope of the advisory practice and how engagements are structured.

Advisory

Transformation diagnostics

Diagnostic work for programmes that have stalled and not delivered the outcomes they were designed to produce.

Advisory

Post-acquisition integration

Integration planning and delivery for bolt-ons, carve-outs, and merger situations.

Who we work with

Private equity

Operating model and people advisory for PE firms and their portfolio companies across the hold period.

The practice is led by Sam Bramhall.

Sam Bramhall is the Principal Consultant at Esbee, with two decades of board-level strategic HR and organisational advisory across telecoms, fintech, professional services, technology, and PE-backed businesses. Engagements are principal-led: you work directly with Sam throughout, not with a junior team managing upward.

About Sam and the firm →

Frequently asked questions

What does 'operating model design' actually mean in practice?: Operating model design is the work of deciding how a business organises itself to deliver its strategy: its structure, its spans and layers, how decisions get made, what work sits where, and how the functions and technology layer connect to the value-creation thesis. In practice, it means making explicit decisions that most businesses have left implicit, often for years, and that have hardened into dysfunction. The diagnostic phase surfaces what those decisions actually are, which is usually different from what the org chart suggests.
How is this different from a restructure?: A restructure is one possible output of operating model work. The diagnostic might conclude that the structure is fine and the problem is actually decision rights: who is accountable for what, and where authority sits relative to where information sits. Or that the structure needs to change in a specific part of the organisation, not across the whole business. Operating model work starts with the diagnostic question; restructuring is one of several tools available in response to what the diagnostic finds.
How do you handle the spans and layers question?: Spans and layers analysis looks at how deep the management hierarchy runs and how wide each manager's direct reports extend. Most mid-market businesses have more layers than they need and narrower spans than they can sustain, particularly below the senior leadership level. The diagnostic identifies where the layers are creating latency, slowing decision-making, buffering information upward, or fragmenting accountability, and designs the minimum viable hierarchy against the actual complexity of the work.
What is decision rights work and when does it matter?: Decision rights work maps which decisions belong to which roles and at what level of the organisation. It matters most in two situations: when a business is scaling and informal decision-making patterns from the early stage have not been replaced with clear accountabilities; and when a new leadership team has inherited an organisation where the informal operating model is significantly different from the documented one. In both cases, the gap between nominal and actual decision authority is usually the thing driving the conflict, the slowness, or the duplicated effort the client is experiencing.
Does AI change how this work gets done?: AI is changing the capability density question: fewer people can do more complex work, which has direct implications for spans, layers, and where decision-making sits. In AI-augmented workflows, the supervision and coordination overhead assumptions that justified the existing hierarchy often no longer hold. The operating model diagnostic now routinely includes an assessment of where AI adoption has already changed the actual work (as opposed to the documented process) and what that means for the design.
How long does operating model diagnostic work usually take?: For a single business unit or a mid-market business with under 500 people, four to six weeks from briefing to written diagnostic output is typical. For a portfolio company during a 100-day plan window, the diagnostic is often run as a parallel workstream to the commercial and financial review, with outputs structured to inform the VCP. For more complex situations, including multi-entity, post-acquisition, or businesses with significant geographic spread, six to ten weeks is realistic.

Last reviewed: May 2026