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, or 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 do not usually count that as engineering. We should, and that is the whole argument here. Most of what we build, the dashboards and the retros and the incident reviews and the quarterly decks, is machinery for producing explanations. The machinery is optimized for the wrong output. It is 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.
Seligman’s Three Dials
Here is the uncomfortable part. A team that reads a failure as permanent and personal, some version of “we are 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, and not in a meeting where someone could push back on it. It happens through a thousand small hedges: the ambitious refactor that does not get proposed, the deadline padded an extra week because why risk it, the reviewer who stops flagging the thing that would take real work to fix. The story arrives first and the behavior follows it down.
Run the three dials the other direction on the identical event and you get a team that treats the same bad release as a passing, local, situational problem with a fixable cause. That team tries again next sprint with more information and less shame. Nothing about the incident changed. The interpretation of it did, and the interpretation is what compounds.
Which is why you can hand the first team better tools, more headcount, and a faster pipeline, then watch the improvement evaporate over two quarters. You upgraded the mechanism and left the explanation untouched. The mechanism was never what was holding the ceiling in place.
The Shared Pool of Meaning
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 is true, whether that is what they saw, what they suspect, or what they are 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 is not intelligence or seniority. It is safety. People add their piece when it feels safe to add it, and hold it back when it does not. Withhold enough pieces and the smartest room in the building will confidently decide on a fraction of the picture and call it consensus.
Notice how tightly that couples to the explanatory dials. A team that has decided its problems are permanent and personal is a team where naming a problem out loud feels like confirming something shameful about yourself, so people stop naming problems. The withheld pieces then guarantee worse decisions, the worse decisions produce more failures, and the failures confirm the original story. It is a loop that runs entirely on interpretation, and no amount of process documentation interrupts it, because the process was never the part that was broken.
Why Faster Tools Do Not Fix It
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 did not read. Speed is real and it is worth having. Anyone who has watched a decision wait three days for a document to surface knows the cost of slow. But speed does nothing for the piece someone chose not to say. You cannot retrieve what was never put in the pool, and no index covers the unsaid.
The bottleneck was never bandwidth. It was whether the junior engineer felt they could name the thing the senior architect got wrong, in front of the senior architect, with the release date two weeks out. Most of our elegant systems route straight around that question as if it were someone else’s department, and then we are surprised when a team with excellent instrumentation still walks into the same wall twice.
There is a version of this in selling, too, which is really just persuasion with a receipt attached. The old craft is a sequence: understand the situation, define the problem, sit in its implications long enough that the other person actually feels the cost, and only then talk about the payoff. What makes it work is not the sequence itself but what the sequence enforces, which is the discipline of not skipping to the answer. Most bad pitches, most bad products, and most bad strategy decks fail at exactly the same joint. They arrive with the solution before anyone has agreed on the problem. They are answering a question the room has not finished asking, which is a very efficient way to be both fast and wrong. The competence is not in the closing line. It is in the patience to stay in the fog with the other person until you both actually see the same shape, and that patience is the same muscle as leaving enough silence for someone to add their piece to the pool.
The Interpretive Layer Nobody Audits
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 do not need recognition, and they are usually reporting something narrower and entirely believable, 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, quietly and in one direction until something interrupts it. Feel unseen long enough and you narrate yourself out of the ambition, adjusting what you attempt to match what you have concluded about your standing. Feel genuinely valued and you will pour more of your real self into the pool than any incentive structure could pay for.
Notice what all of these share. They are not features. You cannot ship them, version them, or put them behind a flag, and no vendor sells them. They are the interpretive layer, the soft substrate the hard systems run on top of, and it is precisely the layer our instruments are worst at measuring, which is exactly why it is the one we keep underinvesting in. We audit the mechanism because the mechanism holds still long enough to be audited. It has a version number, a dashboard, and an owner. The explanation, the safety, and the sense of being seen all move, so we pretend they are weather instead of infrastructure, and weather is nobody’s fault.
Which is the whole trap, stated cleanly: the story a team tells about its failure is not a report on the failure. It is the first cause of the next one. Change what tool they use and you have changed a variable, which is worth doing and rarely sufficient. Change how they explain what just happened to them, and how safe they feel saying the true thing in the room, and you have 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