Senior engineers constantly interrupted? Stop answering the same questions
Why senior engineers become the team's search engine, what each interruption really costs, and a simple system to answer every question once instead of five times.
The KnowWhyy team · · 5 min read
Every team has one: the person who knows why the billing job retries three times, which env var breaks staging, and who decided to split the auth service. They are generous with answers, and that is exactly the problem. A few weeks in, their calendar is full of other people's questions and their own work happens after 6 pm.
This post is about getting that person their mornings back without making anyone afraid to ask.
The cost is bigger than it looks
A single question feels cheap. "Quick one, where do we set the webhook secret?" takes thirty seconds to answer. The cost is everything around those thirty seconds.
The numbers are consistent across studies:
In the Stack Overflow 2022 Developer Survey, 46% of respondents said they spend more than 30 minutes a day answering questions. Among people managers, 32% spend more than an hour a day on it, against 14% of individual contributors.
Microsoft's study of its own developers, Software Development at Microsoft Observed, found that 62% reported switching tasks often because of requests from teammates or managers.
Put those together. Four short questions spread across a morning can easily cost a senior engineer an hour of real focus, even if the answers themselves took two minutes in total.
Ask your first question in minutes.
Create a workspace, connect a tool and choose what gets indexed. The free plan includes GitHub, Slack and Notion.
It is tempting to blame the people asking. That is almost never the right diagnosis. Questions repeat for structural reasons:
The answer was given in a DM. It helped one person and vanished. The next new hire has no way to find it.
The answer exists, but nobody trusts where it lives. If the wiki has been wrong twice, people skip it and go straight to a human. (More on that in keeping internal docs up to date.)
The question is about "why", not "what". Docs usually describe what the system does. The reasoning behind it lives in pull request reviews and Slack threads, which are hard to search. See why was this code written? for that side of the problem.
Asking a person is the fastest path. If finding the answer yourself takes 20 minutes and asking takes 2, people will ask. That is a rational choice, not laziness.
Fixing the problem means changing that last equation: make the self-serve path faster and make asking leave something behind.
Rule 1: answer in public, never in DMs
This is the single highest-leverage habit. When someone DMs you a question, reply with something like:
Good question. Moving this to #eng-help so others can find it later.
Then answer it there. A public answer is searchable, it can be corrected by someone who knows better, and the next person with the same question might find it before they ask.
It also removes the awkwardness for juniors. Asking in a public channel feels exposed at first, so seniors need to model it. Ask your own questions there too.
Rule 2: anything answered twice becomes a doc
Keep a lightweight rule: the second time you answer the same question, the answer goes somewhere permanent. It does not need to be polished. A short page with the question as its title is enough:
# How do I rotate the Stripe webhook secret?
Last verified: 2026-10-12 by @maya
1. Create a new endpoint secret in the Stripe dashboard (Developers > Webhooks).
2. Update STRIPE_WEBHOOK_SECRET in the production environment.
3. Redeploy. Old events signed with the previous secret will fail for ~5 minutes.
Why it works this way: we verify every webhook signature (see PR #482).
Original thread: <link to Slack thread>
Notice the two lines that make this trustworthy: a "last verified" date with a name, and a link back to where the decision came from. Without them, the page becomes one more doc nobody believes.
Rule 3: put a filter in front of people, not a wall
Office hours and support rotations work because they batch interruptions without saying no to anyone. A setup that works for teams of 5 to 50:
#eng-help channel rules (pin this)
1. Search first: Slack, Notion, and the repo. Say what you searched.
2. Post in #eng-help, not in DMs.
3. This week's helper (see channel topic) answers within 2 working hours.
4. Urgent production issue? Use #incidents instead.
Helper rotation: weekly, alphabetical, everyone above 3 months' tenure.
Senior office hours: Tue and Thu, 15:00–16:00, for design questions.
Two details matter here.
"Say what you searched" is not a gate. It teaches people where answers live, and it tells the helper which source is failing. If five people searched Notion and found nothing, that is a documentation gap you can fix once.
The rotation includes mid-level engineers. They often give better answers to onboarding questions than the most senior person, because they remember not knowing. It also spreads knowledge, which helps your bus factor.
Rule 4: track which questions keep coming
You cannot fix what you cannot see. Once a month, skim the help channel and tag recurring themes. A small table is enough:
Question theme
Times asked this month
Where the answer should live
Owner
Local setup fails on M-series Macs
4
README, setup section
@devon
Why are there two user tables?
3
ADR in the repo
@maya
How to get staging access
3
Onboarding page in Notion
@lee
The "why" questions are the most valuable to capture. They are the ones only one or two people can answer, and the ones that get lost when those people leave.
Make it safe to ask
None of this works if people feel judged. A few habits help:
Thank people for asking in public. It keeps the channel alive.
Never answer with just a link. Add one line of context. "It's in the setup doc, step 4 is the one that trips everyone up" lands better than a bare URL.
Fix the doc instead of blaming the reader. If someone could not find it, the doc is in the wrong place or has the wrong title.
Ask new hires to fix one thing. Every new teammate should update at least one page they found wrong. They have the freshest eyes on your gaps. Our guide to speeding up developer onboarding has more on this.
Where KnowWhyy fits
Many repeat questions are really "why" questions whose answers already exist, scattered across a PR review, a Slack thread and a Notion spec. KnowWhyy connects GitHub, Slack (only the channels you choose; DMs are never read) and Notion, so someone can ask in the KnowWhyy web app before tagging a senior engineer. Answers cite the commit, pull request, thread or page they came from, so the asker can check the source, and when the sources don't contain an answer, KnowWhyy says so instead of guessing. It works best as the first stop before the help channel, not a replacement for it. See how it handles onboarding questions, or try it free for teams of up to 2.
The short version
Interruptions cost far more than the answer itself: getting back into code typically takes 10 to 15 minutes.
Answer in public channels, never in DMs, so every answer can be found again.
The second time a question is asked, write the answer down with a "last verified" date and a source link.
Use a weekly helper rotation and office hours to batch questions without saying no.
Track recurring themes monthly, and prioritize capturing the "why" questions only a few people can answer.