If you are a software engineering manager, this will sound familiar to you: two teams are working on a shared API contract, and both have agreed on the interface.
But a few months into the project, somehow both the teams find themselves building workarounds instead of finishing their side of the work that was agreed on properly.
Why did they do that? Because each team assumed that the other team would get delayed, or have bugs, or (most commonly) just change their spec without telling the other.
In fact, I’ve seen a similar scenario play out multiple times during my career having worked on cross-team and cross-divisional initiatives and projects. In most such cases, the teams weren’t “lying” or “lazy”. Not at all. In fact, they were extremely passionate about their work, and every decision they made seemed rational in isolation. But when you looked at the project holistically, it ended up shipping much later than originally planned, and that too with a ‘patched-up’ integration that in the end neither of the teams was proud of.
Most teams call this a communication problem, or a trust problem, but what’s really running it under the hood is the Prisoner’s Dilemma.
In this post, we will unpack what this phenomenon is all about, how it works, and how you can learn to counter it as a leader.
Here’s what we will cover:
Understanding the Prisoner’s Dilemma
How This Shows Up in Leadership
Why this matters for leaders
Applying the Prisoner’s Dilemma in Practice
The Payoff Reset
Common Pitfalls (and How to Avoid Them)
Final Thoughts
Understanding the Prisoner’s Dilemma
I first came across this term during my MBA in the microeconomics class, and you may have heard of it in a similar context.
The Prisoner’s Dilemma was originally coined by Game Theory researchers at the RAND Corporation in the 1950s, in the context of the nuclear strategy during the Cold War.
Here’s how the original setup works:
Two prisoners who are arrested together are held in separate rooms so they can’t talk to each other or coordinate.
Each of them is given the same deal: either betray the other or stay silent and “hope” the other one stays silent and doesn’t betray you.
There are the possible outcomes:
Both stay silent. If both stay silent (i.e., they cooperate), both get a lighter sentence because the prosecution can’t prove much without an actual confession. This is the best combined outcome for the two of them together. But here’s the catch: it only works, if each of them is able to ‘trust’ that the other one won’t betray him/her (i.e., defect), but since they’re in separate rooms and can’t actually talk to each other, neither of them can actually know that for sure.
One betrays, one stays silent. When one of them stays silent, while the other betrays, the betrayer walks free, and here’s the pinch: the one who stayed silent takes the maximum sentence alone. Obviously, this worst case scenario is playing int he minds of hte prisoners as they make a decision. It is what makes betrayal a tempting option even if they don’t like it, because they don’t want to be the one left having to serve the maximum sentence alone. This outcome can happen in two ways, depending on who stays silent and who betrays.
Both betray. When both of the priosoners betray the other, each of them get a moderate sentence, which is worse than if they had both stayed silent, but still better than the maximum sentence of hte worst case scenario above. If you think about this carefully, this might feel like the most rational option by default because betraying kind of protects you from the ‘maximum’ sentence.
The key insight of the Prisoner’s Dilemma is this: when people make rational, self-protective decisions independently, they can add up to be the worse outcome for both parties than if they had simply trusted each other.
Here’s an interesting challenge poster which shows just how broadly applicable this is, just for your curiousity:
How This Shows Up in Leadership
Now, let’s look at how the Prisoner’s Dilemma shows up in leadership. Here’s how you map it:
Betraying becomes protecting my team’s plan (vs the shared plan)
Staying silent becomes committing to the shared plan that was agreed upon with the other team
Consider ths scenario: A new project requires two engineering teams to work on different parts of the project. Paul’s team is building the front-end of the software, whle Melina’s team is build the backend services and APIs. The front-end layer calls the backend APIs, and both teams discuss and agree on a shared plan that includes the specific interfaces and the specs, so that they can work independently and still stick to the overall timelines.
If you run the same four scenarios through this scenario, here’s what you’ll get:
Both teams cooperate: Paul’s team builds the front-end based on what was agreed, and Melina’s team builds the backend APIs to the agreed spec on time. This is the best combined outcome, but the one that only works if both sides are confident that the other will also stick to the spec and plan.
Paul cooperates, while Melina defects: Paul’s team builds the front-end as per the plan and trusts the interface completely, but Melina’s team changes the spec mid-quarter without telling Paul. Paul’s team did everything right, but because of this unexpected shift, still gets burned.
Melina cooperates, while Paul defects: in this case Melina’s team builds the back-end APIs as per the originally agreed spec, but Paul’s team made some assumptions and build a different front-end that is not compliant to the spec without informing Melina. In this case, Melina’s team burns when they discover the change.
Both teams defect: both the teams build workarounds and diverge from the original spec, and when they finally meet, they find their implementations poles apart. This is the worst outcome because it requires the maximum rework.
Why this matters for leaders
Let’s now talk about why this matters, and importantly, what you can do about this as a leader.
While the payoff matrix we just saw may look like it’s “fixed” for the teams that are in the situation, it is actually not the same for a leader who is sitting above both teams in the hierarchy, or a stakeholder who is talking to both teams.
As a leader who has visibility into both teams, and power to influence their goals and priorities, you can change how often the teams meet and coordinate. You can also set processes that catch defections or silos that lead to them in the first place.
You can bring the teams together, outside of just the project alignment, so they get to know each other as humans first, which can help them to form the trust they need to start cooperating on such projects.
In Game theory, there are two types of games involved:
One-shot games are harder to fix as they only involves “one” shot at the coordination or project. This is where the rational choice is typically deflection.
Repeated games are those where the same teams work together again, and cooperation becomes the more rational choice, and it also becomes easier to build trust over time.
So, you might be wondering, what are some things you can do as a manager in such cases? Here are a couple of strategies that I’ve seen work well:
Pay attention to the dynamics in the team - how they commit, how they coordinate with other teams, do they follow the agreed specs and terms, etc. Don’t just assume that ‘motivating’ the team will be enough for them to build trust with each other.
Create a culture of visibility and transparency. For example, something as basic as a shared weekly sync meeting where both teams look at a dashboard of the project together could be enough to reduce the uncertainty, and discourage the teams from ‘assuming’ things about what the other team is doing.
Applying the Prisoner’s Dilemma in Practice
For the rest of this article, we will focus our attention on putting the Prisoner’s Dilemma into practice in your own leadership role. As we do that, don’t forget to download the Prisoner’s Dilemma Worksheet.
Use this worksheet to:
Spot when your teams are stuck in a defect-defect situation
Map what’s actually at stake in each outcome
Turn a vague “trust issue” into a specific fix
How to download the worksheet
This worksheet is part of the Worksheets Collection, available to all paid subscribers to The Good Boss.
👉🏻 Upgrade to paid now and get instant access to the entire collection, including this worksheet.
If you prefer the standalone worksheet, you can purchase it from here.
Next, let’s discuss a technique you can use right away if you notice your teams defecting against each other.