Size is not a grade.
The last chapter left redesign at the scale of a single workflow. That raises a plain question. If the work changes one workflow at a time, what does the size of the company change, and what does it leave exactly the same?
Start with the objection that sounds decisive, because it arrives with a number. In an OECD survey of more than 5,000 small and medium-sized enterprises across seven countries, collected at the end of 2024, one-person companies were less likely to report using generative AI than firms in the 50-to-249-employee band: 23.6 percent against 45.8 percent. There it is, apparently. The small are behind, and they should wait until they can afford what larger firms already have. Look, read what the number measures. It counts who reported using a tool, and the survey's own authors caution that firm-level surveys may miss employee use nobody disclosed. Even among the SMEs that did report use, only 28.7 percent said they used generative AI in core, revenue-producing activities. Reported adoption and redesigned work are different things, even inside the firms that adopted. A company can use a tool every day and have redesigned nothing. A company can report almost no use while its operating design sits in a state that would make redesign quick the moment it began.
That gap is what the title means, and it means something narrower than a boast. I have worked inside large organizations and small ones, and the inference I draw is about operating design, not about the survey. A small company may be early, before its way of working hardens into the systems, permissions, contracts, and politics that make an established workflow expensive to change. That is an opportunity, not a ranking. Early does not mean better, faster, or more prepared, and small carries its own exposure: more work concentrated in named people. It means the wet cement has not set. That is worth something only to a company that shapes it before it does.
An SMB and an enterprise ask the same question at two sizes.
The question does not move with headcount. Can another qualified person or system restart, run, check, and improve critical work without depending on the original owner's memory or presence? That is the inheritability question the whole book has asked, and it is scale-independent. What changes with size is the shape of the exposure, not the question. Reading that shape correctly is the work of this chapter.
Refuse the reflex to grade by size, in either direction. A disciplined enterprise with clean artifacts can be more inheritable than a brilliant, disorganized startup where several critical things live in one founder's head. A small firm can be quick to change a workflow and still carry a real continuity exposure it has never tested. Size is not a grade, and treating it as one is how both large and small companies misread their own risk.
The specific small-company exposure gets moralized when it should be diagnosed. One person holds a critical piece of the work. That is not evidence of hoarding, resistance, low value, or poor performance, and inferring any of those is unfair and analytically lazy. In a small company, one person holding a role is arithmetic. What matters is a distinction people blur: whether the work slows when that person is away, or stops. Slowing is a capacity question, and capacity questions are ordinary. Stopping is a continuity question, and continuity is what the framework is actually testing here.
Because one-person roles are normal below a certain size, the framework uses a convention instead of a naive test. Below roughly thirty people, it reads for succession rather than automatically treating a single incumbent as a failure. Treat "roughly thirty" as a practical convention of the Blank Collar framework, not a cutoff anyone discovered in data. The reason is simple. A test that flagged every one-person role as a defect would flag the whole company and teach you nothing. The succession reading asks the useful question, whether the work could restart, not whether one person happens to hold it. That single move is what lets the framework apply to a very small firm and a very large one without pretending the small one is a shrunken version of the large.
The question itself has a fixed form.
If this person were gone for a fortnight, what would stop, and is there a written artifact from which someone else could restart it?
Ask it of the critical workflow you selected in Chapter 9, not of a person you have privately decided to worry about. That distinction is the whole ethics of the exercise. The moment it becomes about an individual it becomes an accusation, and it is meant to be about a workflow. The two-week continuity condition is common to both scales. The succession reading is what keeps a small firm from failing merely because one capable person holds a role that only needs one person to hold it.
Run it as a tabletop exercise by default. Walk the restart through on paper, with the qualified replacement role reading the artifacts and narrating what they would do at each step. A tabletop can reveal gaps without touching live operations. A live simulation, where someone actually takes over the work, is permitted only after the required authorization and worker consultation, and never by sharing credentials, bypassing separation of duties, cutting anyone's pay, or changing employment conditions. Before any live run, write down the workflow, the qualified replacement role, the access required, the operating standard that counts as success, the conditions that stop the test, and the window over which you will watch. Predeclaring those turns a probe into evidence instead of an anecdote, and it makes a second run comparable to the first.
Keep one access-controlled record of the result: the workflow, the dependency category, the version of the artifact used, the qualified replacement role, the permissions needed, what stopped or merely slowed, the exceptions that surfaced, the repair required, the categories of cost involved, and a retest date. Where a job title is unique enough to identify its holder, use a functional role code or dependency category instead, and keep unique personal descriptors out of it. Retain only what law, collective arrangements, legal holds, and your approved records schedule require, and dispose of other identifying test material through authorized records and privacy procedures once the repair is done and the retention period has passed. Keep the whole record outside routine performance and headcount processes, because it is not one of them, and because a record built to protect continuity must not become a record that exposes a person. Its job is to support the next restart and let a later attempt confirm the first.
Read the record as a set of distinctions about work, not a verdict about a worker. Stopped is a continuity finding. Slowed is a capacity finding, and the two call for different responses. A missing artifact means the written thing a restart needs does not exist, which is a fact about documentation; unavailable evidence means you could not lawfully or safely establish whether it exists, which is a fact about your access, and the two must not be recorded as the same result. A missing permission means the replacement role lacked the access to proceed, which a grant can fix; it is not a sign the person lacked competence, and reading it that way is exactly the corruption the worker-safety ruling forbids. An exception is not the ordinary flow failing; it is the case the standard path was never built to carry, and it belongs in its own column. When you retest, use the same predeclared standard you wrote down the first time, because a standard adjusted between runs measures your leniency, not the repair. If the second run clears where the first stopped, that supports the repaired workflow and nothing wider: one confirmed restart is evidence about that workflow, not a grade on the company or the person, and it stays inside the same access-controlled, privacy-bounded record as before.
State the limit plainly. One restart attempt is a probe. It can reveal a dependency; it cannot grade the company, condemn the person who held the role, or prove that every other workflow shares the same exposure.
For a small company, a found dependency has more than one honest answer. Succession planning, cross-training a second person, maintaining the operating artifact so a restart is possible, arranging permission coverage, lining up an alternative supplier, buying insurance, or consciously accepting the risk with open eyes. Not every dependency has to be removed. Some are cheaper to insure or accept than to engineer away, and a small firm with little spare capacity is entitled to make that trade on purpose rather than by neglect.
For an enterprise, the same probe finds a different animal, because dependencies there run across functions, systems, countries, policies, authorization layers, and vendors. Extra headcount around a workflow is not coverage on its own. Coverage means an authorized replacement role, or a coordinated qualified team, that actually holds the artifact, the permission, and the authority needed to restart the work. Where those are supplied, the coverage is real. Where any is missing, the adjacency is just presence. So the enterprise runs the identical two-week restart probe to learn whether its distributed coverage is genuine. And it applies the same test to outsourcing, because moving work to a supplier does not remove a dependency; it relocates it, and it counts as coverage only if another qualified provider or an internal operator could take the work over within a usable notice and transition period. A single supplier with no alternative is a named-person dependency with a corporate logo on it.
Price the repair honestly, because software spend alone is not the repair cost. The real cost includes the owner's and the backup's time, the throughput lost while people train instead of produce, the documentation itself, provisioning access, security review, running the old and new ways in parallel, validating quality, consulting the workforce, outside advice where you need it, changing systems, and maintaining all of it afterward. Quote only the license and you have priced the receipt, not the repair.
The scale economics differ without resolving into fixed durations or a speed ranking. A small firm pays in the currency it has least of: scarce production capacity and leadership attention diverted from live work to fix continuity. An enterprise pays in coordination, consultation, control validation, and integration, but often has redundancy, specialists, and capital a small firm does not. Either can be faster in a particular workflow, and anyone who tells you small is always nimble or large is always slow is selling a slogan in place of a diagnosis.
One ruling governs all of it, and it is not optional. This finding describes a workflow risk and a management obligation. It is not an employee defect, and it must never be used to select, rank, justify, or supply evidence for a layoff, a performance action, a compensation decision, or any other adverse action against the person who held the role. Its legitimate outcomes are coverage, authority, access, transition support, insurance, or conscious risk acceptance. A restart record that turns into a target list has been corrupted into the opposite of its purpose. Keep names, salaries, rankings, health and leave data, protected complaints, and employee-level telemetry out of it, and secure the appropriate labor, privacy, security, collective, and sector review before any live test. Never time the probe to a real absence. Running it while someone is on, beside, or just back from medical, disability, parental, or other protected leave turns a continuity check into evidence about a protected event, so in those cases the test is the tabletop walk-through only, on paper, and never a live handover. And be honest about where the protection comes from: where works councils and dismissal-protection law apply it has legal force, while in an at-will market it is only as strong as the employer choosing to honor it, so a worker there should not mistake the ethic for a shield. None of that is legal advice, and a restart record does not satisfy any legal or regulatory obligation on its own.
Keep the human consequence in view, because it is the same one the book has carried throughout. When a person makes their work inheritable, support them, and open room for responsibility beyond the workflow they just handed over. Credit for what they transferred, safety in having surfaced it, learning that moves them forward, and a credible next responsibility are what make the transfer worth making from their side. Any reward or role change runs through a transparent, policy-compliant mechanism, with consultation where required, and never by publicly labeling someone the dependency or by deriving their pay from the restart result. The transfer makes the old value portable. It does not, by itself, make the person more valuable, which is exactly the question the transfer exposes and cannot answer.
That question is where the organization side of the framework reaches its limit. Once the organization can inherit the work, what responsibility must the person grow into on the far side of the handoff? The framework has taken the company as far as inspection can take it. The company was the first move. The person is the second. The person is the next chapter's subject.