The gap between a system and the people it forgot — and where I first met it.
“Blind” is a word most people are sure they understand. It means an absence of sight — darkness, a white cane, a life organised around not seeing.
I am registered blind, and almost none of that picture fits me. I read. I write software. I walk into town and watch the weather come in over the fells. For the purposes of registration I’m categorised as severely sight impaired — the category still commonly called blind — but I have usable vision and lead an unremarkable life.
So the word arrives carrying a model of me, and the model doesn’t match the person. That mismatch — the moment the label and the reality are found not to agree — is the most familiar experience of my life. It’s also, as it turns out, the exact shape of the most expensive problems I’m paid to find inside other people’s companies. I just met it first in a word about myself.
The gap is rarely dramatic. Mostly it’s mundane to the point of invisibility.
The clearest example I have is a train station. The departures screen is often mounted high on the wall, well above eye level, where this kind of information has always gone — because for the person who decided where it went, height was free. From across a concourse, at that distance and that angle, I can’t read it. Nor can a fair number of people who’d never describe themselves as visually impaired.
The information exists. It’s published, accurate, refreshed every few seconds. It’s simply placed where it assumes a kind of vision I don’t bring to it. The same goes for most signage built to be caught at a glance from across a room: the assumption is always the same, and it’s always somewhere above eye level.
I’ve adapted, the way people in the gap always do. I photograph it and zoom in. I check the app before I check the wall. The workaround is so habitual now that I barely notice I’m doing it — which is the tell.
The system didn’t change to meet me. I built a small private process and wrapped it around the system, and the screen carries on believing it informs everyone equally. What I actually need is simpler than any of it: the same information, up close, at eye level. That’s the one thing still often out of reach.
That station taught me something the person who placed the screen never had to learn. Every system is built around a model of the person who’ll use it and the conditions it will meet — and that model is always narrower than reality.
The designer rarely sees the gap, because they built the system around themselves, or someone close enough to themselves that the assumptions never had to be said out loud. The designer isn’t on the far side of anything. The person who falls into the gap, by contrast, sees nothing else. To that person the assumption isn’t invisible at all; it’s the most visible feature of the whole arrangement, because they meet its edge every time.
This is why the gap is so reliably missed by the people best placed to close it. Not through carelessness — through position. You can’t see the assumption you’re standing inside. The people who decide where that screen goes are exactly the ones who can read it from across the concourse.
The first time I understood this, I thought it was a fact about screens. It’s really a fact about systems — all of them, including the organisations that build the screens, which hold assumptions about themselves that the people inside them are the least equipped to see. I came to that part slowly. But the shape was already familiar, because I’d been living inside its smaller version all my life.
And there’s a second thing happening, quieter than the first. The better I get at the workaround, the less anyone would ever know there was a gap to work around. My adaptation doesn’t only route around the problem; it conceals it. From the outside the system still looks like it’s working — the information is reaching me, after all — and the fact that it reaches me by a private route I had to build for myself shows up nowhere. A gap that someone has quietly learned to accommodate stops looking like a gap. It starts to look like normal.
I’ve spent a long time being the edge case. Long enough to stop hearing it as an unkind word.
In a specification an edge case is a condition rare enough to handle later, or never — the input outside the expected range, the user who doesn’t behave like the others. But edge cases are people. The phrase is a small monument to its own assumption: someone decided where the centre was, drew a boundary around the conditions they expected, and the people outside it became edges.
I happen to know what it is to be filed under later. This isn’t a grievance. It’s information — about where a system’s real model stops and its imagined one begins.
For a long time I filed all of this under my own eyes — a fact about how I move through the physical world. It took me longer to see it was the same structure I kept meeting at work, only larger, and that the station had been teaching me to read it.
Organisations run on models too. Not of their users — of themselves. Every company carries an account of how its software behaves, how work moves from idea to release, what depends on what, what’s automated, what’s safe to change, and who could leave without the place noticing. That account lives in a founder’s head, in an architecture diagram, in a runbook, in the confident sentence someone says in a meeting.
And like any model, it’s narrower than the reality it describes. Most of it was true once — which is exactly what makes it dangerous. The account isn’t fiction; it’s history, an accurate snapshot of a system that has since moved on without filing the change. The systems keep going and the account stays where it was last updated. The gap between how those systems actually behave and how the organisation believes they behave is the same gap I’d been falling into all my life — relocated to a place where the stakes are measured in roadmaps and revenue rather than missed trains.
It has the same property, too: invisible from the inside, obvious from the edge. That’s sharpest in a founder-led company, where so much of the model lived in one person’s head that nobody else ever had cause to write it down. The founder is the last person able to see where their own understanding has drifted, for the same reason the person who placed the departures screen can’t feel the height — the thing was built around them.
The people who can see it are the ones meeting its edge. The engineer who checks the overnight job by hand every morning, because a silent failure six months ago taught them not to trust it. The support lead fielding a question that used to be rare. The contractor quietly keeping a server alive that the architecture diagram no longer shows. The new hire treating a working system as unexploded ordnance, because nobody can tell them which parts are safe to touch. Each of them is standing in the gap. None of them, usually, is in the room where the model gets described.
I think this is why I work the way I do. Faced with any system — a piece of software, a delivery process, a company’s account of itself — my first instinct isn’t to ask whether it works. It’s to ask where it assumes ideal conditions, and who’s standing on the far side of that assumption.
I read systems from the position of the detail they forgot, because I’ve spent a life as the detail a great many systems forgot. That isn’t a method I adopted; it’s closer to a reflex I couldn’t switch off if I wanted to.
When the official account of a thing has repeatedly failed to match your experience of it, you stop trusting accounts. You go looking for what’s actually true underneath, and you get into the habit of arriving there sideways — not through the front door the system offers, but from whichever edge it wasn’t expecting anyone to come in by.
Lateral by necessity, first-principles by temperament — what being on the far side of an assumption makes of a person.
Inside a company, that instinct has a job. The gap doesn’t announce itself there either. It accumulates one workaround at a time, exactly as mine did at the station — a shortcut becomes a dependency, a workaround becomes the process, a senior person becomes the documentation.
For a long while none of it costs anything you’d put in front of a board. The workarounds hold. The people carrying them don’t complain, because to them it’s simply how the place works. The model and the reality drift apart quietly, and the quiet is the dangerous part.
Then it gets priced in, usually all at once: a release nobody trusts, a roadmap that slips for reasons no one can quite name, a piece of knowledge that turns out to live in one person’s morning routine and nowhere else. By the time it surfaces as a problem, the model and the reality have been apart for months, and the distance between them is already being paid for.
I go looking for that distance while it’s still a correction and not yet a crisis — setting a company’s account of itself beside the evidence of what its systems are really doing, and reading the difference. Most of the time the difference isn’t a failure of engineering. It’s the ordinary lag of a model that stopped being updated while the thing it described kept moving.
So I’m the wrong person to take a system’s own account of itself at face value, and I’ve come to think that’s the most useful thing about me.
I met the gap first in a single word. I learned its shape on a thousand small occasions of being the person the design didn’t picture. And I recognised it at once when it turned up at work.
What I needed at the station was never complicated: the same information, closer, at eye level. It turns out that’s what most companies need as well — not more dashboards or more process, but the truth about their own systems brought near enough to see plainly.
That’s the thing I try to put back within reach.
If the gap between a working system and an understood one is something your company is quietly paying for — I'd like to compare notes.
And if this is worth a colleague's time, send it along.