Two teams, two ways of expressing intent, one deadline

Missed deadlines. Deliveries that don't match expectations. Growing frustration on both sides, yet everyone is acting in good faith. If this sounds familiar, you're not alone. This scenario comes up often in my work. One organisation I advised was stuck in exactly this pattern with their external development team. In this article, I'll show how two models helped us diagnose what was actually going wrong, and what you can do about it.

The situation

The organisation had hired an external team to build out a software product. On paper, the arrangement seemed straightforward: one side would define what needed to be built, the other would build it. In practice, both parties in the collaboration were struggling.

Deliveries missed the mark. The internal team felt they weren't getting enough communication or questions from the external team. The external team felt they were working hard to meet agreed deadlines, only to be told the work wasn't right. Both sides were acting in good faith, yet the relationship kept generating conflict.

I was initially brought in to remedy the situation: to get between the two teams and make the collaboration work. By investing in communication and bridging the gap between both sides, the day-to-day friction gradually improved. But a question kept nagging: what was actually causing this? The symptoms were clear, but neither team had a way to articulate the underlying problem, which meant they couldn't address it structurally.

A model for what went wrong

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

Every boundary between teams is a line on this continuum, whether that's between an organisation and an outsourcing vendor, between a product team and a platform team, or between leadership and engineering. Everything to the left of that line stays with one side. Everything to the right becomes the other's.

In this case, the boundary was between an organisation and their external development team. But the dynamic I'm about to describe is not unique to outsourcing. It plays out wherever two groups share responsibility for delivering software and have different assumptions about their working relationship.

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

The diagnosis

When I looked at the situation through this lens, two things became clear.

The first problem was an expression gap. The internal team operated on the strategic end of the continuum. They thought in terms of business outcomes, user needs, and product direction. When they communicated about the work, they used that language, describing what the product needed to become rather than exactly what to build.

The external team operated on the execution end. They thought in terms of specifications, tasks, and deliverables. They needed concrete inputs they could act on.

Neither side was translating. The internal team couldn't convert their strategic intent into the execution-ready language the external team needed. The external team couldn't work backwards from vague strategic direction to figure out what was actually being asked of them. The result was a persistent gap at the boundary: work went across, but meaning was lost in transit.

The second problem was a mismatch in interaction modes. 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.

The external team was operating in what the book calls an X-as-a-Service mode. They expected clear, well-defined inputs. They took ownership of delivery within those specifications. The boundary was a fixed point: tell us what to build, we build it.

The internal team was operating in a Collaboration mode. They expected shared responsibility for success. The boundary was a fuzzy area where work gets discovered and refined together through frequent communication.

Both interaction modes are valid, but the two sides had incompatible assumptions about which one they were in. And this compounded the expression gap: the internal team assumed the external team would help bridge the strategic-to-execution translation through collaboration, while the external team assumed that translation had already been done before the work reached them.

How it showed up in practice

Both problems, the expression gap and the interaction mode mismatch, played out in everyday communication.

The internal team would say: "We expect you to ask us questions about the work." The external team would think: "Just tell us what to build, we'll deliver it." The internal team was speaking from a strategic perspective: they knew the direction but expected the details to emerge through dialogue. The external team was listening from an execution perspective: they heard an incomplete brief and waited for the rest of it to arrive.

Over time, this gap compounded. The internal team would say: "This delivery is not what we expected." And the external team would respond: "The deadline is killing us." They weren't even frustrated about the same thing: one was talking about whether what was built matched their vision for the product, the other about timeline. The strategic intent hadn't made it across the boundary, so the execution couldn't match it.

Both sides were being reasonable within their own frame. These aren't contradictory values, but they become contradictory when there's no alignment on the boundary between the teams.

The root cause

Putting it all together, the boundary between these two teams was broken in two ways.

First, it was a translation gap. Strategic thinking went in on one side, but execution-ready instructions didn't come out on the other. Nobody was doing the work of converting between the two, and neither side realised that work needed to happen.

Second, it was an expectations gap. One side saw the boundary as permeable: a zone where requirements get collaboratively refined. The other saw it as a handoff point: once work crosses it, the receiving team owns the execution.

These two problems reinforced each other. Because the internal team expected collaboration, they didn't feel the need to fully translate their strategic intent before handing work over. Because the external team expected a clean handoff, they didn't push back when the inputs were ambiguous. They just built what they could with what they had.

This is why both sides felt frustrated despite acting in good faith. One kept expecting engagement that never came. The other kept building from incomplete inputs they didn't know were incomplete.

What the model makes possible

Before this diagnosis, both teams could feel the friction but neither could name it. The conversations stayed at the level of symptoms (missed deadlines, unclear requirements, disappointing deliveries) because there was no shared language for the structural issue underneath.

The Strategy-to-Execution Continuum, combined with the interaction modes from Team Topologies, gave both sides something they didn't have before: a way to talk about the relationship itself. With these models, the conversation shifts from blame to alignment:

1. Who's translating between strategy and execution? If one side thinks strategically and the other thinks in terms of deliverables, someone needs to bridge that gap. Is that translation happening? Who's responsible for it?

2. Where does the boundary sit on the continuum? Which activities does each side own? What about the grey areas in between?

3. What interaction mode applies at that boundary? Is this a collaboration where both sides refine work together? Or is this a service relationship where one side provides specifications and the other delivers against them?

4. 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 this case, what actually helped first was simply investing in more communication. By bridging the gap between both teams day to day, the immediate friction eased.

But there's an important constraint with outsourcing that makes this harder than it looks: you don't have full authority over how the other side works. You can invest in communication, you can name the mismatch, you can propose a different interaction mode, but you can't unilaterally change the vendor's operating model. This means that in an outsourcing context, the model isn't just a diagnostic tool for fixing existing friction; it's a lens for preventing it. If you understand these dynamics upfront, you can select vendors whose default interaction mode matches what you actually need, and align on the nature of the boundary before the first line of code is written.

The takeaway

If any of this sounds familiar (missed deadlines, deliveries that don't match expectations, frustration that keeps building despite everyone's best efforts), here's what I'd want you to take away.

Understand where the friction comes from. The Strategy-to-Execution Continuum, combined with interaction modes from Team Topologies, gives you a shared vocabulary for a conversation that most organisations don't know how to have. It lets you move past the symptoms and ask the structural questions: is strategic intent actually being translated into execution-ready language? Where do we think the boundary is? And what kind of boundary do we think this is? When both sides can see and name the mismatch, it becomes something you can discuss and resolve, rather than something you endure.

Invest in communication to ease the immediate pain. In this case, the friction improved well before the root cause analysis happened, simply because someone started bridging the communication gap between the two teams. If you're in the middle of this kind of situation, more communication is a good place to start.

Get ahead of it. If you're selecting a vendor, designing your team structure, or setting up a new cross-team collaboration, use these models before the friction starts. Align on where the boundary sits, what kind of boundary it is, and what communication patterns follow from that. The cheapest friction to resolve is the friction that never occurs.

That said, communication in the general sense only goes so far. Knowing that you need to communicate more is a start — knowing what to communicate, and how, is what makes the difference long-term. In upcoming articles, I'll share more specific tools and guidance for executives and technical leaders navigating these dynamics.

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