Hand over everything you can describe. Become what's left.
The last chapter argued that a company's size changes the shape of its continuity risk without changing the question underneath it. That question has a personal twin, and it has been waiting since the first movement. When your repeatable work becomes inheritable, when the artifact you leave behind lets someone else run it without you, what happens to you? The organization gets stronger. The book has been clear about that. It has been far less clear, on purpose, about what the person gets, because the honest answer is uncomfortable and most career advice is built to avoid it.
Two defenses feel safe and are not. The first is to protect your repeatable execution: to be the one who knows the process, holds the exceptions, runs the report nobody else can run, and to treat that indispensability as security. The second is newer and looks like the opposite of the first. It is to use AI to produce more of that same repeatable execution, faster, and to mistake the speed for advancement. Both are moves inside the old operating model, the one that rewards owning execution and keeping knowledge lodged in particular people. I am not assigning anyone a motive here; most people who do this were taught to, by every incentive around them, and the teaching was consistent for a long time. But the ground under both defenses is moving, and building your safety on either is building on the exact thing the machines are getting good at.
Here is the distinction the rest of this chapter turns on.
Making work inheritable makes the old value portable. The person becomes more valuable only when they can take responsibility for a problem the inherited system cannot yet solve.
I had to learn that against my own instincts. I built a framework once whose human side assumed that capturing what people knew was the whole job, as if documenting a person's expertise settled the question of what that person was now for. It did not. Capturing the knowledge made the knowledge portable and left the person standing exactly where they were, holding a role that had just been made copyable. The correction I made to the framework was to stop asking only what a person knows and start asking what responsibility they take on once what they knew can be run without them. That is the question the personal method exists to answer.
The answer is a loop, and it runs in one direction. You do the work yourself first, long enough to understand it and make the mistakes in it, because you cannot hand off or automate what you never understood. You make the repeatable part inheritable, starting with the one boring step, not the whole job at once. You move up to the judgment the procedure could not hold. You look for the next problem worth solving, usually one domain over from the last. And you make that new thing inheritable too, and go again. The specialist climbs one ladder. The Blank Collar keeps stepping off the ladder they just built, because the ladder was never the point. The stepping off was.
Call the personal method the Blank Collar Card, and be precise about what it is and is not, because the temptation is to treat it as the Company Card pointed at a human being. It is not. The Company Card asks whether an organization can inherit its work. The Blank Collar Card asks a different question, of a different subject, with different evidence: what repeatable work did this person make inheritable, and what accountable responsibility did they take on afterward? It reads one completed cycle of transfer and growth, and only that. It does not grade a career, a personality, or an identity, and it does not run on the organizational scoring the Company Card uses. Borrowing that machinery would turn a personal method into a performance instrument, which is the opposite of what it is for. The two cards belong to the same Blank Collar framework and answer questions that must not be confused.
The card reads one completed work cycle. Its face carries the four fields Chapter 15 showed you, and behind them it wants five specific pieces of evidence. First, the work that was handed over, and the artifact, procedure, or machine setup left behind to carry it. Second, evidence that another qualified person or system could restart, run, and check that work without leaning on the original owner's memory. Third, the exception or unresolved problem the person took on once the routine was handed off. Fourth, the accountable decision, correction, or result they produced in that new responsibility. Fifth, evidence that they began building the next inheritable method, so the cycle can repeat.
Run those five through the workflow this book has carried, and label it plainly: schematic, not a person assessment. The recurring responsibility is handling routine refund requests, and the person has made that inheritable by building an approved artifact from which the routine path runs. The handoff evidence is that another qualified role can now take a routine refund, work it from the artifact, and check the result, without asking the person who built it how it goes. That is the transfer, and on its own it is where most stories stop. What makes this a Blank Collar cycle is what comes next. The routine path leaves a residue it cannot settle: the disputed renewal, the customer who says they tried to cancel, the case the artifact was never built to decide. The person takes that on. Their bounded next responsibility is to review the pattern of those disputes and propose or own an authorized correction to the policy or the escalation rule. And the next inheritance begins the moment that correction is recorded so that another qualified person can apply it and challenge it, which turns the person's new judgment into the next thing that can be handed over. I am inventing no outcome for this, no promotion, no metric, no proof that it happened twice. It shows the shape of the cycle, and the shape is the teaching.
The evidence has to be evidence, which means holding two easy substitutions at arm's length. An artifact existing is not the same as a handoff working. A written procedure can sit in a shared drive, complete and unread, while the work still routes back to the person who wrote it, because nobody has tried to run it from the page alone. The handoff counts only when a qualified person or system actually restarts the work from the artifact, runs it, and checks the result without the original owner in the loop. The second substitution is on the growth side. Taking on a title is not the same as producing an accountable decision, a correction, or a result. Being named owner of exceptions proves nothing until an exception has been decided and the decision can be pointed to. One completed cycle, no score, no verdict on anyone.
Describe evidence strength honestly and with only three levels: claim only, demonstrated once, or demonstrated repeatedly. A person who tells you they made their work inheritable is at claim only until an artifact and a working restart exist. Demonstrated once means an artifact exists, a qualified role restarted the work from it, and an exception was actually decided, both visible. Demonstrated repeatedly is where the evidence gets hard to fake, because a cycle run three times, on exceptions that varied, with the dependence on the original owner dropping each time, is a practice and not a story. Repetition earns confidence. It does not produce a grade, and anyone treating it as one has misread the card. Handle the evidence the way the work requires: gather it through authorized access, and keep it inside the permissions and privacy rules that govern the underlying records.
Two gates decide whether a reading counts, and they are the whole discipline. A handoff with no new responsibility assumed is a transfer, and transfer alone is not personal growth; it made your old value portable and left you to answer the question of what you do now. A new responsibility with no demonstrated handoff behind it is expansion built on continued dependency, someone taking on more while still being the single point everything routes through. The Blank Collar pattern requires both: the work demonstrably left, and a harder responsibility demonstrably taken up. Either one alone is a familiar career move. Together they are the thing this book is named for.
The transfer half is more learnable than people expect, because it uses instruments managers already own. To make repeatable work inheritable, whether the inheritor is a person or a machine, you define the objective and what a correct result looks like; you map the repeatable work as it actually runs, including its exceptions; you brief the inheritor on the work and its boundaries; you establish the operating loop and the condition under which it hands difficult cases back; and you verify through use, checking the output without hovering over every run. None of that is a new named model. It is delegation, applied with enough rigor that the thing delegated can be run by someone else and checked by another qualified role.
I will give you one from my own work, unnamed on purpose, and offered as testimony rather than proof. I have walked into operations where making a new hire useful took months, most of it spent shadowing whoever happened to be free, and left with an onboarding a new person could run in days, because the thing that used to live in the shadowing had been written into something they could actually follow. The point is not the speed. The point is what the speed indicates: the knowledge stopped living only in one experienced person's availability and started living in an artifact. That is the transfer half, seen in practice. It is where the work starts, not where it ends.
The growth half is the part no artifact can do for you, and it is a set of real activities, not a mood. Judging the exceptions the procedure cannot resolve. Reframing a problem the current method answers badly. Making a decision you can be held accountable for and recording why. Creating a method where none existed. At greater scope, assembling and directing people, AI agents, or both, verifying what the combined system produces, and owning the consequences. That last part does not transfer to the agent team. It stays with the person who had the authority to put the system in motion. Where execution gets cheaper to replace, this is the work that is harder to hand to a machine, and it is where a person's contribution can keep growing.
Be careful with the market claim underneath all this, because the loud version is wrong. Repeatable execution is increasingly exposed wherever software can perform it, and that exposure is real and worth taking seriously. It does not follow that judgment is universally safe, that anyone doing judgment work is protected, that salaries must rise, or that one tidy market mechanism explains what happens to every job. The claim is narrow: the part of your work that can be written down and run by something else is getting cheaper to replace, so building your position on that part is building on sand. What you build on instead is the responsibility the sand cannot hold.
If you are early in your career, do not read this as instructions for later. You do not need seniority or authority you have not been given to start, and waiting for them is its own trap. Take one repeatable responsibility you actually hold, and build the artifact that could carry it, the written thing from which someone else could run it. Then propose the next legitimate handoff through an authorized channel, and ask, in the same motion, for what makes the handoff worth making to you: bounded ownership of something with visible consequences, corrective feedback when you are wrong, exposure to problems outside your lane, and responsibility for the exceptions your routine work throws off.
I have watched how fast this can go when someone actually does it, and I will keep the example unnamed and offered as what I saw, not as proof of a law. With bounded direction and several days of their own effort, a motivated person in a nontechnical function can take a recurring report or the same answers repeatedly typed to customers and turn part of that work into something another person or system can run. What happens next is the whole point of this book. If credible responsibility follows, the returned time can move toward the harder part of the job. I did not make those people more valuable by handing them a tool. The tool opened a transfer. The organization and the person still had to complete the trade.
I have to be honest about the limit of that, because pretending otherwise would make the card a weapon against the people it is meant to help. A junior cannot manufacture authority the organization withholds. The card can show, cleanly, that you made your routine work inheritable and were then handed no access to outcomes, no exceptions, no judgment, only more routine. That is a real and useful finding, and it is a finding about the organization, not a failure of the person. What the employer owes in that situation is the next chapter's subject.
One more boundary, because this chapter sits one shelf away from a genre it must not join. This is not a mindset test, a productivity routine, an identity quiz, or a personal-brand exercise, and completing the cycle guarantees you no promotion, no raise, no security, and no protection from change. Every reading the card produces has to rest on actual work and an actual consequence, which is exactly what separates it from the self-assessment that asks how you feel about your potential. The example in this chapter is the only card I will complete for you, and I ran it on a labeled schematic precisely so it grades no real person.
The identity in the book's title is not a status you claim. It is a pattern you earn by running the cycle more than once: make a piece of work inheritable, take on the problem it could not solve, turn your answer into the next inheritable method, and do it again from a harder starting point. A person who has done that once has evidence. A person who has done it repeatedly has a practice.
And a person can do all of it, correctly and repeatedly, and still be held down, because the method lives inside an organization whose hiring, promotion, and pay may reward the opposite behavior. You can make yourself inheritable in a company that only ever promotes the indispensable. That is not a flaw in the method. It is a fact about the system the method runs in, and it is where this book turns next.