Operating Model and Decision Rights

Operating Model and Decision Rights

_Joint Venture Playbook

The legal agreements tell you who owns the JV and what each side can block. The operating model determines whether the JV can execute without constant negotiation. Many ventures are negotiated with precise economics and governance, then launched with fuzzy answers to practical questions: Who prices? Who owns the customer? Who controls the product roadmap? Whose system is the system of record? In a JV, those “operating” questions are also control questions. If you leave them ambiguous, you create hidden vetoes that slow the business.

A second failure mode is letting the operating model “emerge” during stand-up. That usually means decisions fall to whichever parent has the system, the people, or the contract. The JV then becomes a coordination layer rather than a decision-making enterprise, and management is blamed for underperformance it cannot control.

11.1 Defining the JV’s Operating Model

The operating model bridges the business case and daily execution. It answers four questions: where accountability sits, where decisions are made, what capabilities are inside the JV, and what dependencies exist on the parents. A strong model makes the JV’s critical decisions easy to make and its biggest risks hard to trigger.

Most JVs fit one of three archetypes.

Integrated: The JV relies heavily on one or both parents for core functions and systems, such as sales coverage, supply operations, IT platforms, or shared services.

Standalone: The JV operates as a self-contained company with its own leadership, functional capabilities, and end-to-end accountability, using parents primarily as shareholders.

Hybrid: The JV is independent for some activities and dependent for others, using parent capabilities through structured interfaces and often with a deliberate path to greater independence over time.

The right archetype depends on what the JV must do quickly and what must be protected. Build two maps and use them as your decision filters.

Speed map: List the decisions that drive value and the cycle time the market requires for each: pricing updates, discount exceptions, capacity allocation, customer onboarding, incident response, and key hiring. If the market requires decisions in hours or days, the decision forum cannot be a slow parent committee without delegated authority and default rules.

Ring-fence map: Identify what must be separated to avoid unacceptable risk: customer data, competitively sensitive information, IP and know-how, regulatory controls, and certain liabilities. Ring-fencing informs whether you can share systems, whether you can use dual-hatted roles, and what information can flow to parents.

An integrated model can be powerful when the JV’s advantage comes from parent scale and mature platforms. It becomes dangerous when integration turns into hidden control: the parent that owns the system and the people often ends up owning the timeline. Integrated models also struggle when the JV needs neutrality, because parent commercial teams naturally optimize for parent priorities. If you choose integration, protect the JV with explicit delegations, defined service levels, and clear boundaries on what the parent can change unilaterally, including IT access rules and release cadences.

A standalone model is attractive when neutrality is required, when execution speed is a differentiator, or when competitive overlap makes information leakage a material risk. It can also be essential when regulators expect an entity that can be supervised as a complete business, including risk, compliance, and data governance. The tradeoff is cost and time: duplicating finance, compliance, and IT capabilities can destroy the case unless the value pool is large enough and the stand-up plan is disciplined. Standalone only works if parents commit to staffing and funding the JV so it can build the capabilities that independence requires.

A hybrid model works when dependencies are treated as designed interfaces with enforceable standards. Hybrid fails when dependencies remain informal favors. Under stress, favors stop, and the JV discovers it has no reliable access to what it needs. In hybrid models, you should assume you are running two operating systems at once and invest accordingly: clear interfaces, strong process discipline, and early management bandwidth dedicated to making the handoffs work.

Independence roadmap: A time-phased plan for which capabilities will become internal, which will remain shared, and what milestones trigger transitions. A practical default is early independence in customer-facing decisions, cash visibility, and compliance accountability.

Two early clarifications prevent years of friction. First, decide whether the JV is an operator or an orchestrator.

Operator vs. orchestrator: Whether the JV directly performs core activities end-to-end or primarily coordinates delivery performed by parents and third parties.

Second, decide the system of record for the JV’s critical data domains.

