When a new starter keeps asking the same questions, it does not always mean they were trained badly.
Sometimes the clearer explanation is that the process itself is not yet clear enough to follow without help.
This is easy to miss in a small team. The work still gets done. An experienced colleague fills in a missing step, explains which spreadsheet to use, or says, “Ask Sarah if that comes up.” From the outside, it can look like the process works.
But if the work only moves because long-serving staff keep adding context from memory, side messages, and informal conversations, that is worth noticing. What looks like a people issue is often a process issue.
For an Operations Lead, this is useful evidence. A capable new person getting stuck can tell you a lot about whether a process is really shared, clear, and complete.
When a capable new starter keeps getting stuck
Most small organisations have seen some version of this.
A new staff member seems sensible and capable. They follow the instructions they have been given. They are paying attention. But they still keep getting stuck.
They ask the same clarifying questions more than once. They miss steps that “everyone knows.” They complete the main task, but not the follow-up that happens afterwards. Or they pause because they cannot tell what applies in this case, who decides the next step, or what to do when something is missing.
The work still gets done, but only because someone experienced steps in.
That person explains the unwritten rule. They point out the exception. They say which figures can be trusted. They remind the new starter who needs to be copied. They translate a process that is only partly written down.
If that sounds familiar, it is worth pausing before deciding the new person just needs more training.
Sometimes they do. But often, a capable new starter getting stuck is a sign that the process cannot yet be followed reliably without live interpretation.
That is not a criticism of the team. It is a practical diagnosis, and a common one in organisations where work has evolved gradually over time.
What this looks like day to day
Usually, there is some form of documentation.
There may be a how-to note, a checklist, an old handover document, a template, or a spreadsheet with instructions on the first tab. On paper, that can make the process feel documented.
But often the document covers only the main route.
The real work depends on things that are not written down clearly: common exceptions, judgement calls, missing information and hidden handoffs, or knowing who to ask when the standard steps stop being enough.
A new staff member logging service activity might follow the written steps and still need to ask:
- Which spreadsheet version are we using now?
- Do I copy the programme lead on this one or only some cases?
- What do I do if a date is missing?
- Has this already been entered somewhere else?
A new fundraiser might complete the basic donor admin only once someone explains the unwritten naming rules, where the right folder actually lives, and what to do with repeat donations that do not fit the standard pattern.
A programme coordinator might be shown how to prepare the monthly report, but the process only really works when somebody explains which figures are trusted, where to cross-check them, and which anomalies can be ignored.
Another clue is when experienced colleagues explain the same process differently.
That usually means people are not following one clear process. They are each interpreting it using their own memory and judgement. The differences may seem small, but they matter for someone new. One person says to update the tracker first. Another says to wait until the confirmation email arrives. A third says it depends on the type of case.
From a distance, this can look like minor variation. For a new starter, it feels like the map changes depending on who they ask.
This is also why onboarding can take longer than expected. The new person is not only learning the task itself. They are also uncovering hidden logic, workarounds, and handoffs that the team has stopped noticing because experienced staff carry them automatically.
The issue may be process clarity, not just training
Training matters. People need context, examples, and time to learn.
But training can only teach a process that is there to be learned.
If success depends on someone remembering exceptions, spotting missing pieces, or knowing the usual workaround, then the process is still being held together partly by staff memory.
That is a different problem.
A pattern that comes up often is this: a team describes a process as documented, but the document only covers the happy path. It explains what happens when everything arrives in the right order, the information is complete, and no unusual case appears.
The harder parts sit elsewhere.
They show up when the referral form is incomplete, when two records do not match, when a funder wants the numbers grouped differently, when a repeat donation needs to be handled differently from a first gift, or when the person who usually approves something is away.
Those parts are often not written down properly. They live in someone’s head, in side conversations, or in a chain of “just ask if that happens.”
That is common in small nonprofits and small organisations. People build reliable ways of working over time. They know where to look, who to check with, which report can be trusted, and what to ignore. The team may be functioning well enough, but the process itself is not yet clear for new staff.
This is why a process can feel fine to the people who know it best while still being genuinely difficult for a newcomer to follow.
The issue is not that the new person lacks common sense. It is that parts of the process are still invisible unless someone translates them live.
And when a process depends on staff memory, the effects go beyond onboarding. It can affect consistency, reporting, handoffs, cover during leave, and how easily the team can improve the work later.
How to tell whether it is training or process clarity
You do not need a major review to tell the difference.
Start with what the new person actually needs help with.
If they mainly need practice doing a clear task, that points more towards training. They understand the steps, know what to do next, and can see where the information comes from, but they are still building speed or confidence.
If they repeatedly need live translation, that points more towards process clarity.
That translation often sounds like this:
“Use this spreadsheet, not the one in the shared folder.”
“If that field is blank, check the email thread.”
“We usually ignore that number unless it is above a certain level.”
“Send it to finance, but copy the service manager if it is grant-funded.”
“Officially it goes there, but in practice we keep the latest version here.”
That is not just training. That is the process being explained around its gaps.
A few signs are especially useful.
If the person is capable but cannot tell what applies in this case, the process may not show the decision points clearly enough.
If they can do the main step but get stuck when information is missing, the process may not show what to do when reality is incomplete, which it often is.
If they need to chase context across emails, chats, folders, and old spreadsheets before they can continue, the process may be spread across too many places to be followed reliably.
If follow-up depends on noticing that “someone should probably do the next bit,” the handoff may exist socially rather than operationally.
And if multiple new starters get stuck in the same places, treat that as process evidence.
At that point, it is less useful to frame it as a series of individual training failures. More likely, the same hidden complexity is catching each new person as they run into it.
A useful test is this: could a capable person who is new to your organisation follow the task with reasonable confidence, without needing someone to interpret what the process really means?
If the answer is no, that does not mean your team is failing. It means you have found a process that still depends on staff memory.
If you are trying to diagnose recurring friction before changing the wrong thing, you may find these More articles on spotting process problems useful.
A simple self-check
You do not need to rewrite everything at once.
Pick one recurring task your team relies on. Choose something familiar and slightly annoying rather than something unusual. It might be logging service activity, preparing a monthly report, processing donor admin, or handing work from one team member to another.
Then look at it from a new starter’s point of view.
The question is not, “Do we have a document?”
The better question is, “Could someone new follow this without extra translation?”
As you review it, check whether the process shows:
- the main steps in the order they actually happen
- the decision points that change what happens next
- the common exceptions people run into
- the handoffs between people, including who owns the next step
- what to do when information is missing, unclear, or does not match
- where the source information actually lives
You do not need a perfect manual. You are looking for the places where an experienced colleague would normally add verbal explanation.
Those are often the exact places where the process depends on staff memory.
For example, if a new staff member can follow the service logging steps but still needs someone to explain which spreadsheet version matters, that is a sign the process is unclear about the source of truth.
If a new fundraiser knows the standard admin steps but still needs unwritten naming rules and exception handling explained, that suggests the process becomes unclear as soon as real variation starts.
If a programme coordinator can technically build the monthly report but only an experienced colleague knows which figures are trusted and which anomalies can be ignored, that suggests the reporting process is relying on inherited judgement rather than shared clarity.
You may also notice that some sticking points are really handoff issues. The task looks simple until it needs input, approval, or follow-up from someone else, and then the next step depends on memory, chasing, or a side message.
If that broader question is coming up in your team, this may help: Is it a process problem or an overloaded team?
Keep the review small. The aim is not perfect documentation. It is to see whether the process is clear enough for new staff to follow without someone having to translate the unwritten parts. If the same problem appears while people learn a new system, use the staff buy-in guide to separate a training need from a process or setup problem.
Want to get started today? Use this quick checklist to test one process your team relies on and see where extra translation is still doing the real work.
How do I know if a process problem is really just a training problem?
What makes a process clear enough for a new member of staff to follow?





