The Shadow Onboarding

Years ago I ran a small electronics workshop inside a university chemical engineering department. When a new researcher or postgraduate joined, the department handed them an induction that ran to sixty-three links. The week one of them came to work with my workshop, I clicked all sixty-three, because I wanted to know how much of what the department told a new arrival about itself was actually true. Thirty-one of the sixty-three still went anywhere at all. Of those thirty-one, nine led to a page that had been quietly superseded by a newer one that said something different, and four led to a document whose owner had left at some point that nobody had got round to recording.

On the new researcher’s sixth day, a colleague nobody had asked to help them sent them a document in a private message. The line above it read: ignore the onboarding space, this is the one we actually use. I saw it only because the new researcher, unsure which of the two versions to trust, forwarded it to me and asked. The document was fourteen pages long and had been written, as far as I could tell, by four or five different people over a couple of years. Every link in it worked. In its first two pages it answered three of the questions the new researcher had spent the week failing to answer from the official version, and over the rest of it answered another dozen they had not yet known to ask.

I read the official onboarding and I read the document the colleague had sent, and the distance between the two told me more about a place I had worked in for years than its official version had ever been built to tell a new joiner at all. I have come to think of that distance as one of the most useful things a new joiner is ever handed, and as the thing those of us already inside most reliably mistake for a problem to be tidied away.

How the shadow onboarding gets built

Every team I have worked inside has had a shadow onboarding, and the engineers I compare notes with describe the same thing at companies I have never set foot in. As far as I can tell they are all built the same way. The official version is written once. It is usually written by someone who was asked to write it rather than by someone who does the work it describes, and once it has been written it is, in the sense that matters, finished. Nobody is made responsible for it still being true a year later. It is maintained, when it is maintained at all, in short bursts, by whoever has most recently been embarrassed by it in front of a new starter.

The shadow document is built the other way round. It is written by the people closest to the work, a paragraph at a time, because they need it to be true in order to get through their own week. When a step in the real process changes, the person the change inconveniences updates the document that same afternoon, since the cost of not updating it is being asked the same question again the following week by the next person who walks into the same wall. The official document describes the organisation the way it would like to be described. The shadow document describes the organisation the way it runs, because the people keeping it current cannot afford for it to describe anything else.

The gap is sharpest wherever the official process is the most controlled thing in the building. A university workshop is inspected and audited, it has procedures for safety and for procurement, and a quality manual that exists in the form it does partly so that an inspector can be walked through it. Somewhere alongside all of that, in a document no inspector will ever be shown, is the knowledge of how you actually get a part machined before the week is out, who really signs the dangerous things off, and which of the rules can be skipped and which will hurt you. Both versions are real. Only one of them is written down where the institution can see it.

The instinct to make it official

When I understood what the colleague’s document was, my first instinct was the one I have slowly learned to be suspicious of in myself. I wanted to fix it. The fix seemed obvious to the point of being barely worth thinking about. The shadow document was plainly better than the official one, so the official one ought to be replaced by it. I would take the fourteen pages, move them into the onboarding space, retire the dead links, and the department would at last have an induction that told its new arrivals the truth on the first day rather than the sixth.

I got as far as opening both documents side by side before I saw the difficulty.

The reason the shadow document was true was that it had no owner sitting far from the work and no approval step standing between a change in the world and a change in the page. The moment I moved it into the official space it would acquire both. It would belong to whoever owned the onboarding space. A change to it would have to be reviewed by someone whose responsibility was the document rather than the work the document described. Within a few months it would say what the official onboarding had always said, which was whatever happened to be true on the last day someone with the authority to edit it had found the time to look. And the people closest to the work, finding once again that the official version could no longer be relied on, would do the only sensible thing available to them, which was to open a fresh document in private and tell the next new joiner to ignore the wiki.

I would not have fixed the shadow onboarding. I would have converted a true document into an official one, which is the same thing as starting its decay.

I would not, in other words, have closed the gap. I would have moved it. The shadow onboarding was never the symptom of a documentation failure that a better document would cure. It was the organisation’s standing answer to a problem the official system kept reproducing, and absorbing this one instance of the answer would simply have produced the next one, on a colleague’s laptop, by the end of the quarter.

What the document actually was

