Your senior project manager sends a resignation email on a Tuesday. By Friday, three clients are calling because nobody knows the status of their deliverables, two invoices got missed, and the new hire your sales team just closed has no onboarding plan because the entire playbook lived in that PM's head and their personal Notion workspace.
This is the bus factor in action — the number of people who would have to disappear before your operation grinds to a halt. For most professional services firms in the US and Canada, that number is uncomfortably close to one. And it isn't because they hired the wrong people. It's because they built the operation around people instead of around systems.
The instinct when someone critical leaves is to ask "why didn't we document this?" That question already misses the point. Documentation is a snapshot. Operations are a moving target. By the time you finish documenting how Sarah runs client onboarding, Sarah has already changed three steps because a client complained or an integration broke.
The structural issue is that the company never decided who owns the process. When ownership defaults to the person doing the work, the process belongs to that person. They tweak it, optimize it, and store it in their head, their Slack DMs, their personal spreadsheets, and their email threads. The company technically employs them but operationally rents the process from them.
Every quarter your team gets better at doing the work, but that improvement doesn't accrue to the company — it accrues to the individual. Five years in, your top PM is irreplaceable not because they're a genius but because they're the only person who knows the seventeen workarounds your operation depends on.
That isn't loyalty. That's leverage. And it eventually gets exercised — either through a counteroffer, a competitor's recruiter, or a burnout-driven resignation that leaves you scrambling.
Most operations leaders respond to this risk with some combination of three moves: write SOPs in a wiki, hold cross-training sessions, and require everyone to "document everything" in a shared drive. After six months, the wiki is outdated, the cross-training is forgotten, and the shared drive has 400 files nobody can find.
The reason this fails has nothing to do with discipline. It fails because documentation and execution are two different artifacts. The SOP lives in Confluence. The actual work happens in Asana, Gmail, QuickBooks, a CRM, and three browser tabs. The minute the two diverge — which is immediately — the documentation becomes fiction and people go back to doing it the way Sarah taught them.
Documentation describes a process. It doesn't enforce one. A new hire reading your SOP wiki still has to translate that description into actual clicks, fields, and handoffs across a dozen tools. If those tools don't guide them through the process, the SOP is theater.
The real fix isn't more documentation. It's making the operation itself the documentation — so the system you use to do the work is also the system that defines how the work is done.
Here is the reframe. Stop asking "where do we document our process?" Start asking "where does our process execute?" Those should be the same place.
When a deal closes, a sales rep shouldn't open a wiki to remember the handover checklist. The CRM should create the handover ticket automatically, assign it to operations, populate the fields from the deal, and notify the project manager. The process isn't written down somewhere — it's embedded in the workflow.
When a project hits a milestone, the PM shouldn't have to remember to send an invoice request to finance. The system should generate the invoice record, link it to the deal, and trigger the approval flow. The knowledge of "what happens next" doesn't live in anyone's head. It lives in the object relationships, the pipeline stages, and the automations.
The first thing that changes is onboarding. A new project manager doesn't shadow Sarah for three weeks to learn how things are done. They open the CRM, see their assigned tickets in the right pipeline stage, and the system tells them what comes next. The learning curve collapses from months to days because there's nothing tribal left to learn.
The second thing that changes is auditability. You can answer questions like "how many billable hours did we lose on the last twelve projects because of scope changes that weren't logged?" in two minutes. Today, that question requires someone to read through Slack threads and email chains for a week.
The third thing — and this is the one most leaders underestimate — is that improvement becomes institutional. When a PM finds a better way to handle a recurring issue, the fix gets built into the workflow. The next person to encounter that issue doesn't have to rediscover the solution. The company gets smarter, not just the individual.
You don't need an audit firm to find out how exposed you are. Walk through these checks with your leadership team and be honest about the answers.
For a US or Canadian services firm with 20 to 200 employees, fixing the bus factor isn't about buying more software. You probably already have enough licenses. The fix is about architecting the system so that the process lives inside the objects you already use.
That means deals carry the commercial truth. Tickets carry the operational work, broken down by team — presales, delivery, QA, finance — each with its own pipeline. Projects carry the execution state, including costs, incidents, and progress. Invoices roll up into the deal so margin is visible in real time, not at quarter-end. Every handover is a state change in the system, not a meeting.
Automation isn't about replacing people. It's about removing the parts of the process that require someone to remember to do something. When the deal moves to closed-won, the handover ticket is created automatically. When the project hits 80% of budget, finance is notified automatically. When a client hasn't been contacted in 30 days, the account owner gets a task.
None of this depends on Sarah remembering. The process executes whether Sarah is at her desk, on vacation, or working at a competitor.
The US and Canadian labor market for senior operations talent has changed. Tenure is shorter. Counteroffers are aggressive. Remote work has made your senior people visible to recruiters they never would have met. The probability that your most critical person leaves in the next 24 months is materially higher than it used to be.
The companies that survive that turnover without operational damage are the ones where the process was never tied to the person in the first place. The companies that don't survive it discover, the hard way, that they were renting an operation instead of running one.
When the process lives in the system, growth stops being a hiring problem and starts being a capacity problem. You can onboard a new PM in a week instead of three months. You can promote someone from coordinator to lead without losing the institutional memory their predecessor accumulated. You can acquire another firm and integrate their operations because yours is documented in software, not in tenure. You can leave for two weeks and the business runs.
This is the difference between a business and a high-functioning group of individuals. A business has assets that persist when people leave. A group of individuals has relationships that walk out the door. If you want to see what an operation looks like when the process belongs to the company instead of the people, this is the model we build for firms that sell projects — designed so that resignations are inconvenient, not catastrophic.