System of record: The authoritative source for a defined data domain, used for reporting, audit, and operational decisions. If the JV uses parent platforms, this still matters: you must define which dataset is authoritative, how the JV extracts it, and who can change it.

At the end of the operating model definition, you should be able to answer: “If performance misses the plan next quarter, who has the authority to move the few levers that will fix it?” If you cannot answer, you have not designed accountability.

A useful discipline is to publish a one-page operating model blueprint that becomes the reference point for stand-up workstreams.

  • Archetype: Integrated, standalone, or hybrid, and why.
  • Capabilities inside the JV: What functions are fully internal on day one and by month 12.
  • Key dependencies: What the JV receives from each parent and under what rules.
  • Decision rights: The few decisions that must sit in the JV versus in parent forums.
  • Independence roadmap: The planned transitions and triggers.

11.2 Interfaces with Parent Organizations

Even a standalone JV has interfaces: IP licenses, brand permissions, board reporting, and capital. Interfaces are recurring decision points. Treat each interface as a managed product with an owner, a service definition, economics, and escalation paths. When interfaces are vague, they become daily negotiations, and daily negotiations become a tax on performance.

Interface: The structured relationship through which work, decisions, services, or assets flow between the JV and a parent or affiliate.

Four interfaces drive most friction.

Sales interface: Decide who owns customer relationships, who sets pricing policy, and how quota credit and margin credit work. If a parent sells for the JV, treat the parent as a channel partner: define lead routing, service levels for quoting, minimum effort expectations, and a mechanism to resolve account conflicts. If the JV sells directly but parents retain key accounts, define boundaries and collaboration rules so customers do not receive conflicting messages.

Sales interfaces break at exceptions. A strategic customer requests a discount, a bespoke term, or a bundle that spans parent and JV offerings. The parent wants speed and credit. The JV wants margin discipline and consistent treatment. Build an exceptions policy with clear thresholds and a fast escalation path, and require post-exception review so you learn and tighten the standard playbook over time.

Supply interface: If a parent supplies inputs, capacity, logistics, or manufacturing, design for scarcity, not abundance. Define allocation rules, quality standards, lead times, and priority logic during outages. Where the JV depends on committed capacity, ensure commitments are measurable and backed by remedies, alternative sourcing rights, or inventory buffers. If the JV’s differentiation depends on reliability, treat supply performance as a board-visible KPI, not a back-office issue.

IT and data interface: Shared platforms can accelerate launch but import risk: leakage, access disputes, slow release cycles, and competing roadmaps. Define access governance, segregation controls, uptime expectations, incident response responsibilities, and data extraction rights. Also define “change rights”: what changes the JV can request, what the parent can defer, and how disputes are resolved when the JV’s commercial need conflicts with the parent’s roadmap.

Shared services interface: Shared finance operations, payroll, procurement support, and HR administration can be efficient, but the JV remains accountable. Use SLAs, service catalogs, chargebacks, and escalation so service quality and cost are visible. If the JV is regulated, confirm that outsourcing requirements are satisfied: audit rights, resilience expectations, data handling, and exit planning.

Across all interfaces, apply two rules.

  • Named interface owners: One JV leader and one parent leader own each interface, resolve issues within defined limits, and escalate quickly when limits are reached.
  • Exception governance: Define what counts as an exception, who can approve it, and how exceptions are reported so the organization learns and reduces repeat exceptions.

Also separate transaction interfaces from strategic interfaces. Transaction interfaces should be optimized for reliability and cost. Strategic interfaces—pricing, capacity, customer data, incident response—should be optimized for speed and performance, even if they cost more.

Interface norms: Practical agreements on response times, documentation expectations, and escalation behavior between JV and parent teams.

11.3 RACI and Decision-Rights Mapping for Critical Processes

After you choose an operating model, you need decision rights that operators can use without reading legal agreements. The most common failure is a generic RACI that lists committees but not the process steps where decisions occur. The second failure is “consult everyone,” which makes consultation a veto and slows execution.

