The mechanics of target operating model design are broadly similar across situations, but the constraints and priorities change sharply depending on the strategic context. A post-merger integration is not the same animal as a cost crisis, and both are very different from standing up a carved-out business.
This chapter looks at four common contexts where TOM work features heavily, and how to adapt your approach in each:
- Post-merger integration
- Carve-outs and stand-ups
- Cost turnarounds and restructurings
- Joint ventures, spin-offs, and alliances
17.1 Post-Merger Integration: Designing a Combined Operating Model
In post-merger integration (PMI), the TOM is where you actually capture the synergies you sold to the board and the market. If you do not explicitly design a combined operating model, you almost always end up with “two companies lightly bolted together.”
You are solving for three things at once:
- Synergy realization (cost, revenue, capital, risk)
- Continuity of service for customers and operations
- A credible, motivating “new company” narrative for employees
A practical way to frame TOM in PMI is to start with three big design choices.
1. Target model posture: adopt, best-of-both, or new
Broadly, there are only a few stances:
- Adopt one side’s model (dominant acquirer pattern)
- Faster to implement; clearer for leadership.
- Less friction in integration of platforms, processes, and governance.
- Can, however, destroy value if the “dominant” model is not actually better in specific segments or regions.
- Best-of-both
- More politically palatable and often healthier in reality.
- Slower and more complex: you must actually decide, process by process, system by system, what “best” means.
- Requires more robust, fact-based diagnostics up front.
- New / greenfield combined model
- Useful when both legacy models are clearly unfit for the future strategy, or when you are pivoting to a new business model.
- Highest design complexity and implementation risk; more suited to multi-year transformations than “fast capture” integrations.
The key is to avoid the comforting but unrealistic position of “informally best-of-both” where, in practice, every local leader assumes their own way will be preserved.
2. Where to integrate vs. where to keep separate
You do not have to merge everything. Use a simple grid:
- Must integrate: areas where scale, consistency, or regulatory requirements dominate (e.g., core operations, risk frameworks, finance, major platforms).
- Should integrate selectively: where there are clear synergy pools but also material differences (e.g., channels, some salesforces, pricing teams).
- Can remain separate for now: legacy product lines near end-of-life, non-core businesses, or regions earmarked for disposal.
Map this onto:
- Value streams (Lead-to-Cash, Order-to-Delivery, etc.)
- Major functions (Operations, IT, Risk, Finance, HR)
- Platforms and data domains
Call out explicitly where you will run dual operating models for a time, and how long you are willing to tolerate that.
3. Day 1 vs. Target TOM
In PMI, you need a Day 1 operating model that simply keeps the show on the road (basic governance, delegation of authority, interim reporting and risk coverage), and a Target TOM that may take 18–36 months to fully implement.
Day 1 TOM is about:
- Clear authority: who runs what, who signs what, who can approve what.
- Basic risk and compliance continuity: who owns license relationships, who signs regulatory filings, how incidents are escalated.
- Minimal process and system connections: enough to do essential cross-company transactions and consolidations.
Target TOM is:
- The full end-state for value streams, structure, platforms, locations, and sourcing.
- The anchor for synergy estimates and detailed integration plans.
You should architect the integration roadmap around moving from Day 1 to Target TOM, not around a random collection of functional projects.
17.2 Carve-Outs and Stand-Ups: Building a TOM from Scratch
Carve-outs and stand-ups are the opposite of PMI: instead of combining two operating models, you are teasing one out of a larger parent and making it stand on its own.
The main challenges:
- Building a “minimum viable company” fast enough to meet separation timelines
- Avoiding permanent dependence on Transitional Services Agreements (TSAs)
- Designing something future-fit instead of freezing the parent’s model in miniature
A few design patterns help.
1. Define the Minimum Viable Company (MVC)
You rarely have the time or budget to recreate every function at full depth on Day 1. Start by defining the MVC:
- Which value streams must be running independently on Day 1?
- Which customers, products, and geographies are in scope initially?
- What minimum capabilities are required in each function (e.g., Finance, HR, IT, Risk) to operate legally and credibly?
Think in terms of:
- Tier 1 – Essential: capabilities you must have in-house or with strong control on Day 1 (e.g., core finance and tax, regulatory compliance, basic IT infrastructure, payroll).
- Tier 2 – Important but can be phased: things that can initially run via TSAs or external vendors but should be internalized or re-platformed (e.g., some analytics, some HR services, certain reporting).
- Tier 3 – Optional / deferred: enhancements and optimizations you will tackle after stabilization.
Design the TOM to deliver Tier 1 robustly and Tier 2 with clear migration paths.
2. Use TSAs deliberately, not as a default
TSAs can be lifesavers, but they are expensive and sticky. To avoid long-term dependency:
- For each TSA service, define:
- What is the target TOM destination (in-house, outsourced, SaaS, partner)?
- What is the cutover approach and date range?
- What must be done before TSA expiry (data migration, process design, hiring, training)?
- Build a TSA exit plan directly into the TOM roadmap, with clear responsibilities and funding.
Avoid signing up to TSAs that:
- Cover vaguely defined scopes (“IT services”) without clear boundaries.
- Lock you into parent platforms that contradict your target architecture for too long.
If you know a core platform replacement is inevitable, it may be better to stand up a lean, interim stack than to spend a fortune extending the parent’s legacy.
3. Borrow more from greenfield design
Carve-outs are a rare chance to avoid repeating legacy mistakes. Apply more greenfield thinking:
- Challenge the inherited process landscape: do you really need all those variants and exceptions?
- Embrace modern delivery patterns early (e.g., shared services from day one, cloud-first, API-first, product-oriented tech teams).
- Right-size governance and overhead: it is easy to copy the parent’s heavy committee structure even though the carved-out company is smaller and more focused.
At the same time, be realistic:
- Over-designing a sophisticated TOM for a small carve-out can create cost and complexity the business cannot bear.
Focus your most advanced TOM moves where they align with growth ambitions or regulatory needs, not everywhere.
17.3 Cost Turnarounds and Restructurings: When Money is Tight
In cost crises and restructurings, the temptation is to run a pure headcount-reduction exercise and call it an operating model. That approach may hit short-term targets but leaves a brittle, demoralized organization and usually requires another restructuring soon after.
A TOM lens helps you change the cost structure, not just the cost level.
1. Clarify what must be protected
In deep cost programs, you need a priority map:
- Revenue engines and customer relationships that cannot be compromised
- Capabilities critical to strategic pivots (e.g., key digital or analytics functions)
- Minimum viable risk and control functions to stay within appetite and regulation
Make explicit choices:
- “We will not touch X in this wave” (or “only after Y is stabilized”).
- “We are prepared to cut deeply in A/B/C areas, even if service levels dip, because they are not differentiating.”
If you do not do this, every unit will claim to be “too strategic to cut,” and you end up with blunt, across-the-board reductions.
2. Use TOM to identify structural cost levers
Instead of starting from headcount lists, start from TOM levers:
- Consolidation: how many locations, platforms, teams, and variants can be removed?
- Standardization: where can you eliminate bespoke processes and shrink exception handling?
- Sourcing and automation: which activities move to shared services, lower-cost locations, or automation?
- Simplification: which products, channels, segments, and reports can you exit or rationalize?
For each, translate into:
- Process changes (e.g., one global process instead of many local ones)
- Structural moves (e.g., create or expand shared services, close sites)
- Tech and data requirements (e.g., basic workflow, rationalized tools)
This reframes the conversation from “cut 20% in each department” to “change the way work is done so that we need 20% less effort structurally.”
3. Sequence “survival moves” and “foundation moves”
In a crisis, you often need immediate savings to stabilize. But if those moves undermine the future TOM, you will pay for it.
Pragmatic pattern:
- Wave 0 – Stabilize
- Immediate spend controls, hiring freezes, temporary reductions, tactical vendor renegotiations.
- Minimal TOM change: you are buying time, not designing yet.
- Wave 1 – Structural TOM moves with near-term impact
- Consolidate obvious overlaps (e.g., duplicate regional centers, redundant reporting lines).
- Simplify product or customer portfolios where the economics are clearly negative.
- Start moving standardized work into shared services or automation where implementation is short.
- Wave 2 – Deeper TOM shifts for resilience
- Broader platform simplification.
- More complex location moves.
- Re-architecting governance and roles for leaner, faster decision-making.
Throughout, maintain a simple value tracking view: which TOM moves contribute how much to the cost target, by when, and at what risk. This keeps restructuring decisions grounded.
4. Manage morale and credibility carefully
Cost restructurings are emotionally charged. The TOM can help or hurt:
- If you can explain how the new operating model will be better (simpler, clearer, less firefighting), people are more likely to stay and engage.
- If you only talk about “cost and synergies,” you will lose critical talent exactly where you need it most.
Use the TOM narrative to:
- Show that cuts are not random but linked to a coherent future model.
- Signal where you are still investing (and why).
Provide a path for people to see themselves in the future organization.
17.4 Special Situations: Joint Ventures, Spin-Offs, and Alliances
Joint ventures (JVs), spin-offs, and strategic alliances bring additional complexity: you are designing an operating model that must interface with one or more other enterprises, each with their own TOM and politics.
The main design questions are around boundaries, governance, and optionality.
Joint ventures
In a JV, you typically have:
- At least two parent companies with different cultures, systems, and risk postures
- Shared ownership but not always aligned incentives over time
- A JV entity that must operate credibly in the market while depending on parents for some capabilities
Key TOM design topics:
- What is inside the JV vs. provided by parents?
- Inside: activities core to the JV’s proposition and differentiation (e.g., product development, local operations, front line).
- From parents: things where scale and existing capabilities dominate (e.g., some back office functions, some platforms, brand elements).
- Service models with parents
- Formalize parent-to-JV services much like TSAs: scope, SLAs, pricing, change mechanisms.
- Design interfaces to be as standardized and API-like as possible to minimize friction.
- JV governance
- Decision rights between JV management and parent representatives.
- How conflicts are resolved when parents’ interests diverge (e.g., product roadmap, vendor choices).
- Risk and compliance oversight (which risk frameworks apply, who signs off on what).
- Decision rights between JV management and parent representatives.
Your TOM for a JV should make it very clear how independent the JV really is, operationally and commercially.
Spin-offs
Spin-offs share some DNA with carve-outs but with a twist: you are often creating an entity that needs a distinct identity and growth trajectory, sometimes with public market scrutiny.
TOM implications:
- You can often give the spin-off a more agile, focused operating model than the parent (fewer layers, more product or segment orientation).
- You must still manage dependencies and TSAs, but there is often a stronger push to remove them quickly to demonstrate independence.
- Investor messaging will hinge on how the new TOM supports faster decision-making, sharper capital allocation, and cleaner accountability.
Here, your TOM story is as important externally (analysts, investors) as internally.
Alliances and strategic partnerships
In alliances, there is no new legal entity, but your operating model will still change:
- Shared service offerings or bundles.
- Joint go-to-market in certain segments or regions.
- Shared data, platforms, or infrastructure.
TOM considerations:
- Joint processes: how leads are shared, how joint solutions are sold and delivered, how support is coordinated.
- Data and systems integration: what data is shared, under what rules, and in which tools.
- Risk and compliance interfaces: how each party ensures that joint activities stay within both organizations’ risk appetites and regulatory requirements.
In alliances, you rarely get to redesign everything, so your TOM work is mostly about defining and industrializing the touchpoints:
- Joint governance forums (e.g., alliance steering committees).
- Shared KPIs (e.g., joint revenue, joint NPS, joint incident rates).
- Simple escalation paths when things go wrong.
Across all these contexts, the core TOM discipline is the same: translate strategy into operating requirements, design an integrated future state, and build a sequenced path to get there. What changes is where you start, what you optimize for, and which constraints dominate.
