DRAFT - Case study: Diagnosing outsourcing friction with the Strategy-to-Execution Continuum

A company I've been working with experienced persistent friction with their software development vendor. Deadlines were missed, deliveries didn't match expectations, and both sides felt frustrated. Using the Strategy-to-Execution Continuum model, we identified the root cause: a mismatch in how each party understood their working relationship.

The situation

The client had engaged an external development team to build a software product. On paper, the arrangement seemed straightforward: the client would define what needed to be built, and the vendor would build it. But in practice, the collaboration was struggling.

The vendor consistently delivered work that didn't match the client's expectations. The client felt they weren't getting enough communication or questions from the vendor. The vendor felt they were working hard to meet agreed deadlines, only to be told the work wasn't right. Both parties were acting in good faith, yet the relationship kept generating conflict.

Applying the model

In a previous article, I introduced the Strategy-to-Execution Continuum—a model for understanding where different software development activities fall on a spectrum from strategic (requiring deep business context) to execution (requiring specialized delivery skills).

When you engage an outsourcing vendor, you're essentially drawing a line on this continuum. Everything to the left of that line (more strategic) remains your responsibility. Everything to the right (more execution-focused) becomes the vendor's domain.

The critical question is: where exactly is that line, and do both parties agree on its location?

The diagnosis

When I analyzed the situation, a pattern emerged. The client and vendor had different mental models of where the boundary sat—and crucially, different expectations about what happens at that boundary.

The book Team Topologies¹ describes three fundamental interaction modes between teams: Collaboration, X-as-a-Service, and Facilitating. Each mode comes with different expectations about communication, ownership, and how work gets refined.

In this case, the vendor was operating in what the book calls an X-as-a-Service interaction mode. In this mode, the provider expects clear, well-defined inputs. They take ownership of delivery within those specifications. The boundary is treated as a fixed point: you tell us what to build, we build it.

Meanwhile, the client was operating in a Collaboration interaction mode. In this mode, there's an expectation of shared responsibility for success. The boundary is treated as a fuzzy area where work gets discovered and refined together through frequent communication.

Neither party was wrong. Both interaction modes are valid. But they were operating with incompatible assumptions about the nature of their working relationship.

How it showed up in practice

The mismatch manifested in day-to-day communication. Here's how the same situations were interpreted through each lens:

Both sides were being reasonable within their own frame. The client wanted dialogue and iteration. The vendor wanted clarity and execution space. These aren't contradictory values, but they become contradictory when applied to the same boundary without alignment.

The root cause

The Strategy-to-Execution Continuum helped reveal what was really happening: the two parties hadn't just disagreed about where the boundary was—they had different assumptions about what kind of boundary it was.

The client assumed the boundary was permeable: a zone where requirements would be collaboratively refined. The vendor assumed the boundary was a handoff point: once work crossed it, they owned the execution.

This explains why both parties felt frustrated despite acting in good faith. The client kept expecting engagement that never came. The vendor kept working toward deadlines that got invalidated by changing expectations.

What could have helped

The core issue was a communication gap about the nature of the relationship itself. Before diving into project specifics, both parties needed to align on:

1. Where the boundary sits on the continuum. Which activities does the client own? Which does the vendor own? What about the gray areas in between?

2. What interaction mode applies at that boundary. Is this a collaboration where both parties refine work together? Or is this a service relationship where the client provides specifications and the vendor delivers against them?

3. What communication patterns follow from that mode. How often should the teams talk? Who initiates when there's ambiguity? What happens when requirements need to change?

In hindsight, stronger project management practices could have surfaced this mismatch earlier—regular check-ins would have made the different assumptions visible before they compounded into major conflicts. But even without formal project management, simply having an explicit conversation about interaction modes at the start of the engagement could have prevented much of the friction.

The takeaway

When an outsourcing relationship isn't working, the instinct is often to look at tactical issues: unclear requirements, missed deadlines, quality problems. But sometimes the root cause is more fundamental—a mismatch in how both parties understand the working relationship itself.

The Strategy-to-Execution Continuum provides a shared vocabulary for these conversations. It lets you ask: where do we think the boundary is? Combined with interaction modes from Team Topologies, you can also ask: what kind of boundary do we think this is?

If you're experiencing friction with an outsourcing vendor—or any external partnership—consider whether the problem might be at this structural level. The specific issues you're seeing may be symptoms of a deeper misalignment that no amount of better requirements documents will fix.

Ivo Timmermans is the founder of Sparqpath, where he works as a fractional CTO and strategic technology advisor, helping companies navigate complex technical decisions including outsourcing strategy and vendor relationships.