How do you stop being the person who knows?
Being the one everybody asks felt like the most valuable thing about me, and it was quietly the reason my team never had to learn.
For a long stretch of my career the most satisfying part of the week was being asked.
Can you take a quick look at this. Does this pass. What is the rule about focus. Ten designers and researchers on my team at UKG, a product suite in front of five thousand organizations, and a steady traffic of questions coming to one desk. It felt like being useful. It was also the reason nothing changed.
What does a bottleneck feel like from the inside?
Like seniority.
Nobody experiences themselves as an obstruction. You experience a full calendar, a reputation, and the pleasant weight of being necessary. The questions arriving are evidence that the work matters and that you are the person trusted with it.
What is actually happening is that you have become the cheapest available substitute for the team learning something. Asking you takes four minutes. Learning it takes an afternoon. People are rational, they are busy, and they will take the four minutes every single time, for years.
The trap is that the arrangement rewards you for maintaining it. Every answer you give is a small confirmation of your standing and a small deferral of the moment anyone else has to hold the knowledge.
Who pays for that?
Not the people who ask. The ones who do not.
For every question that reached my desk there were a great many decisions made in rooms I was not in, on days I was booked, by people who did not know there was a question to ask. Those decisions did not pause. They resolved, sensibly, using whatever was available, and what was available did not include the thing that only existed in my head.
So the exclusions did not come from the reviewed work. They came from everything adjacent to it. A control named in a hurry. A color chosen in a file at five o'clock. A flow that was obviously fine and had never been keyboard-tested, because the person who always asks that question was in another meeting.
Knowledge held in one person is unavailable at exactly the rate the organization is busy, which is most of the time, and busiest when it matters.
And the part I find hardest to sit with: if I had left, it would have left. Two years of accumulated judgment, gone in a notice period, and the team would have gone back to first principles without knowing which principles had already been settled.
What actually moved it out of my head?
Writing it down somewhere with consequences.
At ClearCo the design rules, the accessibility standard and the writing guidelines live as plain markdown in the repository the work happens in. Not a wiki, not a deck, not a channel. The place people already are when the question occurs to them.
Then the part that makes it real: some of it fails the build. A rule with a gate behind it gets followed. A rule in a document gets weighed against the deadline, and the deadline wins on a long enough timeline.
The sentence I am proudest of from that period is unglamorous. The platform conformance target is now answerable from the repository rather than from me. It is a small sentence and it took a year.
Why was writing it down harder than doing it?
Because most of what I knew was not knowledge. It was taste, and taste resists being written.
Sitting down to state a rule exposes how much of it was "I would know it when I saw it." Some of that turned out to be real judgment that genuinely needs a person. A great deal of it turned out to be a decision I had made once, years ago, for a reason I could no longer reconstruct, and had been re-applying ever since with the confidence of a principle.
There is also a quieter difficulty, and I think it goes unspoken in our field more than it should. If your standing comes from being the person who knows, then writing down what you know feels like handing away the thing that makes you valuable. I felt that. I do not think it is shameful to have felt it.
It is also wrong, and the correction is worth stating plainly: what made me valuable was never the answers. It was being the person who noticed the question existed. Nobody has ever automated that, and writing down the answers is what frees you to go and do it somewhere new.
What I would tell someone who is the person who knows
- Notice the four-minute question. The ones you answer without thinking are the ones that should not be reaching you. Those are your first entries.
- Write the rule where the work is. Not where documentation goes to be ignored. In the repository, in the file, in the template.
- Give rules consequences, not just homes. The ones that matter most should fail something. The rest should at least be findable by someone who does not know your vocabulary.
- Write down the taste, not only the rule. "The accent marks selection and nothing else" is worth more than a hex code, because it is the sentence that answers the next twelve questions.
- Let someone else answer badly. The first few times a colleague fields a question you would have answered better, say nothing. Correcting it once restores the old arrangement completely.
- Measure whether the queue shrank. If you are still being asked the same things after two quarters, the writing was not reachable and you should treat that as a design failure rather than a discipline problem.
What I actually think this is about
Accessibility knowledge concentrated in one person is a design decision about when it will be available, and the answer is: sometimes, on request, to people who already know to ask.
That is not a training problem or a headcount problem. It is a distribution problem, and it is ours to fix, and it is much cheaper to fix while you are still there.
Think back to the last question someone brought to your desk and how quickly you answered it. The speed is the signal. Put that answer somewhere that does not require you to be available.