I was in a design meeting once, mid-argument, when I said something like: “The data model is right in Postgres, but you can’t enforce that invariant in plain SQL — it really wants to be an event the other services subscribe to.” The engineer across the table nodded; we were locked in. Someone else in the room — sharp, senior, just not a backend person — laughed and said, “It’s like you’re speaking another language.”
She was righter than she knew.
A close friend of mine was a therapist before he ever came into tech, and years ago he taught me about an approach called collaborative language systems — Harlene Anderson and Harold Goolishian’s name for it. (We always lazily called it a “theory,” and that’s the version that stuck in my head.) The way he explained it, each person’s mind is its own web of symbols — words, phrases, images — wired over a lifetime onto particular meanings. That private web is your language, and mine is not yours. Even when we’re both speaking English, the symbols don’t always land on the same meaning.
In that frame, talk therapy isn’t about saying the true thing. It’s about bridging the gap between the therapist’s language and the patient’s — because the real failure mode is talking past each other, where two people trade sentences that sound like agreement while the symbols quietly fail to connect. Learn the other person’s language, though, and the channel gets wider. You can hand them something real — something that helps them heal and grow.
I do a small version of this every week. Back in that meeting, saying it again more slowly would have done nothing; the move that works is to drop “Postgres” for “the database,” and to trade “enforce the invariant” for an example of the bug we’d ship without it. It’s slower, and it costs me the comfort of shorthand. It also asks the other person to trust that I’m reaching for their language on purpose — not talking down to them.
A whole web of gaps
For a long time I thought of this as a one-on-one skill: me and one other person, closing one gap. But the more senior I got, the less my job was any single conversation. It became holding the whole web at once — who on the team speaks what, where two people are sure they agree but don’t, which quiet gap is about to become a month of rework. That running map, everyone’s languages and the spaces between them, is the thing I actually tend. I’ve come to call it a cognitive inventory: collaborative language systems scaled up from two people to a whole team.
And here’s what took me longest to believe: a conversation isn’t finished when I’ve said the true thing. It’s finished when the meaning has actually crossed — when there’s a shared understanding solid enough for the team to execute on. Those are very different stopping points, and most of the friction I’ve ever seen on a team lives in the gap between them.
Which is the real reason I say our job is not to build software. The software is the deliverable — the thing we ship, the thing with our names in the commit history. But it isn’t the job. The job is figuring out what should exist, and why, and then getting that understanding to land with the right people in a form they can act on. The code is what falls out the end of that process.
A salesperson barged into my office
A salesperson barged into my office one afternoon and asked, “Does our IoT platform have time?”
I laughed and said, “You did it!” We threw a fist in the air, victorious, and then both burst out laughing. Partly at how vague and out-of-context the question was. Partly at the sheer silliness of it. But mostly because, just days earlier, we’d been talking about how to hand off the things he was learning in the field to me. Like a lot of people in his seat, he’d told me he doesn’t really understand “the technical stuff” — but he knows how to sell it. I told him that was perfect. And I told him not to be afraid to ask the stupid questions. In fact, I said, there should be a reward for asking the stupidest question in the room.
And here he was, collecting his reward.
It turned into one of the more important conversations I had that quarter. He’d just come off a call with a customer who was unhappy with their current IoT setup — the kind of system that shows you a temperature reading but gives you no way to tell whether it’s from five seconds ago or five hours ago. So when he barged in asking whether ours “had time,” the literal question was about timestamps. The real question, the one underneath, was: is this a story I can sell? Can I look that customer in the eye and promise ours is better here?
I pulled up a couple of data diagrams showing that every reading was stamped with its time, and some screen designs showing exactly where that time would appear. That was the proof he needed — and with it he could move past the plumbing to the thing he actually cared about: the pitch.
From there it traveled. We worked out how to message the value of that gap, and it went into marketing, into product. It changed what I understood about which customers we were trying to win and what they actually worried about. It got me sitting in on more customer calls, with tighter feedback loops on what we were building. And it gave the sales team a worn path to the developers: demos sooner, more water-cooler arguments, fewer translation layers.
None of that happens if I answer the literal question. It happens because the goal was never to transfer facts — it was to find his language and meet him in it.
This is what a cognitive inventory looks like in motion. If I’m talking backend with a salesperson, I’m not walking them through our CI pipeline — but I’m also not handing them a cartoon. I’m finding the part of the system that matters to them. If a manager had asked me the same opening question, we’d probably have spent the whole time on the threat model — something the salesperson and I will likely never touch. Same system, same facts, two completely different conversations, because two different languages. The skill was never in knowing the facts. It was in knowing which ones to reach for.
The reward for the stupidest question
So why on earth reward the stupid question? Because, read correctly, it’s the most useful signal in the room. It tells you exactly how far the conversation has drifted from the other person’s language — where your symbols stopped landing on their meaning. A stupid question is someone crying out, the words you’re saying don’t mean anything to me anymore. Hear that cry and don’t punish it, and you get the one thing you actually need: a chance to stop and learn their language.
Here’s what stuck with me about that salesperson: he was completely unafraid to not know things. “I don’t understand the technical stuff” came out of him with zero shame, and that fearlessness is precisely what made him valuable. He could walk into a room, admit the gap, and start closing it immediately.
Most developers cannot do this. And it’s the single most expensive habit I work to break.
Somewhere early, a lot of us absorb the idea that our value comes from knowing things. So when an issue surfaces in a meeting and we have to say “I don’t know how to do that,” it doesn’t land as a neutral fact — it lands as failing at the fundamental thing we believe we’re paid for. So people hedge. They nod. They go quiet and burn two days privately rather than spend two minutes admitting a gap in front of peers.
My therapist friend’s field has a name for the posture I’m after: the not-knowing stance. The therapist deliberately stays in “I don’t know,” lets the other person’s meaning reshape their own, and never assumes they already understand. That posture is just as much a senior-engineer move as a therapeutic one. The most senior people I’ve worked with say “I don’t know” constantly, and they say it with total confidence, because the sentence never ends there. It ends with a move:
- “I don’t know, but let’s figure out who to ask.”
- “I don’t know if that will work, but we can run a quick experiment.”
- “I don’t know what to decide, so let’s figure out what the decision-tree looks like.”
That’s the reward for the stupidest question, made real. “I don’t know” stops being an admission of weakness and becomes the opening move of someone who knows what to do next. My job is to make the room safe enough that people will actually surface these gaps — because I can’t bridge a gap nobody will admit is there.
Cognitive inventory includes me, too. Once I started keeping it honestly, the thing I thought of as my job quietly changed shape — less being the person with the answers, more keeping everyone’s languages lined up so the answers could come from anywhere. That turned out to be most of what being an architect is.
Where this goes next
A conversation is only done when there’s a shared understanding the team can actually execute on. That’s the whole philosophy, and it scales down to a single confused salesperson and up to an entire org.
Lately, though, I’ve started asking the same three questions — what do they know, what do they think in, what context do they need to succeed — about a new kind of teammate. The agents I build alongside have a cognitive frame too. They need guardrails, organized context, and an environment engineered for them to do good work.
But that’s another post.