Orientation Before Productivity: What Onboarding Is Actually For

It was their first afternoon, and the morning had already covered everything a company owes a new employee by law, the HR welcome, the health and safety briefing, the tour of facilities. What came after lunch was the part of the day I had designed myself, a starting notes document written specifically for them, and it's the part of that day I still remember most clearly.

It ran to several pages. Names and reporting lines. Links to the systems and documentation they'd need. The business process leads they'd have to build a relationship with before they could get anything done at all. Their objectives for the first six weeks, and the shape of the work waiting behind them. I walked them through it quickly, since a document read aloud loses most of its value, and then we spent the rest of the afternoon on the duller business of getting them logged in and chasing down the handful of systems still waiting on access. We came back to those notes every week for the first month, not to tick boxes, but to rewrite them together as they worked out which parts were useful and which parts I had simply guessed at. For the first few days I walked them to every introduction myself and made them in person, because there is a particular kind of loneliness in being pointed vaguely towards a room and left to explain who you are. Nobody should start a job that way.

The plan itself, once you stripped away the detail, was almost embarrassingly simple: six weeks, one department at a time, customer service, planning, production, shipping, finance, IT, maintenance, a systematic tour of an entire operation before they wrote a line of anything. The breadth of it said something before they had done a single day of actual work, and said it more persuasively than I could have managed in conversation: your job here is to understand this business, not merely operate its systems. Productivity, whatever the rest of the organisation seemed to believe, could wait. Understanding had to come first. Everything built without it needs rebuilding eventually anyway.

Most organisations, in my experience, get this precisely backwards. They optimise for speed to productivity over depth of understanding, hand a new hire a laptop and a desk and a handful of starter tickets, and leave them to assemble the rest from context clues. The implicit message, however kindly delivered, is that we need you contributing as fast as possible, and contribution without context isn't really contribution. It's activity. It's code that solves a problem nobody actually has, or analysis that answers a question nobody was asking, technically correct and strategically adrift, busy without ever quite being useful.

Onboarding isn't process orientation. It's cultural transmission, whether you intend it to be or not. What you ask someone to learn in their first month, who you ask them to meet, what you set them to do while everyone else is still forming an opinion of them, communicates what you actually value long before you get round to saying so out loud. A morning of induction followed by here's your laptop, here's your team, good luck, tells a new hire that productivity outranks understanding. Six weeks of systematic rotation through every corner of the business tells them the opposite. Nobody has to say either thing. The plan has already said it.

Two Plans, One Philosophy

I've designed and run two onboarding plans that look nothing alike and answer the same underlying question in opposite directions, which is either evidence that the philosophy holds regardless of context, or evidence that I'm inconsistent enough to make two different things look principled in hindsight. I'll let you judge.

The first was for a technology team, six months rather than six weeks: induction and a handful of low-stakes tickets in month one, a structured rotation through senior developers for months two to six with each month documented as it happened, then joining a team properly for its OKR cycle from month seven onward. Always Be Teaching, made structural rather than aspirational.

But the detail that mattered most wasn't the shape of the plan. It was what happened at the end of every single introduction session: an exercise. Sit with the web team, learn the brand, then summarise it in exactly three sentences. Tour the factory, then come back with the three most impressive facts you found there. Meet a department, then name its biggest challenge and propose something that might help. None of this was accidental. It grew out of watching people return from inductions holding almost nothing, and never quite knowing whether they'd been distracted, missed something obvious, or simply hadn't been taught well in the first place. The exercise gave the uncertainty somewhere to land. You cannot politely zone out of a factory tour if you know you'll be asked, at the end of it, for three facts that actually impressed you. Listening turned into work. It was about to be marked.

It worked for a graduate and a senior developer equally well, not because the task was easy but because it was generic enough to meet each of them where they stood. A graduate gave you a plain summary. A senior developer gave you something with more edges. Both were demonstrating the same three things underneath the different vocabulary: humble enough to actually listen, hungry enough to engage with material that wasn't glamorous, smart enough to synthesise it into something worth saying.

The second plan was for a systems role, dropped into the middle of a major ERP implementation, and it's the plan that opened this piece. Same philosophy, an almost entirely different shape. Six weeks through every department, customer service, planning, production, shipping, finance, IT, maintenance, an actual tour of an actual operation rather than a diagram of one. The technical lead and I kept the IS and integrations sessions on days one and two, gave the barest overview of the systems they'd actually been hired to work on, and then deliberately stepped back and let the business do the rest of the teaching. The business need shapes the technology. It has never once worked the other way round, whatever the org chart implies. By the end of month one they had gone out to the business themselves, documented what concerned them, and drawn process flow diagrams mapping what we'd built onto how the business actually ran, diagrams that surfaced gaps in our own understanding as readily as theirs. That's what good onboarding produces: contribution that arrives already anchored in understanding, rather than execution waiting to find out later what it was for.

The contrast is the point, not the inconsistency. A technology team needs technical and cultural immersion built into its bones from month one. A systems role dropped into an ERP implementation needs the business taught to it before the systems make any sense at all. There is no universal onboarding plan, only the same demand asked twice and answered twice in whatever shape it needs: work out what this specific person has to understand before anything they do will actually matter.

The Job Before the Job

There's a version of onboarding that happens before anyone accepts a job at all. It taught me more about the whole philosophy than anything that came after it, and it's worth examining on its own.

For production roles, we ran paid work trials, two days, starting at six in the morning, actual shift time rather than a softened approximation of it. Coffee and a light breakfast waiting when people arrived, a brief company overview, a factory tour, and then two days rotating across different machines alongside operatives we'd deliberately chosen for being good communicators rather than simply available. This happened before any offer of employment existed. It was a trial in the fullest sense. We were assessing fit. So, unmistakably, were they.

