The Integrator Tangle: Accountability in Multi-Vendor Transformations

Episode 38 of the Michael Martino Show podcast, hosted by Michael, titled "The Integrator Tangle: Accountability in Multi-Vendor Transformations" was published on June 26, 2025 and runs 4 minutes.

June 26, 2025 ·4m · Michael Martino Show

0:00 / 0:00

Summary

Welcome back to The Michael Martino Show Today, I want to talk about something that’s become a hallmark of modern transformation program – working with multiple service integrators. On paper, it makes sense. You bring in specialized vendors to focus on different layers of the tech stack. One’s great at infrastructure, another leads the cloud migration, a third owns user experience, and maybe another is handling legacy retirement. While specialization is powerful, it introduce a kind of complexity that’s hard to unwind once it sets in. Why does working with multiple integrators add so much complexity? Also, how do you hold them accountable—to keep costs down, avoid scope creep, and still deliver a high-quality product? Once you're in-flight, the problems emerge fast: Conflicting delivery methodologies -- One integrator is Agile, another is waterfall, and a third thinks Agile means running a daily stand-up with no backlog. Chaos Finger-pointing: Something breaks and the infrastructure partner blames the app team, who blames the API vendor, who says “we followed the spec.” Meanwhile, your product manager is stuck in the middle Lack of a common architecture—If you don’t impose a centralized architecture strategy early, everyone builds in a vacuum—and you end up with a Frankenstein platform stitched together by PowerPoint and good intentions. Culture –Some integrators embrace collaboration. Others operate like they’re the smartest people in the room, and they’d rather win than align. The illusion of accountability Now here’s the real kicker—when things start to go off the rails, the question becomes –Who is actually accountable? If no one’s responsible for the whole, then no one’s truly responsible. This is where governance has to step up—or everything falls apart. What can you do? If you're managing a transformation with multiple service integrators, here’s how you build accountability into the structure: 1. Appoint on leader You need one party responsible for integration across the board. Sometimes it’s an internal team with strong architecture and delivery governance. Other times, it’s a lead integrator who coordinates the others under a master services agreement. But it has to be clear who owns the end-to-end performance. 2. Design for collaboration from the start Make interdependencies explicit in contracts. Define shared deliverables. Hold joint planning sessions. Create integration boards. And most importantly—make sure each partner understands how their work fits into the larger ecosystem. 3. Use incentives wisely Tie payments to outcomes, not just tasks. If you’re launching a new claims intake system, don’t just pay for code delivered—pay for working integrations, successful tests, and user adoption. Make everyone’s success interdependent. 4. Install strong product ownership The organization needs internal leaders who can speak business and tech. Product owners who understand that decisions about functionality, sequencing, and risk can’t be left to vendors alone. You can’t outsource judgment. 5. Centralize architecture and QA This is non-negotiable. You need a single team defining the data model, the integration standards, the security posture. Same with testing. If every integrator is testing in their own sandbox, you’re not testing the system—you’re testing wishful thinking. To wrap Working with multiple service integrators doesn’t have to be a disaster. But it will be if you don’t lead decisively. You need clarity. Governance. Technical leadership. An obsession with the whole, not just the parts. Transformation isn’t about managing vendors—it’s about orchestrating outcomes. If you’re not careful, you’ll end up with a beautifully executed failure. The question is –Who’s accountable for the whole? And are your partners aligned to deliver it?

Episode Description

Welcome back to The Michael Martino Show

Today, I want to talk about something that’s become a hallmark of modern transformation program – working with multiple service integrators.

On paper, it makes sense. You bring in specialized vendors to focus on different layers of the tech stack. One’s great at infrastructure, another leads the cloud migration, a third owns user experience, and maybe another is handling legacy retirement.

While specialization is powerful, it introduce a kind of complexity that’s hard to unwind once it sets in.

Why does working with multiple integrators add so much complexity? Also, how do you hold them accountable—to keep costs down, avoid scope creep, and still deliver a high-quality product?

Once you're in-flight, the problems emerge fast:

Conflicting delivery methodologies -- One integrator is Agile, another is waterfall, and a third thinks Agile means running a daily stand-up with no backlog. Chaos
Finger-pointing: Something breaks and the infrastructure partner blames the app team, who blames the API vendor, who says “we followed the spec.” Meanwhile, your product manager is stuck in the middle
Lack of a common architecture—If you don’t impose a centralized architecture strategy early, everyone builds in a vacuum—and you end up with a Frankenstein platform stitched together by PowerPoint and good intentions.
Culture –Some integrators embrace collaboration. Others operate like they’re the smartest people in the room, and they’d rather win than align.

The illusion of accountability

Now here’s the real kicker—when things start to go off the rails, the question becomes –Who is actually accountable?

If no one’s responsible for the whole, then no one’s truly responsible.

This is where governance has to step up—or everything falls apart.

What can you do?

If you're managing a transformation with multiple service integrators, here’s how you build accountability into the structure:

1. Appoint on leader

You need one party responsible for integration across the board. Sometimes it’s an internal team with strong architecture and delivery governance. Other times, it’s a lead integrator who coordinates the others under a master services agreement. But it has to be clear who owns the end-to-end performance.

2. Design for collaboration from the start

Make interdependencies explicit in contracts. Define shared deliverables. Hold joint planning sessions. Create integration boards. And most importantly—make sure each partner understands how their work fits into the larger ecosystem.

3. Use incentives wisely

Tie payments to outcomes, not just tasks. If you’re launching a new claims intake system, don’t just pay for code delivered—pay for working integrations, successful tests, and user adoption. Make everyone’s success interdependent.

4. Install strong product ownership

The organization needs internal leaders who can speak business and tech. Product owners who understand that decisions about functionality, sequencing, and risk can’t be left to vendors alone. You can’t outsource judgment.

5. Centralize architecture and QA

This is non-negotiable. You need a single team defining the data model, the integration standards, the security posture. Same with testing. If every integrator is testing in their own sandbox, you’re not testing the system—you’re testing wishful thinking.

To wrap

Working with multiple service integrators doesn’t have to be a disaster. But it will be if you don’t lead decisively.

You need clarity. Governance. Technical leadership. An obsession with the whole, not just the parts.

Transformation isn’t about managing vendors—it’s about orchestrating outcomes. If you’re not careful, you’ll end up with a beautifully executed failure.

The question is –Who’s accountable for the whole? And are your partners aligned to deliver it?