Martin Seligman spent decades on a question that sounds too soft to matter and turns out to decide almost everything: not what happens to a person, but how they explain it to themselves an hour later. He found three dials. Is the cause permanent or passing. Is it everywhere or just here. Is it me or the situation. Two people can lose the same account, miss the same ship date, push the same bug to production — and walk out of the building carrying two different futures, because they told themselves opposite stories about one event.
We don’t usually count that as engineering. We should. Most of what we build — the dashboards, the retros, the incident reviews, the quarterly decks — is machinery for producing explanations. And the machinery is optimized for the wrong output. It’s tuned to assign a cause, close the ticket, and move on. It is almost never tuned to notice that the cause a team lands on becomes the ceiling on what that team will attempt next.
Here’s the uncomfortable part. A team that reads a failure as permanent and personal — “we’re just not the kind of group that ships clean releases” — will quietly stop trying to ship clean releases. Not through any decision anyone would defend out loud. Through a thousand small hedges. The story arrives first and the behavior follows it down. You can hand that team better tools, more headcount, a faster pipeline, and watch the improvement evaporate, because you upgraded the mechanism and left the explanation untouched.
The people who study dialogue for a living have a phrase for the thing that actually moves: the shared pool of meaning. The idea is plain. In any room, everyone is holding a piece of what’s true — what they saw, what they suspect, what they’re afraid to say. The quality of the decision depends entirely on how much of that gets poured into the middle where everyone can see it. And what governs the pouring isn’t intelligence or seniority. It’s safety. People add their piece when it feels safe to add it and hold it back when it doesn’t. Withhold enough pieces and the smartest room in the building will confidently decide on a fraction of the picture and call it consensus.
This is the quiet gap under a lot of tooling. We keep building systems to move information faster — faster feeds, faster search, faster models that summarize the thread you didn’t read. Speed is real and it’s worth having. But speed does nothing for the piece someone chose not to say. You cannot retrieve what was never put in the pool. The bottleneck was never bandwidth. It was whether the junior engineer felt they could name the thing the senior architect got wrong, and most of our elegant systems route straight around that question as if it were someone else’s department.
There’s a version of this in selling, too, which is really just persuasion with a receipt attached. The old craft — understand the situation, define the problem, sit in its implications long enough to feel the cost, and only then talk about the payoff — is a discipline of not skipping to the answer. Most bad pitches, most bad products, most bad strategy decks fail at the same joint: they arrive with the solution before anyone has agreed on the problem. They’re answering a question the room hasn’t finished asking. The competence isn’t in the closing line. It’s in the patience to stay in the fog with the other person until you both actually see the same shape.
And underneath all of it sits the least technical fact in the whole stack, the one every empowered-team playbook eventually admits: people want to feel valued, especially by people they respect. Someone will tell you they don’t need recognition, and they’re usually reporting something narrower — that a particular flavor of public praise makes them wince. Almost nobody is telling you the underlying need is absent. It runs the same way explanatory style runs. Feel unseen long enough and you narrate yourself out of the ambition; feel genuinely valued and you’ll pour more of your real self into the pool than any incentive structure could pay for.
Notice what all of these share. They’re not features. You can’t ship them, version them, or put them behind a flag. They’re the interpretive layer — the soft substrate the hard systems run on top of — and it’s precisely the layer our instruments are worst at measuring, which is exactly why it’s the one we keep underinvesting in. We audit the mechanism because the mechanism holds still long enough to be audited. The explanation, the safety, the sense of being seen — those move, so we pretend they’re weather instead of infrastructure.
Which is the whole trap, stated cleanly: the story a team tells about its failure isn’t a report on the failure. It’s the first cause of the next one. Change what tool they use and you’ve changed a variable. Change how they explain what just happened to them, and how safe they feel saying the true thing in the room — you’ve changed the ceiling. The capability was almost never the constraint. The constraint was the sentence people said to themselves on the way out the door, and whether anyone thought to ask them what it was.
Leave a Reply