Every small business owner knows the moment. You're halfway through something important when a team member appears at your shoulder with a question you've answered before. Not once. Several times. You answer it again, they thank you, and you both carry on. A week later, it happens again.
It's not that the person asking is incompetent. It's that nobody has ever sat down and dealt with the underlying problem.
A thread started in January by @Frans VH in the General Business Forum asked exactly this question: how do small teams actually handle repeat "how do I do X?" questions, and is there anything that genuinely works beyond shadowing and asking colleagues? The thread ran for 42 replies across five months and revealed something more interesting than a simple answer: the right solution depends entirely on who is asking the questions, and most standard advice assumes a version of your team that may not reflect reality.
@StrategyDoctor built on this with the SOP approach: standard operating procedures for regular tasks, developed into a starter manual that new team members inherit and are expected to improve over time. The detail that caught my attention was the suggestion that new starters update the SOPs as they learn, adding clarity and catching gaps that existing staff have long since stopped noticing. It turns onboarding from a passive process into an active one.
@Stuart_Walker made the case for a company wiki with a framing I think is genuinely useful: the "number 9 bus" test. What would happen to the business if you stepped in front of a bus tomorrow? Working through that question as a team, with the explicit aim of making sure no single person holds critical knowledge in their head alone, gives documentation a purpose that people can actually connect with rather than treating it as admin.
@alamest offered what I thought was the most practical heuristic in the thread: don't try to document everything up front. Only write something down once the same question has been asked twice. That keeps your documentation useful rather than turning it into shelf-ware that nobody reads because it covers everything and therefore helps with nothing.
For teams who find dense written SOPs off-putting, @Jordan Lopez suggested lighter alternatives: swimlane diagrams and short screen recordings using tools like Loom or Scribe. The point he made about behavioural compliance is worth paying attention to. A beautifully written SOP that nobody reads has the same value as no SOP at all. Format matters.
@zenithpa summed up what works in practice as simply as anyone in the thread: clear step-by-step guidance people can quickly refer back to, not corporate manuals. The side benefit, stopping knowledge sitting with just one person, is one of the most overlooked risks in small businesses and one that tends to only become visible when that person leaves.
This is where the thread got more interesting. @fisicx was direct about it: the issue here is training, not documentation, and the root cause is a management failure rather than a process gap. @Newchodge, who advises on employment law, made the point that proper training for all staff, including temps, is a management responsibility, not optional.
@UKSBD reframed the problem in a way that I think cuts to the heart of it: if you're expecting seasonal workers to have deep product knowledge across 30,000 SKUs without adequate senior cover, the problem isn't the temps. It's not having enough experienced colleagues and team leaders in place to support them. And the alternative, as UKSBD noted, is to simplify the categories so that the knowledge gap becomes manageable in the first place.
@Paul FilmMaker described what serious structured onboarding actually looks like in his video production business: an hour of training every morning for the first six weeks, on days without shoots, covering both research-led learning and hands-on practice. It's a significant investment of time, but it's the kind of investment that separates a team that can operate independently from one that keeps coming back with the same questions.
That's a goal that sounds counterintuitive to many small business owners, particularly those who built something from nothing and whose instinct is to stay across everything. But a business where critical knowledge lives only in the founder's head isn't really a business. It's a job with extra paperwork.
The "number 9 bus" framing Stuart_Walker used in the thread is one version of this question. Another is: if you wanted to take a month off next year, could the business run without you answering questions every day? If the answer is no, the training and documentation conversation is the place to start.
For seasonal or casual teams: documentation is a secondary concern. The primary questions are whether you have enough experienced people in the ratio, whether your product or service complexity is realistic for the level of hire, and whether your onboarding gives people enough structured time before they're expected to operate independently. If the answer to any of those is no, more documentation won't fix it.
For any team: @lattod made a point that applies regardless of context. When someone asks a question, try responding with "if I wasn't here and you had to make a decision, what would it be?" then let them make it. You have to be prepared for some mistakes, but empowerment and learning go hand in hand. A team that's only ever told the answer never develops the judgment to work things out for themselves.
Ultimately, the repeat question problem is usually a symptom rather than the disease itself. The disease is either a process that hasn't been captured, a team that hasn't been properly resourced, or a business that hasn't yet worked out how to operate without the founder in the room. All three are solvable. But they need different solutions, and reaching for an SOP template when the real issue is something else is how a lot of small businesses stay stuck.
The thread is still live if you want to add your own experience: How do you handle repeat "how do I do X?" questions from your team?
It's not that the person asking is incompetent. It's that nobody has ever sat down and dealt with the underlying problem.
A thread started in January by @Frans VH in the General Business Forum asked exactly this question: how do small teams actually handle repeat "how do I do X?" questions, and is there anything that genuinely works beyond shadowing and asking colleagues? The thread ran for 42 replies across five months and revealed something more interesting than a simple answer: the right solution depends entirely on who is asking the questions, and most standard advice assumes a version of your team that may not reflect reality.
The standard advice, and why it works
For permanent, invested staff, the consensus in the thread was clear and consistent. @fisicx put the most direct version of it first: get the person asking the question to write down the process themselves. They will rarely ask again, and if they do, you point them at what they wrote. It's simple, it transfers ownership, and it works.@StrategyDoctor built on this with the SOP approach: standard operating procedures for regular tasks, developed into a starter manual that new team members inherit and are expected to improve over time. The detail that caught my attention was the suggestion that new starters update the SOPs as they learn, adding clarity and catching gaps that existing staff have long since stopped noticing. It turns onboarding from a passive process into an active one.
@Stuart_Walker made the case for a company wiki with a framing I think is genuinely useful: the "number 9 bus" test. What would happen to the business if you stepped in front of a bus tomorrow? Working through that question as a team, with the explicit aim of making sure no single person holds critical knowledge in their head alone, gives documentation a purpose that people can actually connect with rather than treating it as admin.
@alamest offered what I thought was the most practical heuristic in the thread: don't try to document everything up front. Only write something down once the same question has been asked twice. That keeps your documentation useful rather than turning it into shelf-ware that nobody reads because it covers everything and therefore helps with nothing.
For teams who find dense written SOPs off-putting, @Jordan Lopez suggested lighter alternatives: swimlane diagrams and short screen recordings using tools like Loom or Scribe. The point he made about behavioural compliance is worth paying attention to. A beautifully written SOP that nobody reads has the same value as no SOP at all. Format matters.
@zenithpa summed up what works in practice as simply as anyone in the thread: clear step-by-step guidance people can quickly refer back to, not corporate manuals. The side benefit, stopping knowledge sitting with just one person, is one of the most overlooked risks in small businesses and one that tends to only become visible when that person leaves.
Where the standard advice runs out
About halfway through the thread, the conversation shifted. Frans VH revealed that the context behind his question was a chain of 12 seasonal stores with a product list of around 30,000 items, half of them in dropshipping. The team were largely temporary summer workers and students. The problem wasn't that they lacked SOPs. It was that no SOP in the world was going to help a new hire navigate 30,000 products well enough to serve customers competently after a few days on the job.This is where the thread got more interesting. @fisicx was direct about it: the issue here is training, not documentation, and the root cause is a management failure rather than a process gap. @Newchodge, who advises on employment law, made the point that proper training for all staff, including temps, is a management responsibility, not optional.
@UKSBD reframed the problem in a way that I think cuts to the heart of it: if you're expecting seasonal workers to have deep product knowledge across 30,000 SKUs without adequate senior cover, the problem isn't the temps. It's not having enough experienced colleagues and team leaders in place to support them. And the alternative, as UKSBD noted, is to simplify the categories so that the knowledge gap becomes manageable in the first place.
@Paul FilmMaker described what serious structured onboarding actually looks like in his video production business: an hour of training every morning for the first six weeks, on days without shoots, covering both research-led learning and hands-on practice. It's a significant investment of time, but it's the kind of investment that separates a team that can operate independently from one that keeps coming back with the same questions.
The question behind the question
I added a reply to this thread myself back in January. At my own businesses, we've done a mixture of the fisicx approach and having experienced team members document their own areas of responsibility. Some of that was driven by our ISO certification process. But the underlying motivation was more personal than that: I wanted to make myself genuinely redundant in the day-to-day operation of the business.That's a goal that sounds counterintuitive to many small business owners, particularly those who built something from nothing and whose instinct is to stay across everything. But a business where critical knowledge lives only in the founder's head isn't really a business. It's a job with extra paperwork.
The "number 9 bus" framing Stuart_Walker used in the thread is one version of this question. Another is: if you wanted to take a month off next year, could the business run without you answering questions every day? If the answer is no, the training and documentation conversation is the place to start.
What actually works, depending on your situation
For permanent small teams: SOPs, wikis, short screen recordings for anything visual, and one central place where everything lives. Have the team write the documentation themselves. Only document once a question has been asked twice. Treat the wiki as a living document, not a one-time project.For seasonal or casual teams: documentation is a secondary concern. The primary questions are whether you have enough experienced people in the ratio, whether your product or service complexity is realistic for the level of hire, and whether your onboarding gives people enough structured time before they're expected to operate independently. If the answer to any of those is no, more documentation won't fix it.
For any team: @lattod made a point that applies regardless of context. When someone asks a question, try responding with "if I wasn't here and you had to make a decision, what would it be?" then let them make it. You have to be prepared for some mistakes, but empowerment and learning go hand in hand. A team that's only ever told the answer never develops the judgment to work things out for themselves.
Ultimately, the repeat question problem is usually a symptom rather than the disease itself. The disease is either a process that hasn't been captured, a team that hasn't been properly resourced, or a business that hasn't yet worked out how to operate without the founder in the room. All three are solvable. But they need different solutions, and reaching for an SOP template when the real issue is something else is how a lot of small businesses stay stuck.
The thread is still live if you want to add your own experience: How do you handle repeat "how do I do X?" questions from your team?
