Yippee-Ki-Yay
What Die Hard Teaches Us About Platform Engineering & Team Topologies
Platform engineering might not involve crawling through air vents barefoot, but it does come with its own high-stakes challenges. In my recent talk, I explored how the lessons from Die Hard - yes, the greatest Christmas movie of all time - apply to building scalable, resilient platforms.
John McClane didn’t plan to be the hero. He was thrown into a chaotic situation, forced to react, and had to take down Hans Gruber’s operation with limited tools and a whole lot of improvisation. Many platform teams find themselves in the same position - constantly firefighting, dealing with complex legacy systems, and being the last line of defence when things go wrong.
But what if we structured teams in a way that prevented the chaos in the first place?
This is where Team Topologies comes in - a framework for structuring teams to reduce cognitive load, improve collaboration, and build scalable systems without needing a lone hero to save the day.
1. Right Team, Right Structure: Why McClane Was Always Outnumbered
McClane didn’t win by going solo - he had crucial support (shoutout to Al on the radio). But the real problem? The police and FBI had no clue how to handle the situation, which led to miscommunication and bad decisions.
In platform engineering, we often see the same problem. Teams are set up in ways that force them into reactive mode, constantly dealing with escalations instead of focusing on strategic improvements. Team Topologies gives us a better model, breaking teams down into four key types:
• Stream-Aligned Teams → Own the end-to-end delivery of features and services. These are your frontline teams, like McClane in the Nakatomi Plaza.
• Platform Teams → Build reusable infrastructure and tooling to support stream-aligned teams (think of them as the Al Powell of engineering - always there to help, but not in the direct line of fire).
• Complicated Subsystem Teams → Handle deep technical challenges that require specialised expertise (like Theo, the hacker in Gruber’s crew - but, you know, on the good side).
• Enabling Teams → Help other teams adopt new technologies and best practices (kind of like Argyle in the limo - there to support, but not bogged down in the action).
Without these clear roles, teams end up working against each other, creating unnecessary complexity and friction.
2. Adapt or Get Left Behind: Scaling Without Getting Stuck in the Vents
McClane faced unexpected challenges - broken glass, missing shoes, bad guys with machine guns. But he adapted, using his environment creatively.
Many engineering teams, on the other hand, don’t adapt. They get trapped in legacy systems, manual processes, and outdated team structures, making it impossible to scale.
Instead, we need to:
✔️ Enable self-service so teams don’t have to rely on platform teams for every little thing.
✔️ Reduce cognitive load by building intuitive, well-documented platforms.
✔️ Empower teams to own their services instead of escalating every problem.
Otherwise, you’re just crawling through air vents, hoping things don’t blow up.
3. The Power of Strategy: Why Gruber’s Plan (Almost) Worked
Gruber wasn’t just a guy with a gun - he had a strategy, using deception, planning, and well-defined roles to stay ahead of the police. His team worked together seamlessly (until McClane started picking them off).
In platform engineering, teams need that same level of strategic alignment. The best platform teams operate like product teams, treating developers as their customers and focusing on usability, automation, and self-service.
• Bad strategy → A platform team that acts as a gatekeeper, forcing dev teams to submit tickets for everything.
• Good strategy → A platform team that builds developer-friendly tools and APIs so teams can work autonomously.
If you don’t think ahead, you end up like the FBI guys in Die Hard - overconfident, reactive, and totally unprepared when things go sideways.
4. Resilience Doesn’t Always Mean Victory
McClane emerged bruised but victorious. I, on the other hand, learned that pushing for change doesn’t always guarantee a happy ending. Despite advocating for a scalable, team-aligned approach, things didn’t quite work out the way I’d hoped. Sometimes, the challenges of legacy systems, deep-rooted processes, and resistance to change win out.
But that’s okay. Because in platform engineering, just like in Die Hard, it’s about the fight, the lessons learned, and getting ready for whatever comes next.
Final Thoughts
The best platform teams don’t rely on heroics - they build systems that prevent fires before they start. The key to scaling isn’t working harder - it’s designing your teams and platforms to work smarter.
So, the next time you find yourself firefighting, ask: Are we structured for success? Or are we just crawling through air vents, waiting for the next explosion?