RACI: A mapping that identifies who is Responsible, Accountable, Consulted, and Informed for each step of a process.

Start with a short list of critical processes: annual planning and budgeting, pricing and discounting, customer contracting, procurement, capacity planning, product change control, incident response, key hiring, and capex approvals.

Critical process: A process where ambiguity on decision rights would predictably slow execution or create repeated parent-JV conflict.

Map each process at the step level and attach four elements.

  • Authority: Who approves each step and at what thresholds.
  • Inputs: What information is required and who provides it.
  • Timing: Cycle-time standards and escalation triggers when time is missed.
  • Evidence: The minimum documentation needed for audit and learning.

Delegation bands: Predefined variance limits within which management can decide, paired with reporting requirements. Delegation bands are the difference between a board that approves a plan and a board that runs a business.

Timelines matter because they prevent indefinite consultation. Set cycle-time standards for key steps, then automate escalation when deadlines are missed.

Cycle-time standard: The expected time window for completing a decision step.

Define a default rule for silence. Silence should not become a hidden veto. For low-risk items, lack of response within the window should allow the JV to proceed with documentation. For higher-risk items, silence should trigger escalation to a sponsor with a shorter clock.

Default rule: A predefined outcome that applies when a required response is not received within the agreed timeframe.

Use decision memos to keep debate factual and fast. A good memo is short: decision required, options, impact on customers and economics, risk and compliance implications, recommendation, and the approvals sought. If a memo cannot be written concisely, the decision is not yet framed.

Decision memo: A short, structured document that frames a decision, presents options, quantifies impacts, and records the chosen path.

Make accountability explicit. The “A” in RACI should sit where outcomes are owned and tradeoffs can be made. If accountability sits in a parent forum while the JV is judged on results, you will get slow decisions and underpowered management. If accountability is split across multiple parties, you will drift and blame-shift.

Accountability: Clear ownership of outcomes, including authority to make tradeoffs and the obligation to deliver results.

11.4 Service Level Agreements and Intra-Group Arrangements

Interfaces become reliable only when they are codified in agreements that are clear, measurable, and enforceable. Intra-group arrangements should be treated like third-party contracts, with additional safeguards for conflicts and auditability. If you rely on informal commitments, you are betting the JV on permanent goodwill.

Service level agreement: An agreement defining service scope, responsibilities, performance metrics, pricing, escalation, and remedies.

Build SLAs from a service catalog, then define a small set of metrics that capture performance: uptime and recovery for critical systems, turnaround time for key transactions, accuracy standards for finance operations, and incident response times. Metrics should be auditable and tied to customer impact where possible. Avoid a long list of metrics that no one uses; focus on the few that predict service failure early.

Service catalog: A structured list of services provided by a parent or affiliate, with defined scope and service owners.

Use simple pricing principles aligned to service type.

  • Utility services: Cost-plus with clear cost definitions, allocation keys, caps, and an annual review.
  • Market-available services: Benchmarked pricing or periodic market tests.

Chargeback: The mechanism for allocating shared service costs to the JV, based on agreed pricing and usage measures.

Include change-control so the JV can request scope or performance changes without renegotiating from scratch. Also define a service governance cadence: a monthly operational review for metrics and issues, and a quarterly review to adjust scope, pricing, and investment needs.

Change-control: The process for modifying service scope, performance expectations, or pricing.

Remedies must be usable. Service credits and fee reductions create day-to-day accountability. Step-in or termination rights matter for persistent failure or for situations where a parent’s distress threatens continuity. Remedies should be proportional and executable, with clear evidence requirements.

Service credit: A predefined fee reduction applied when service levels are missed.

Beyond SLAs, intra-group arrangements often include supply, offtake, licensing, distribution, leases, and transition services. For each, define a fairness standard, priority rules for scarcity, and auditability of methodology. If benchmarking is difficult, use an agreed methodology and periodic independent review rather than ad hoc debate.

