Gaming Taught Me Systems Thinking

I’ve learned a surprising amount of engineering from a video game. Not from the mechanics — from the systems. Competitive team games, the Overwatch-shaped ones especially, are tight little simulators for the things that actually decide whether a group of capable people wins or loses together: communication, role clarity, feedback loops, and the brutal honesty of reviewing what went wrong. Strip out the heroes and the scoreboard and a ranked match looks a lot like a team shipping software under pressure.

Bad comms lose winnable fights

The fastest way to lose a fight you should have won is for five people to each have a correct plan that nobody said out loud. Everyone’s individually right and collectively scattered, and the other team — who called one target and committed — rolls you anyway.

Coordination beats individual correctness. A mediocre plan everyone commits to beats a brilliant plan nobody hears.

This is the standup, the incident channel, the PR description. The information that stays in your head helps no one. “I’m low, falling back,” “I’ve got ult,” “focus this one” — the engineering translations write themselves: say the thing, say it early, say it in a form the team can act on now.

Team composition is architecture

You don’t win a team game by stacking the five flashiest picks. You win by fielding a composition where the roles cover each other — someone makes space, someone holds it, someone cleans up, and the pieces are designed to work together, not just to be individually strong.

That’s architecture. A system of all star players with no coherence loses to a boring, well-composed one every time. The questions are identical: what does each piece do, what does it depend on, where are the gaps, and does the whole actually hang together — or is it five impressive parts that don’t fit? “Best component” is the wrong optimization in both rooms. “Best fit” wins.

Fast feedback beats ego

In a match, the feedback loop is merciless and immediate: you make a call, and within seconds reality tells you if it was wrong. The players who climb are the ones who update — adjust the positioning, swap the pick, change the plan. The ones who stay stuck are the ones who’d rather be right than win.

The same fork shows up at work, just slower, which makes it more dangerous. Fast, unsentimental feedback is a gift — a failing test, a blunt review comment, a metric that disagrees with your story. Ego turns that signal into an argument. The skill, in both arenas, is to hear “that didn’t work” as information instead of insult, and to change something before the round is lost.

VOD review is incident review with more screaming

Serious players review the recording. You watch the fight back, find the moment it actually went sideways — usually earlier and more boring than it felt live — and you do it without spiraling into blame, because the goal is the next game, not a verdict on this one.

That’s a postmortem. Same structure, same discipline: what happened, when did it really go wrong, what would we do differently, no scapegoats. The teams that get this right — in a game or in production — treat the review as a system for getting better, not a tribunal. The screaming is optional and, frankly, counterproductive in both venues.

Tilt is an operational risk

Tilt is when one loss bleeds into the next: you’re rattled, you make worse calls, the worse calls confirm the bad mood, and a single setback becomes a losing streak. Good players learn to treat their own state as something to manage — take the break, reset, don’t queue angry.

Engineering has tilt too; we just don’t name it. Debugging while furious. Shipping a fix at 2am on no sleep because stopping feels like losing. Letting one rough outage poison the judgment that handles the next one. Treating operator state as an actual risk — and building in the breaks that defuse it — is real reliability work, not weakness. The calmest person in the incident is usually the most useful one.

Good systems reduce panic

Here’s the through-line. The reason to care about all of it — clear comms, coherent composition, fast feedback, honest review, managing tilt — is that good systems lower the temperature. When roles are clear and the plan is shared, a bad moment is a thing you handle, not a thing that handles you.

The mark of a good system isn’t that nothing goes wrong. It’s that when something does, nobody panics.

That’s the same property I want from infrastructure, from automation, from a deploy at the wrong hour: not the absence of failure, but calm in the presence of it. A system you can operate without your heart rate spiking is a well-designed one, whether it’s a team fight or a production pager.

From the scoreboard to the codebase

None of this is a stretch I’m reaching for after the fact — it’s genuinely how the wiring in my head got laid down, and it’s why the gaming and community side of what I do isn’t separate from the engineering. The community bots come straight out of it: small systems that handle the coordination overhead so the humans can focus on the part they showed up for, which is exactly what good comms and clear roles do inside a match.

Competitive games reward the same things good engineering does — clarity, feedback, composure, and systems that keep a team calm under pressure. I just happened to learn the lesson with a scoreboard first. If you want the longer view of how the playful side and the serious side connect, the about page is the place, and if you’d rather just compare notes, come say hi.