How to Capture a Process That Exists in Employees' Heads

Ask three people on an employee onboarding team to describe how a new hire gets set up, and you will likely get three different answers. Not because anyone is lying, but because each person has learned the process from their own corner of it, adjusted it over time to handle problems nobody documented, and never had a reason to compare notes with a colleague doing a slightly different version of the same job. This is what "tribal knowledge" actually looks like in practice: not a single hidden truth waiting to be extracted, but a set of overlapping, partially contradictory understandings that each contain real information.

Why tribal knowledge forms in the first place

Processes drift because people solve problems as they arise, and those solutions rarely get written back into an official record. An HR coordinator handling employee onboarding might learn, after a couple of bad experiences, to always confirm a new hire's equipment order two days before their start date rather than trusting the automated confirmation email, because the automated one has been wrong before. That fix works, it gets repeated, it becomes part of how that coordinator does the job, and it never shows up in any document because there was never a document to update. Multiply that across every person who has ever touched the process and you get a process that runs successfully day to day but cannot be fully explained by any single person.

How to interview without putting people on the defensive

The framing of the conversation matters more than most people expect. Opening with "walk me through what you're supposed to do" invites a sanitized, official-sounding answer, because it sounds like you are checking compliance against a standard. Opening with "walk me through what actually happens, including the parts that are a bit of a workaround" gives people permission to be honest, and most people are relieved by that permission rather than suspicious of it. It also helps to ask about a recent specific case rather than the process in the abstract. People remember what they did with an actual new hire last month far more precisely than they can generalize an abstract rule for how onboarding is supposed to work.

Walkthroughs with real cases

Once you have a rough shape of the process, the most reliable way to sharpen it is to walk through two or three real, recent cases in detail. For employee onboarding, that might mean picking last month's new hires and tracing exactly what happened for each: when the offer was signed, when IT was notified, when the equipment arrived, whether the manager sent a welcome message before day one, and where anything went differently than expected. Real cases surface details that abstract descriptions miss almost every time, particularly around timing and handoffs between roles, because people notice concrete facts about a specific case that they would never think to mention as a general rule.

Capturing the workarounds people do not volunteer

Some workarounds do not get mentioned voluntarily, usually because the person doing them assumes everyone already does the same thing, or because they are mildly embarrassed that a workaround is necessary at all. Direct, low-stakes questions work better than open-ended ones for this: "is there anything you do that isn't in the official steps, that you'd be worried would stop happening if you were out sick for a week?" tends to produce answers that a general "describe the process" question does not. It is also worth asking what happens when the person is away, since the answer often reveals which steps genuinely depend on one individual's private habits rather than a documented, transferable procedure.

Resolving contradictions between two accounts

When two people describe the same step differently, resist the urge to decide who is right before investigating further. Often both are right, describing genuinely different situations without realizing it: one person handles onboarding for a specific department that has an extra approval step, another handles a department that does not. Sometimes one account is simply outdated, describing a version of the process that changed after a tool or policy update the person never fully absorbed. The way to resolve it is to bring the specific disagreement back to both people together, or trace it through a real case, rather than guessing which account to trust.

Running a validation session

Once a draft map exists, put it in front of the people who actually do the work and ask them to find what is wrong with it, rather than asking them to approve it. Framing the session as a search for errors, rather than a sign-off, produces much sharper feedback, because people are more willing to point out a mistake in someone else's draft than to raise a concern that might look like it is holding up an approval. Walking through the map step by step against a real case, live in the room, tends to surface disagreements that a silent document review never would.

How Processfix supports this stage

Processfix is designed to work from exactly this kind of raw material. A process described in plain language, or an existing SOP or PDD extracted from a document, can be turned into an editable swimlane model, and Processfix asks clarifying questions where the description is ambiguous or incomplete, which mirrors the kind of probing a good interviewer would do by hand. The resulting map is a starting point for the validation session described above, not a substitute for it. Processfix models the process people describe, it does not independently confirm that a particular workaround is technically feasible or that a system genuinely behaves the way someone assumes it does.