Intra-group arrangement: Any contract between the JV and a parent or affiliate, including supply, services, licensing, leases, and distribution.

Plan for independence and separation. Every critical agreement should include a transition clause that specifies data return, handover assistance, and timelines if the JV changes systems or exits. This is especially important where a parent platform is the system of record; without a transition plan, “exit” becomes impractical.

Transition clause: A provision defining how services or assets will be transferred or replaced, including data extraction, assistance, and timing.

11.5 Managing Conflicts of Interest in Day-to-Day Operations

Conflicts of interest are normal in JVs. The objective is to make conflicts visible and manageable so they do not distort decisions, undermine fairness, or create legal exposure. Treat conflicts management as an operating capability, not a compliance afterthought.

Conflict of interest: A situation where competing incentives or duties could bias decisions away from the JV’s best interest or agreed standards.

Most operational conflicts fall into three categories.

Information conflicts: Risk that sensitive information flows to a parent business that competes. Controls include role-based access, restricted board materials, clean team procedures for sensitive analysis, and consequences for breaches. If competitive overlap is material, define in advance what topics require aggregation or clean team handling, so teams do not improvise under time pressure.

Transaction conflicts: Risk that related-party transactions become a vehicle for value extraction or cost shifting. Controls include approval thresholds, transparent reporting, benchmarking or independent review where feasible, and audit rights focused on methodology. A practical tool is a quarterly related-party report: volumes, pricing method used, exceptions granted, and any methodology changes proposed.

Operational conflicts: Risk that scarce resources—capacity, engineering support, IT change windows, key personnel—are prioritized for a parent. Controls include priority rules in agreements, escalation paths with time limits, and incentives that reward parent teams for JV support. If you cannot put a rule in an agreement, treat that dependency as a risk and build a backup plan.

Dual-hatted roles require explicit rules. Secondments can accelerate launch, but they create ambiguous loyalties. Define direction, performance management, and confidentiality: daily direction comes from the JV; reviews incorporate JV input; sensitive topics follow information rules. For high-risk roles such as pricing analytics and customer data administration, prefer JV-first appointments.

Secondment: A staffing arrangement where employees remain employed by a parent while working in the JV, requiring clear direction, performance, and confidentiality rules.

Use a simple conflict protocol managers can execute quickly.

  • Disclosure: Timely disclosure of relevant conflicts.
  • Recusal: Step out of discussion and decision making when conflicted.
  • Documentation: Record decisions and the standard applied.
  • Escalation: Fast path to compliance or ethics for unclear cases.

Recusal: A requirement that a conflicted individual does not participate in deliberation or decisions on the conflicted matter.

Bright lines help. Define prohibited disclosures, restricted topics that require clean team handling, and thresholds above which related-party transactions must be reviewed by a conflicts committee. Bright lines reduce debate and make onboarding safer for new leaders who did not negotiate the deal.

Bright line rule: An objective boundary that simplifies compliance and reduces argument about whether behavior is acceptable.

When conflicts recur, treat them as a design signal. Persistent disputes about transfer pricing, data access, or capacity allocation usually mean the operating model is misaligned or interfaces are under-specified. Run an interface health review and adjust agreements, thresholds, or decision ownership, rather than letting the board meeting become a recurring courtroom.

Interface health review: A periodic assessment of whether JV-parent interfaces are meeting service levels, remaining fair, and supporting performance, with targeted fixes.

The operating model is where a JV becomes real. Your objective is not to eliminate interfaces, but to make them explicit, measurable, and governable—so management spends its time winning in the market, not renegotiating how to work together day after day.

How to get started

1

arrow-down-blue

Tell us about your project

2

arrow-down-blue

Interview candidates

(We’ll provide bios within 48 hours on average)

3

Select your consultant and start work

Find a Consultant

or email us at: [email protected]