Every team has questions where the answer lives in exactly one head. The problem is not that the expert refuses to help. The problem is finding them fast, and reaching them before your whole day is gone.
Here is a practical way to find the one person who knows, usually in under a day, without pinging half the company to get there.
Why the search takes so long
Most people find experts by broadcasting. They post "does anyone know how X works?" in a big channel and wait. Sometimes it works. Often it gets silence, or three half-answers from people who also do not really know. The broadcast is slow because it asks everyone and commits no one. A better search is narrow, quiet, and follows a trail instead of shouting into a room.
Step 1: Write the question before you ask it
Before you look for a person, get the question exact. "How does billing work?" has no single owner. "Why does an annual plan get a prorated charge when a seat is added mid-cycle?" points at one system and, usually, one person. A precise question does two things: it narrows who could possibly know, and it lets that person answer in one reply instead of ten.
Write the question down in one sentence. If you cannot, you are not ready to find the expert. You are still figuring out what you are actually asking.
Step 2: Start with the artifact, not the person
Do not start by asking "who knows this?" Start with the thing itself: the doc, the code, the config, the dashboard, the ticket. Every artifact carries fingerprints.
- Open the document's revision history and see who wrote the part that matters.
- Look at who last changed the relevant code or setting, and who reviewed it.
- Find the ticket or pull request where the decision was made, and read who argued for it.
The person who created or last changed the exact thing you care about is your first real candidate. You found them by following the work, not by interrupting anyone. And you did it quietly, before anyone knew you were looking, which means you have not spent a single ounce of anyone else's attention yet.
Step 3: Follow the paper trail one hop
Sometimes the person who last touched a thing was just cleaning up, not the owner. So take one hop. Read the thread around the change. Who did they ask? Who approved it? Who is tagged when it breaks? Names that show up more than once, across more than one artifact, are your real experts. A name that appears once might be a passer-by. A name that appears three times owns the thing.
Step 4: Ask a connector, not the crowd
If the trail runs cold, do not go back to the big channel. Find one well-connected person, often a manager, a long-tenured engineer, or someone on a support rotation, and ask them one specific thing: "Who owns prorated billing?" Connectors are valuable because they hold the map. They will not know the answer, but they know the name, and that is what you need. One direct question to one person beats a broadcast to a hundred.
Step 5: Confirm before you interrupt
Before you take an expert's time, make sure it is them. A quick, low-cost check: "I am trying to understand why annual plans prorate mid-cycle seat adds. It looks like you set that up last spring. Are you the right person, or should I ask someone else?" This gives them an easy out if they are not, and it shows you did your homework. Experts answer faster when they can see you are not going to make them explain the basics.
Step 6: Ask well, so they can answer once
When you reach the right person, make the answer cheap for them to give.
- Lead with your one-sentence question.
- Say what you already checked, so they do not repeat it.
- Say why you need it, so they can catch a wrong assumption.
- Make it answerable async, so they can reply when they surface, not on your schedule.
A well-formed question turns a back-and-forth into a single reply. That respects the one person whose time you finally found, and it makes them far more likely to help you fast the next time you come knocking.
Step 7: Capture the answer so the next search is shorter
You just spent effort finding this. The next person will need the same answer. Write it down where the artifact lives: a note on the doc, a comment in the code, a pinned reply in the channel. Include the answer, the source, and the date. This is the step almost everyone skips, and skipping it is why the same expert gets the same question next month.
A quick recap
- Write the exact question in one sentence.
- Follow the artifact to whoever created or last changed it.
- Take one hop through the surrounding trail to confirm ownership.
- If cold, ask one connector for the name, not the crowd for the answer.
- Confirm you have the right person before spending their time.
- Ask in a way they can answer once, async.
- Write the answer down so the search is shorter next time.
The version that removes the search
Notice that most of this work is detective work: reconstructing who knew what, from trails they left behind. It would be faster if the people who know simply wrote down what they own and what they decided, in their own words.
That is what StandIn does. Someone writes one short brief at the end of their day about their own work, and while they are away, it answers teammates' questions from what they actually wrote, with a source under each answer. When the answer is not in the record, it says so instead of guessing. It does not replace the expert. It just means finding the answer no longer depends on finding the one person free at the exact moment you are stuck.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.