Early attrition on that cohort was remarkably low, and not because the job had become easier or the pay had improved. People knew, with total precision, what they were signing up for, because we hadn't simulated the job for them; we'd simply shown them the actual thing. The ones who turned up at six and stayed engaged through two full days had self-selected in before we'd spent a penny training them. The ones who didn't turn up, or turned up and quietly checked out, saved everyone six weeks. They just didn't have to pay for it.

Six in the morning wasn't incidental. It was the entire test disguised as a scheduling decision. If you cannot make it to a factory floor at six, you cannot do this job, and it's considerably kinder to discover that during a paid trial than three weeks into employment, once you've burned political capital with a team that has already rearranged itself around you. The coffee and the breakfast weren't incidental either, and this is the detail I've come to think mattered more than almost anything else in the whole exercise. Turning up at six is hard. Turning up at six to somewhere unfamiliar, for a trial rather than a job, is harder still, and a flask of coffee and something to eat says, without anyone having to say it aloud, that we thought about what this morning would actually feel like for you. It's a small gesture doing an enormous amount of work, cheaper than almost anything else in the recruitment budget and more persuasive than most of it.

This reframes what onboarding is actually for. It isn't only the business of getting someone up to speed once they've joined. It's creating the conditions in which the right people can see themselves succeeding before they've committed to anything, and the work trial isn't separate from onboarding. It's the first layer of it, arriving before the paperwork does.

What the Exercises Actually Test

The exercise model was the piece that did the real work, and its power sat almost entirely in its specificity. Nobody was asked to send over a summary of what they'd learned, that particular request lets people off far too easily, producing something broad and safe that demonstrates nothing. Summarise the brand in three sentences. Bring back the three most impressive facts about the factory. Name the biggest challenge and recommend something that might help it. A specific request forces precision in a way a vague one never will. It tests whether someone actually absorbed the detail, whether they can decide what matters enough to keep, whether they can turn information into something someone else could act on. That's the whole test.

It also hands you diagnostic information you'd otherwise have no way of getting. If someone comes back from a factory tour and can't produce three facts that impressed them, something has gone wrong somewhere, and it's worth finding out whether the fault sits with their attention, the tour itself, or whoever was meant to be explaining it. The exercise doesn't just test the new hire. It tests the onboarding.

We got the calibration wrong at least once, in a way worth admitting rather than glossing over. A developer, several weeks into a diet of business tours, arrived thoroughly demotivated and wanting nothing more than to get stuck into actual code. That wasn't them being difficult. It was a signal we were slow to read correctly. For developers especially, a commit in the first week matters more than any amount of context, it establishes the habit, signals real contribution, and starts building belonging in a way that a well-run factory tour, however impressive, simply cannot. The business context still matters. It just needs to arrive alongside the satisfaction of doing the thing they were actually hired to do, not instead of it.

The Slow Leak

We had an analyst once whose induction was spread, through nobody's actual decision, across two months. Nobody planned it that way. It was simply poor planning, the kind that accumulates through nobody's fault in particular, a session postponed here, a department too busy to host a tour there, until the gaps between introductions grew wider than the introductions themselves. Sessions that should have happened in week one landed in week eight, and for the entire stretch between them they felt permanently and visibly new, the person who still didn't quite know where anything was three weeks after everyone had stopped expecting to have to tell them. Relationships didn't form quickly enough, because nobody had bridged the gap deliberately, and by the time the induction was technically complete, the team had moved on without them and they spent most of their time here quietly catching up to a target that kept shifting. They left before the year was out. That's on us, not on them. Onboarding is our responsibility, never the new hire's, however tempting it is to describe someone as not having settled in, as though settling in were a task they'd simply failed to complete alone.

What happened to them is what happens, in smaller doses, whenever onboarding is left to assemble itself. A laptop that isn't ready and accounts that aren't provisioned on day one say, more clearly than any welcome email could, that we weren't quite expecting you.

Show a new hire to a desk and leave them to introduce themselves, and you'll usually find everyone else defaults, entirely reasonably, to waiting for the new person to speak first. Six weeks in, they still can't tell you what half the team actually does. Tell them simply to have a look around and ask if they have questions, and a senior hire used to finding their own way treats that as freedom. Almost everyone else finds it close to paralysing.

Give someone work without ever telling them why it matters, and the work still gets done. Competently, even. But mechanically, with no ownership and no real sense of what it touches. And if nobody checks in, because everyone assumes the new person is fine since they haven't asked for help, the new person doesn't ask precisely because they don't want to look as though they need it. The gap opens quietly in both directions at once, and nobody notices until it has become the entire shape of someone's first months.

None of this is complicated, and that's rather the uncomfortable part. The starting notes document. The exercise at the end of every induction. The paid trial that starts at six in the morning with coffee already on. The six-week tour through a business before anyone touches its systems. Every one of these is doing the same job. Orientation before productivity, understanding before contribution, in whatever shape a given role actually needs. Most onboarding fails for a subtler reason than indifference, most organisations plainly do care. What's missing is design: an assumption that culture will transmit itself, relationships will form without anyone building the bridge, and context will simply become clear given enough time.

It doesn't. Culture only ever moves through the systems you deliberately build to carry it, and an onboarding plan is one of the more visible ones you'll ever design. I still think about that first afternoon, the starting notes document sitting between us on the table, six weeks of someone else's business laid out in front of a person who hadn't yet earned an opinion about any of it. Get that part right, and almost everything that follows gets easier. Get it wrong, and you spend the next six months finding out exactly how expensive that mistake was, in a currency nobody put on the budget.