Part II — Seeing Organizational Flow · Chapter 30 · 5 min read · First Public Draft
Interfaces
You Have to Know a Guy
A capability you can only reach if you happen to know the right person.
Jump to a chapter
Narrated with Microsoft's neural voice, not me — a recording.
A new starter, second week, needs something from another part of the organization. They do the sensible thing and look for how to ask.
There is a page on the intranet, last updated three years ago, linking to a form that submits to a queue nobody monitors any more. There is a shared mailbox. There is a channel with eleven members and no messages since March.
So they ask their own team, and their own team says: oh, just message Maja.
Maja is excellent. Maja knows how everything works, answers quickly, and has done for years. Nobody in this story has done anything wrong, and the newcomer has just learned the actual interface, which is not the form and not the mailbox but a person’s name, passed along by word of mouth like a good restaurant.
This is the most cheerful of the patterns in this part, because it looks so much like things working. Somebody helpful, helping. It only shows its price later — when Maja is on holiday, or in a workshop, or has moved to another company and taken the routing table in her head with her. Then a capability that seemed perfectly available turns out to have been available through one person the whole time.
The part I overlooked for years is what it costs Maja.
She is interrupted perhaps fifteen times a day by questions only she can answer quickly. Each one takes four minutes and costs her twenty, because the work she was doing before the interruption has to be picked up again from wherever she dropped it. Her own deliverables slip, and she makes up the time in the evening. Meanwhile the thing she is actually paid to be good at gets whatever attention is left over, which by Thursday is not much.
And she will not complain, because being the person everyone comes to is genuinely lovely. It is a form of standing you cannot get any other way. She is visibly useful, obviously indispensable, thanked constantly — and at the next review somebody will say we can’t afford to lose Maja, and mean it as praise. Which it is. It is also an accurate description of a risk the organization has decided to admire rather than address.
That is what makes this pattern so durable. Everyone involved is being rewarded: the newcomer gets a fast answer, the organization gets a working shortcut, and Maja gets to be the one who knows. Nobody has any incentive to notice that none of it scales, that all of it lives in one person’s head, and that the day she moves on, the organization will discover which of its capabilities were real and which were her.
What happens when nobody finds Maja
The newcomer above got lucky. Somebody told them a name. The more expensive version is when nobody does.
A team needs something, looks for it, cannot find it, and reasonably concludes it does not exist. So they build it. They are competent, they are under time pressure, and they bend a rule or two on the way because the rule was written for a route they never found. It works.
Now there are two endpoints doing more or less the same job. Not identically — one rounds differently, one treats a cancelled order as still open for a day, one was built before a rule changed and nobody told its author because nobody knew it existed. Both are correct, in the sense that each does exactly what its team intended. The organization now has two answers to the same question, and no way of knowing which one anybody is looking at.
The subtler version needs no new system at all. A team is given credentials to something that already exists, reads the data, and works out for themselves what the fields mean — because there was nothing to read and nobody obvious to ask. Their reading is sensible and slightly wrong, in the way any honest reading of an undocumented thing is slightly wrong. They build reporting on it. Six months later there is a third version of the truth, in a deck, in front of people making decisions with it, and it disagrees with the other two by a margin nobody can explain.
What is worth noticing is that no rule was broken in the second case at all. Access was granted properly. The team did what access implies they should do. What was missing was not permission or competence — it was anything that said here is what this means, and in its absence people supply their own meaning, which is what people do.
Both of these usually surface years later, as a data quality problem, and get handed to someone to reconcile. It rarely gets recorded as an interface problem, which is what it is: the first thing anybody could not find was the front door.
What Maja actually is, in the vocabulary An Interface Nobody Can Find sets out, is the bottom rung: not automated, not self-service, not even a queue with a name on it — a person you have to know. And the reason it persists is that from the inside it feels like the top rung, because for anyone who knows her the answer arrives immediately.
Both versions are the same mechanism. Once with a helpful person standing in the gap, once without. The only difference is whether the cost lands on Maja or on the second system nobody knew they were building.
What moves this is making the capability reachable by somebody who knows nobody — which sounds like documentation and is really about deciding that how to use this is part of the thing rather than a description of it. Maja stops being load-bearing at the point where a stranger can get what she gives them without her, and not one moment before.
Cultivating this: Opening the Front Door, in Part III.