The math is elegant. The humans aren't
Why engineering leaders are uniquely vulnerable to game-theoretic explanations of their stuck teams, and what the framework consistently misses about why nothing changes.
I found a recent Substack piece on game theory seductively compelling. The Forbidden Files published it in February and it’s been read more than eleven thousand times. The piece is a competent, accessible walkthrough of the standard concepts: prisoner’s dilemma, Nash equilibrium, ultimatum game, zero-sum versus positive-sum, repeated games, coordination games, signaling, tragedy of the commons. It ends with a paywall and a promise that paying subscribers will learn to start “winning” these games rather than just understanding them.
I want to talk about why this kind of piece spreads so well in engineering circles specifically, and why the framework consistently fails the engineering leaders who try to apply it to their teams. The failure isn’t because game theory is wrong. It’s because the framework is doing different work than its applicators think it’s doing, and the gap between what it claims to explain and what it explains is exactly where the most expensive organizational mistakes live.
Why engineering minds find game theory irresistible
The piece’s appeal to engineers and engineering leaders is not an accident. Game theory presents organizational dynamics as systems with inputs, outputs, equilibria, and discoverable optimal strategies. It promises that the messy human stuff your team is doing is a tractable mathematical structure that someone like Nash figured out the rules of. For minds trained on distributed systems and architecture, this framing lands as recognition. Of course the team is stuck in a Nash equilibrium. Of course the calibration meeting is a coordination game. Of course the engineer who undermined your design is playing tit-for-tat.
The framework feels like rigor because it borrows the surface texture of rigor. Equations, payoff matrices, named concepts with mathematical pedigree. What it borrows less reliably is the rigor’s epistemological humility. Real game theorists, the academic kind, are usually careful to specify the conditions under which their models predict actual behavior. The popular versions skip that part, because the part that sells is the elegance, not the boundary conditions.
The boundary conditions matter. Adam, in the comments on the original piece, made the point cleanly enough that I’ll borrow it: game theory “assumes rationality, stable desires, and clear payoffs. But humans don’t live inside equations.” That’s not a hand-waving philosophical objection. It’s a specific empirical claim about the conditions under which the math predicts behavior. When those conditions don’t hold, and they routinely don’t in engineering organizations, the math becomes a vocabulary for after-the-fact rationalization rather than a tool for prediction.
What “we’re stuck in a Nash equilibrium” usually means
The piece’s central example of Nash equilibrium is a couple who both want to move but in different directions, so they stay put for years. This framing maps neatly onto a thing engineering leaders frequently describe: a team locked in some suboptimal pattern that everyone privately acknowledges and nobody changes. The product manager who keeps shipping bad specs. The on-call rotation everyone hates. The architecture that everyone agrees is wrong and nobody refactors.
Calling this a Nash equilibrium gives it intellectual respectability. It also tends to be wrong about what’s holding it in place.
Real Nash equilibria require that the participants are choosing rationally given perfect information about each other’s options and incentives, and that nobody can unilaterally improve their position by deviating. In actual engineering organizations, those conditions almost never hold. What’s usually holding the bad pattern in place is some combination of: incomplete information about what the other people actually want or fear, asymmetric power that makes “deviating” carry sharply different risks for different participants, organizational incentives that punish certain kinds of change attempts, and a leader somewhere whose stated preferences differ from their revealed preferences in ways nobody’s been allowed to name.
I wrote about a version of this in Boundaries as Infrastructure: the argument that conversational-level interventions (”let’s all just communicate better and coordinate our way out of this”) don’t survive contact with real organizational pressure. The Nash framing is the engineering-leadership version of the same fallacy. It assumes the obstacle is coordination, when the obstacle is usually structure. The fix isn’t a better conversation between the players; the fix is changing the payoff matrix the players are actually operating in. The popular game theory framing rarely names this distinction, because naming it would mean admitting that someone with structural authority needs to do something the model didn’t predict.
The repeated-games fallacy in performance management
The piece’s section on repeated games and tit-for-tat is the part that engineering leaders most often try to operationalize. Cooperate with cooperators, defect against defectors, build reputation, and the system stabilizes toward mutual benefit. It sounds like a calibration strategy. It also assumes a clarity about defection that calibration rarely has.
For tit-for-tat to work, you need to reliably identify when defection occurred, communicate clearly to the defector that their behavior was noticed, and have a symmetric set of payoffs that makes “defection” meaningful in both directions. Engineering performance management has none of these features. Defection is rarely clean. The “defector” often has no idea they defected. The information about defection spreads through informal channels that filter it through whoever has the most political capital. And the payoffs are wildly asymmetric: the senior engineer who undermines a junior peer experiences different consequences than the junior engineer who tries the same move.
The asymmetric-payoff problem is the one that game-theoretic framings most consistently miss in tech contexts. The original piece’s signaling-games section is a partial exception, but it treats signaling as a neutral coordination problem instead of as a structure that channels its costs predictably to specific people. The engineer who can’t afford to spend evenings on conference talks, the parent who can’t perform unlimited availability, the woman whose assertiveness reads as “abrasive” rather than “decisive”: these aren’t equal participants in a symmetric coordination game. They’re operating in a payoff structure that rewards the same costly signal differently depending on who sends it. I’ve written about the gender-specific version of this in The Likability Tax on Technical Leadership; the broader version applies anywhere identity meets evaluation.
When engineering leaders apply game theory to performance management without recognizing the asymmetric payoffs, the result is usually that they install a model that codifies the asymmetry while believing they’ve installed a fair system. The model assumes the players are symmetric, and the players are not. The framework’s silence on the asymmetry is the problem.
What the framework does for the leader who deploys it
Here’s the part I keep coming back to, because it’s the part I don’t see discussed enough in technical-leadership circles.
The game-theoretic vocabulary does specific work for engineering leaders that has less to do with explaining their organizations and more to do with locating responsibility. “We’re in a Nash equilibrium” is a way of saying “everyone is making rational choices given the structure, so nobody is at fault, including me.” “It’s a coordination game” is a way of saying “we just need to align, and any failure to align is a collective property of the team rather than something I should have prevented.” “It’s tragedy of the commons” is a way of saying “this is structural, the incentives are misaligned, and individual intervention can’t fix it.”
Each of these framings is sometimes correct. Each of them is also a way for the person describing the situation to be in it without being responsible for it. The framework distributes responsibility evenly across rational actors, which conveniently includes the leader whose authority was supposed to shape the structure in the first place.
I wrote about this dynamic in The Leader Who Never Looks Inward: the way self-perception in leadership becomes the most expensive blind spot because it routes attention away from the structural choices the leader is making. The game-theoretic framing is a sophisticated form of this routing. It tells the leader they’re describing the system from outside it, when they’re usually one of the variables the system runs on. The senior engineer who reads the team’s stuck pattern as a Nash equilibrium is rarely accounting for the fact that her own response to disagreement is part of the equilibrium’s stability conditions.
Where game theory does help
I don’t want to overcorrect into “the framework is useless.” It isn’t. Game theory’s genuine contribution to organizational thinking is a few specific moves that survive contact with real conditions.
It teaches you to look for the payoff structure underneath observed behavior. When a team is doing something that looks irrational, asking “what are they actually being rewarded for and punished for” is a productive frame, and game theory is one of the disciplines that trained that question into modern organizational thinking. The frame holds even when the formal math doesn’t.
It teaches you that equilibria can be stable and bad simultaneously. This is an important insight that engineering organizations often miss: a pattern that has persisted for years isn’t necessarily working; it might be a local optimum that nobody can deviate from without bearing disproportionate cost. The framework gets you to ask whether the persistence of a pattern is evidence of its value or evidence of its trap-shape.
It teaches you that some games change character with repetition. Single-instance interactions and long-running relationships have different equilibria, and treating an ongoing employment relationship like a one-shot negotiation is a category error that game theory at least gives you the vocabulary to recognize.
These contributions are real. They are also much smaller and more contingent than the framework’s popular treatments suggest. The popular treatments package a useful set of analytical questions inside a confident claim about how human behavior works, and the confidence is what spreads on Substack while the questions get lost.
What to do with all this
If you’re an engineering leader and you’ve been reading the popular game theory content with a sense of recognition, the move is not to throw the framework out. The move is to develop a habit of asking three questions every time you reach for it.
First: are the payoffs in this situation symmetric, or am I treating an asymmetric structure as if it were symmetric? Most of the time in organizations, the answer is asymmetric, and the asymmetry has direction. The senior person and the junior person aren’t playing the same game. The man and the woman in the same meeting aren’t playing the same game. The recognition is the start of the work, not the end.
Second: am I using this vocabulary to describe a system I’m outside of, or am I one of the variables the system runs on? If you’re a leader and you’re describing your team’s stuck pattern in game-theoretic terms, you are almost always one of the stability conditions for the pattern. The framework’s neutral language is going to obscure this if you don’t ask.
Third: what structural intervention would change the payoff matrix, and do I have the authority to make it? Communication doesn’t change payoff matrices. Process design does. Org structure does. Promotion criteria do. Pay does. Authority does. If the answer to your stuck-team problem is “we need to coordinate better,” you’ve identified a coordination problem and not addressed it. If the answer is “I need to change the on-call comp structure,” you’ve identified a payoff problem and proposed a fix. The framework’s actual usefulness is in helping you distinguish.
The piece on Substack is a fine introduction to the concepts. The concepts are real. They’re just much narrower in their predictive power than the piece suggests, and the gap between the concepts’ actual scope and the way engineering leaders apply them is where most of the damage happens. Game theory doesn’t change your life. It might give you slightly better vocabulary for some of the conversations you’re already trying to have. The rest is the same hard structural work it’s always been, and the framework’s elegance is mostly a way to avoid noticing that.
The best engineers I know read frameworks for what they predict and what they fail to predict, with roughly equal interest. Game theory is worth reading the same way. The math is interesting. The humans it tries to describe are doing something more complicated, and most of the leadership work happens in the gap.