Open Innovation (Part 2): From T&M to Shared Outcomes
The structural blueprint for an engagement model that scales.
In Part 1, we discussed the “Enemy Within”—how internal resistance and the Not Invented Here syndrome kill projects before they start.
But let’s assume you’ve done the hard work.
The mindset is right.
Your team is ready.
You’ve selected a partner.
Now comes the dangerous part:
Structuring the engagement.
The Default Trap: Buying Headcount
Most organizations default to the path of least resistance: Time & Material (T&M), often dressed up as staff augmentation.
“I need 5 frontend developers and 2 embedded engineers for 6 months.”
“Send me the CVs. I’ll interview them. I’ll manage their daily work.”
This feels safe.
It is also a trap.
When you buy headcount, you buy effort.
When you buy outcomes, you buy value.
Taking the Fast Path requires a role change:
You stop acting like a manager of people
and start acting like an architect of value.
The Trap Explained: The “Extended Workbench”
The “Extended Workbench” model (staff augmentation) is fine for maintenance or bug fixing.
It is poison for innovation.
Why? Because the incentives are misaligned.
Your goal:
Finish the project as fast as possible, with high quality.
Their goal:
Keep engineers billable for as many hours as possible.
I’ve seen this play out countless times.
Six months in:
Velocity drops
Architecture decisions stall
Conversations devolve into arguments about scope
The partner says:
“That wasn’t in the ticket.”
The internal team says:
“But it’s obvious.”
The meter keeps running.
In this model, the partner takes zero delivery risk.
Buggy code? They bill you to fix it.
Bad architecture? “We just followed your instructions.”
You haven’t engaged a partner.
You’ve rented a slower, remote version of your own team.
The Alternative: Managed Outcomes + Core Team Model
The most successful R&D programs in my career followed a Managed Outcome model.
You don’t pay for hours.
You pay for outcomes.
You retain ownership of strategic intent:
Business objectives
Constraints
Regulatory boundaries
Non-negotiable quality bars
The partner owns execution:
Delivery approach
Staffing
Internal process
Technical realization
But in a true Managed Outcome model, the “What” is not frozen upfront.
This does not mean fixed scope with fantasy timelines.
It means:
Co-created requirements
Fixed quality gates
Clear milestones
Shared delivery risk
The partner is not a passive executor.
They are given controlled access to strategic inputs and are expected to challenge, refine, and help shape product requirements in conjunction with your internal team.
You remain accountable for direction.
They become accountable for delivery and for the quality of the solution definition.
That shared ownership is what makes the model scale.
The Structural Backbone: Core Team + Factory
This model only works if the engagement is structured correctly.
Successful programs separate the team into two layers:
A stable Core Team
A scalable Factory (Flex Team)
Think of it like this:
Business ⇄ Embedded PO ⇄ Core Team ⇄ Factory
Pillar 1: The Core Team & Embedded Product Owner
You cannot manage a 50-person offshore team from a Zoom call in France or Germany.
Communication latency alone will kill you.
The structure that works is a Core Team, anchored by an Embedded Product Owner (PO) from the partner.
The Core Team acts as the knowledge repository:
Stable over time
Deep domain and system understanding
Responsible for continuity as the wider team scales up and down
The Embedded PO (Onsite / Nearsite)
The partner provides a Product Owner who is physically present or operating in your primary time zone.
This person is not a coordinator.
They:
Sit in strategic and technical discussions
Have access to roadmap context and architectural intent
Translate ambiguous business goals into actionable product requirements
Act as the API between your organization and the offshore factory
This is where co-creation happens.
Cultural & Linguistic Alignment
The Core Team must share:
Your working language
Your engineering culture
Your decision-making norms
This “cultural proximity” ensures the partner isn’t just executing tickets—but actively shaping solutions.
Why this works:
You get the high-touch collaboration of a local colleague, combined with the scale and cost-efficiency of a global team.
Pillar 2: Joint Accountability Governance
(Engineering-Led Open Innovation)
A simple question exposes most broken engagements:
Who is accountable for delivery—inside your organization?
In the old model, the answer is vague:
“The internal PM owns it.”
“The vendor delivers it.”
“Engineering validates it.”
That ambiguity is exactly why projects drift.
In the Fast Path model, you treat Open Innovation like what it really is:
A distributed engineering organization.
That means governance cannot sit in procurement or on a single overwhelmed PM.
It requires a paired leadership system with clear interfaces.
The OI Leadership Triangle
Accountability is intentionally split across three axes: relationship, execution, and solution definition.
1) Internal Open Innovation (OI) Manager — Proxy People Manager
This role is the internal “GM” of the partnership.
They:
Own relationship health, operating cadence, and escalation
Remove organizational blockers and arbitrate priorities
Ensure access to decisions, environments, and stakeholders
Manage the integration as an organization—not a project plan
The OI Manager is responsible for the partner being productive—without turning them into staff augmentation.
2) Partner Delivery Manager — Execution Owner
This role owns delivery capacity and throughput:
Staffing and delivery plans
Velocity and quality execution
Factory operations and scaling flex capacity
Corrective actions when milestones slip
This person is not a status reporter.
They are the operational counterweight to the OI Manager.
3) Internal PO/Architect + Embedded Partner PO — Two-in-a-Box for Solution Definition
Separately from operational leadership, you establish a tight pair on the product and technical axis:
Internal PO/Architect: strategic intent and technical guardrails
Embedded Partner PO: co-creates requirements and translates intent into executable backlog
This is where co-ownership of the “What” becomes real—without losing internal direction.
How Accountability Works (No Hiding)
The OI Manager and Partner Delivery Manager are jointly accountable for delivery health
The Internal PO/Architect and Embedded PO are jointly accountable for solution definition quality
If the project is red, it’s not vendor vs internal.
Both names are on the slide—on both axes.
Without this model, escalation becomes theater.
With it, escalation becomes action.
The partner stops acting like a passenger—and starts acting like a co-pilot.
Pillar 3: The Currency of Trust — Definition of Done
Managed Outcomes reduce micromanagement.
They do not reduce control.
Control shifts from task supervision to quality gatekeeping.
Before the contract is signed, define a non-negotiable Definition of Done (DoD).
Weak DoD:
“Feature X is implemented.”
Strong DoD:
“Feature X is merged, passes agreed test coverage, meets performance and safety constraints, has zero critical static-analysis findings, and documentation is updated.”
The Definition of Done is not a Scrum artifact.
It is a commercial instrument.
When a milestone is delivered, the question is not:
“How many hours did you spend?”
It is:
“Does it pass the DoD?”
If yes, payment is released.
If no, the partner fixes it at their own cost.
That is how delivery risk is shared—and managed.
The Daily Reality: Agile in a Hybrid World
If this still feels theoretical, here’s how it looks on a Tuesday morning:
Internal Team: architecture, strategy, system integration
Partner Core Team / Embedded PO: sits with you, absorbs complexity, co-creates requirements
Partner Factory: runs its own delivery cadence, managed internally
Do not drag the entire external team into your internal bureaucracy.
The golden rule of integration:
Input: clear intent and evolving requirements via the Core Team
Process: black box (trust the partner’s delivery engine)
Output: rigid quality gates (DoD, automated tests)
The Architect’s Mindset
Moving from Staff Augmentation to Managed Outcomes is uncomfortable.
It feels like losing control.
You are no longer telling every engineer what to do every day.
That is the point.
As an R&D leader, your job is not to manage tasks.
It is to manage interfaces:
Technical interfaces (architectures, APIs)
Organizational interfaces (contracts, governance, incentives)
Architect the engagement correctly—using a Core Team that shares your culture, language, and accountability—and you won’t need to manage the people.
Stop renting time.
Start buying verified code.
Let the partner co-own delivery risk and solution definition.
That is how serious organizations scale innovation.
This is a very strong and insightful analysis. It highlights key limitations of traditional models. The Managed Outcomes approach would be very interesting to try in more traditional organizations, as it could help drive both better delivery and a more modern way of working.