It helped to give the thing a name. The official onboarding is a small and complete portrait of what I have come to call the Stated System, the version of an organisation that fits on a slide: the org chart, the written process, the planning cadence, the roles that have descriptions, the language used in the rooms where the organisation describes itself to itself. The shadow document is a survey of the Lived System, the version that lives in nobody’s official documentation, where the real decisions get made, whose calendar actually sets the pace, which channel carries the truth, and who you have to ask when the wiki is wrong.

The distance between the two is what I call the Drift, and a shadow onboarding is the cheapest reading of that distance an organisation will ever be handed, because somebody has already done the survey and written it down for you. It tells you, in specifics rather than in the abstract, the exact places where what the organisation says about itself has quietly stopped being true. There are three questions I try to hold open when I read it. What does the Stated System say is supposed to happen when somebody joins. What does the Lived System actually do. And, the question that turns the whole thing from an interesting observation into a decision, who is paying for the gap between the two.

In the case of onboarding the answer to the last question is not hard to find. The new joiner pays, in a first week or two spent discovering by trial that the official map does not match the territory, which is a poor use of the most undivided attention they will ever bring to the place. And the colleagues who keep the shadow document current pay, in time they are not credited for, on a piece of work most of them are quietly unsure they are even allowed to be doing. A shadow onboarding is the most honest audit of a Stated System that an organisation ever produces, it produces it for nothing, and almost nobody in a position to act on it reads it as an audit at all.

The diagnostic

The useful question turned out to be a count rather than a judgement, which is usually where these things end up. The question to ask is not whether your onboarding is any good. The question is how many days pass between a new joiner’s start and the moment somebody hands them the real one, and who it is that hands it over.

The induction tracker, which is a part of the Stated System, will tell you that a person was onboarded on their first or second day, because onboarding in the Stated System is a checklist and a checklist can be completed in an afternoon. The day the first genuinely useful answer arrives, the answer a colleague gives quietly in a private message, is a different date entirely, and the number of days between the two dates is the size of the gap you are actually running.

When I sat down with the new researcher and counted their first week honestly, they had asked something close to nineteen real questions, the kind where they could not do the next thing until they had the answer. The official onboarding had answered three of them. The document a colleague sent on the sixth day answered the other sixteen. I would not have guessed those numbers if you had asked me before we counted. I would have said the department’s induction was roughly fine and a little out of date, which is what everybody says about every official onboarding, and which is the answer the Stated System is built to keep producing.

Why none of them will sign it

Not long after, I caught myself becoming the person who sends the document. Another researcher joined, and on their sixth day I found myself drafting a private message with a very familiar shape to it: a document attached, and a sentence at the top that began, ignore the onboarding space. I stopped with the sentence half written and looked at it for a while.

Since I first noticed the pattern I have taken to asking engineers I meet from other companies whether they have a document like this one, and so far not one of them has said no. Each of those places had arrived, on its own and without comparing notes with the others, at precisely the same solution to precisely the same problem. A true description of how the work was done, kept just out of official sight, maintained by the people who do the work, and handed quietly from one person to the next on or around the sixth day. I had been onboarded by such a document more than once myself, and now I was one of its authors, and in none of these places, the ones I have worked in or the ones the people I ask describe, had anyone decided that the document everyone actually used should simply become the document the organisation admitted to.

I sent the message, and I left the sentence in, because the new starter needed the real document a good deal more than they needed my discomfort about how they were getting it. The more useful question, and the one that took me the longest to surface, has nothing to do with how to write a better onboarding. It is a question about why the truest account of how each of these organisations works is the one none of them is willing to put its name to, and what it would take, in any of them, for the official system to become the one that tells the truth. I am still working that one out.

The scenes in this article are drawn from early in my career, anonymised and, where necessary, composited from more than one context. They are intended to illustrate organisational patterns, not to describe a specific employer, institution, programme, or team. The views are my own.

This is one chapter, condensed, from my forthcoming book Leading Agile When No One Agrees, which works through the Drift framework across twenty-two chapters of scenes drawn from a career inside engineering organisations, from an early one running a university workshop to large-scale agile transformations. The book is in final preparation for a Summer 2026 publication. If this piece resonates, the companion worksheets may be useful in the meantime, starting with the Drift Check. For anyone who would rather work in a terminal, drift-cli runs the same five-question check locally and never sends the result anywhere. A score that gets reported upward stops measuring the gap and starts producing it, so the tool keeps it on your machine by design.

More writing and book launch updates at kylehauslaib.com.