Skip to content
Founders’ price Launch pricing for your first twelve months. 40 Playbooks, 40% discount for Founders. View the playbooks →

A new starter joined on Monday and I haven't onboarded them.

By , Editor · · What’s Next

01Position

“A new starter joined on Monday and I haven't onboarded them.”

The feelingNegligent.

A new starter joined on Monday and I haven't onboarded them. A leadership Playbook film: where you stand, the Play to choose, the tools in sequence, and the leaders who made the same call. Captions available.

If that’s where you are right now, this is the Playbook built for exactly that moment.

“New starter” is one of 40+ What’s Next? Playbooks, for leaders facing a specific, real situation. In under fifteen minutes it helps you recognise what’s actually going on, then gives you a clear way through: the Play to choose, the Plan in concrete moves, the Precedents of people who faced it before, and your next move.

Frameworks you’ll see put to work on this exact decision, applied, not taught in the abstract:

  • Empathy Maps
  • Walking Skeleton
  • Agile Team Onion

You’ll also see how it played out in the real world, Naomi Gleit at Facebook, Palo Alto (2005), and Sheryl Sandberg at Facebook, Palo Alto (2008). Real precedents, not platitudes.

It leaves you with one question to carry into your next conversation: “What will your new starter tell their friend on Friday about what this team is actually like - and will”

Part of the Team & People collection, Playbooks for when you inherit a team, morale drops, or you have to handle conflict and feedback. See them all ›

Transcript — read it in full

What to do when a new starter joined and you haven't onboarded them

July two thousand and five. Naomi Gleit walks into Facebook's Palo Alto office on her twenty-first birthday. She is the company's twenty-ninth employee.

There is no induction programme. No assigned mentor. No first-week plan. No HR person to walk her through the building. The company has been open for eighteen months and has spent that time turning a campus-only social network into something the rest of the internet now reads about every other week. Onboarding has not been on the priority list.

Gleit had written her undergraduate thesis on Facebook the year before. She had pursued the company until they hired her as a marketing associate.

So what she does on her first day is sit down at an unassigned desk and begin working out, in real time, what she is supposed to do.

The interesting decision is the one she makes some years later, from the other side of the same problem. The growth team she joins, and eventually leads, is responsible for Facebook user activation. The question they keep returning to is not how to market to new users. It is how to make sure a new account becomes an active, returning account rather than an abandoned one.

The answer becomes the canonical activation metric in the growth-team discipline that follows. A new user who connects to seven friends within ten days will overwhelmingly stick around. Below that threshold, new accounts mostly do not.

The metric is not cosmetic. It is the structural signal Facebook's growth organisation builds around for the decade that follows.

When a new starter joined on Monday and you haven't onboarded them, the ordinary question is how to onboard this particular person. The more useful question is what the absence of an onboarding process is costing, at scale, across everyone who will join after them. Gleit's first day at Facebook had no onboarding. The organisation she helped build invented the metric that would tell every future new starter whether the onboarding they were getting was working.

So let's go to the office and work through it.

Read what the missing onboarding is actually costing

"A new starter joined on Monday and I haven't onboarded them."

The feeling is negligent.

A capable adult is sitting at a new desk waiting to be told what the place is, and the person who was supposed to tell them has spent the morning answering emails about something else.

Two choices. They look identical the moment the new starter sits down. They need different first moves.

When they need ownership of their own first week

Choice one: this person needs ownership. They are a capable adult and they will resent being processed through a standard onboarding template that wasn't built for them. The schedule somebody else builds for them is the schedule they will follow ungenerously. The schedule they build for themselves is the one they will own.

If that's the read, hand them a blank document and give them thirty minutes to draft their own ideal first week. Not as a test. As a serious question. The behavioural economist Dan Ariely calls this the IKEA Effect — people place disproportionate value on things they have had a hand in building. The drafting itself teaches them more about the shape of the team than any induction pack can.

When they need exposure to what no one wrote down

Choice two: this person needs exposure. Most of the useful knowledge about the way this company works is undocumented. A formal onboarding programme would skip past it because no one can think how to write it down.

If that's the read, assign them to shadow the most opinionated, eccentric veteran in the building for a day. Not someone tidy or presentable. Someone who will tell them what the documentation does not. The sociologist Harry Collins has done much of the substantive work on tacit knowledge — the kinds of knowledge nobody can think how to write down, because the writing-down loses what made them useful, and the difference between a new starter who understands the place and one who doesn't is almost entirely in there.

Ownership, or exposure. The same first conversation. Two different first moves.

How to give them the lay of the land first

Three tools. The discipline is to build their map of the place before you build their task list.

Show them which conversations they are inside

The first is

Agile Team Onion.

Allan Kelly wrote about the Agile Team Onion across his consulting work and his blog through the late two-thousands and early twenty-tens, drawing on long-running Agile-community thinking about team boundaries.

The reason the tool exists is that most teams oscillate between two failures of communication. Over-communication — everyone copied on everything, exhausting the people who are supposed to be doing the work. And under-communication — decisions land on stakeholders three layers out who didn't know the work was happening, and now have to be unwound. Both failures come from the same root: the team has not codified who needs to be how close.

The unique insight is that not everyone needs the same depth of information or frequency of contact. Once that is drawn on a board, the team stops trying to give them all the same thing. Concentric circles, drawn deliberately. The diagram is not a stakeholder map. It is a communication map.

What you get is a new starter who knows, in the first week, which conversations they are inside, which they are outside, and which they are meant to be hearing about second-hand. That knowledge takes most new starters three months to acquire by guessing. Fifteen minutes with a properly-drawn Onion short-circuits most of the guessing.

So. How to draw it.

Frame. Name the work the team is doing and the boundary of what counts as the team. The boundary is the first hard question; do not skip it.

Centre. The delivery team. The people doing the work day-in.

Rings. Immediate collaborators — the people whose work the team's work depends on. Then wider organisation — informed, not steering. Then external — partners, customers, regulators.

Cadence. A communication frequency for each ring. Daily for the centre, weekly for the immediate, monthly for the wider, quarterly or by-event for the external. Lock the cadence; the rings drift outward without it.

Hand the Onion to your new starter on day one. Tell them which ring they are joining. The shape of the place falls into place around that.

Hand them a shared picture of the user in half an hour

The second is

Empathy Map.

Dave Gray formalised the Empathy Map at the consultancy XPLANE in the late two-thousands, and codified it in his twenty-ten book Gamestorming, written with James Macanufo and Sunni Brown.

The reason the tool exists is that teams talk about the user as if everyone shared a picture of who that is. They don't. Each person on the team carries a slightly different mental model. Design decisions get made from those mental models, and when the decisions disagree it surfaces as the team disagreeing rather than as the underlying pictures disagreeing. The Empathy Map is the artefact that pulls the pictures into one place.

The unique insight is the gap between what users say and what users think. Public articulation rarely matches internal experience. The space between those two quadrants is where the most valuable design insight lives, and it is invisible until you draw the quadrants and see them next to each other on a board.

What you get is a shared specific picture, grounded in research rather than assumption. For a new starter, an existing Empathy Map is the half-hour version of the two weeks it would otherwise take them to absorb who the user is from product documentation.

So. How to fill it.

Setup. Pick a specific user segment, not a composite. Heavy users in the financial-services vertical is workable; the user is not. Composites destroy the gap between Says and Thinks before you have started.

Fill. Says, Thinks, Does, Feels — each populated from research, not from the team's intuition. Pains and gains optional, depending on the depth of the research.

Gap. Where Says and Thinks diverge, that is the insight. The team that has been arguing about the user usually finds the argument was about a gap they hadn't surfaced.

For your new starter, hand them the existing map. Tell them which segment it represents. Tell them what the gap is. They will read it in fifteen minutes; they would otherwise have invented it in two months.

Give them an anchor the detail can attach to

The third is

Walking Skeleton.

Alistair Cockburn introduced the Walking Skeleton in the late nineteen-nineties, in his writing on lightweight software methodologies and the team-scale work that followed it.

The reason the tool exists is that engineers building distributed systems tend to build each component in isolation and schedule integration for later. Each piece works in its own test environment. Nobody has tested whether the pieces can actually talk to each other end to end. Integration problems don't surface until the team is months into parallel development, and by that point they are an order of magnitude more expensive to fix.

The unique insight is that a tiny end-to-end implementation — the thinnest possible version of the whole system that still runs — exposes architectural risk early. Not a prototype. Not a demo. A working frame, exercising every component, returning hard-coded data if it has to, but actually wired up.

The transferable parallel is the United States Marines' Commander's Intent doctrine. The Marines learned in the twentieth century that detailed tactical plans don't survive contact with reality, and troops left without instructions in a collapsing plan freeze. Their fix was to require every mission briefing to end with a plain-language statement of the desired end-state and why it matters, distinct from the tactical steps that might change in the field. Both the Walking Skeleton and Commander's Intent set the thing that must hold apart from the things that can flex. The Skeleton transfers the architecture; Commander's Intent transfers the intent. The team flexes the rest.

What you get for your new starter is an anchor. They can attach the detail to it as they encounter it. Without the Skeleton, the detail arrives in arbitrary order from conversations and documents and Slack threads, and they spend three months reconstructing a frame the team could have given them on day one.

So. How to build it.

Map. Identify the components. The list is whatever the system actually has — services, databases, queues, the front end, the third parties.

Pick. The smallest possible feature that exercises every component. A request that goes in the front, hits every service, and comes out the back, returning something that demonstrates the path completed.

Wire. Each component talking to its neighbours, even returning hard-coded data. The point is not the data. It is the integration.

Run. End to end. Repeatedly. The Skeleton is the thing the team builds features on top of, not the thing they build alongside.

For your new starter, walk them through the Skeleton in their first week. Tell them which component does what, and where the architecture has chosen to bend. Then their feature work has somewhere to attach.

A precedent: when the senior hire onboards by listening first

That's the toolkit. One more story before we close.

The Gleit story we opened with is what happens when the new starter walks into a company too small to have any onboarding system at all, and ends up — eventually — building the metric that signals whether onboarding is working for everyone who arrives after her.

The story we close with is what happens when the new starter is so senior that the conventional move would be to onboard her by handing her the org chart and getting out of her way.

Twenty-fourth of March two thousand and eight. Sheryl Sandberg walks into Facebook's Palo Alto offices as the company's new Chief Operating Officer. She is thirty-eight, has run Google's Global Online Sales and Operations team for six and a half years, and has been recruited by a twenty-three-year-old chief executive whose direct reports until recently were his Harvard roommates.

Mark Zuckerberg has been courting her across six weeks of dinners. The pitch is that Facebook needs the operational discipline Sandberg has built at Google applied to its nearly-maturing business. The unstated half of the pitch is that Sandberg will need to absorb the culture Zuckerberg has built with his founding team before imposing any of the discipline.

She arrives knowing both halves and with no induction programme waiting.

Her first decision, sustained across her opening months, is not to act. She sets up one-on-one meetings with senior people across the company and asks each of them a variation of the same question: what is working, what is not, and what do you want the new coo to touch and not touch. She does not bring a pre-formed organisational design. She does not propose a first-hundred-days agenda.

When she eventually begins rolling out business structures — a proper sales organisation, performance management, a monthly metrics review — it is into a company where she has first invited the existing leadership to explain the culture in their own voice.

The structural move is not the discipline she rolls out. It is the listening she does before sending it.

So.

The deeper point: treat the absence as material, not deficit

Two new starters at Facebook, three years apart. The twenty-one-year-old marketing associate with no onboarding because the company hadn't built one yet. The thirty-eight-year-old chief operating officer with no onboarding because the company assumed she didn't need one.

Both refused to treat the absence as a deficit. Both treated it as material.

Gleit eventually built the system the company had been getting away without. Sandberg rode the absence deliberately — for her role, the absence was the onboarding, because a senior hire's first months are the only time their listening isn't read as a verdict.

When you walk in tomorrow morning to a new starter you haven't onboarded, the question isn't what template to grab off the shelf. It's what the absence is teaching you about what onboarding here ought to be.

So. Your Next Move from this playbook.

What will your new starter tell their friend on Friday about what this team is actually like — and will it match the onboarding document you gave them on Monday?

What’s inside All 40 Playbooks
  1. Position

    The situation in a sentence, and the feeling underneath it. Free to read.

  2. A choice of two Plays

    Two behavioural Plays. Each positions you differently for the next conversation. You choose.

  3. A Plan of tools

    Tools from the Toolbox, in order, each ending in Your Next Move — one concrete instruction.

  4. Precedents

    Leaders who stood here. We show whose play worked, half-worked, and shouldn’t have been attempted.

“The list was never the hard part. Standing behind the cut, in the next three conversations, is.”

The close

Sources & further reading 3 Positions, 4 Plays, 3 Plans, and 2 Precedents.

Your Next Move

Questions, answered

How does a Playbook work?

A Playbook names your Position, hands you two Plays to choose between, then turns your choice into a Plan — a sequence of tools, each ending with a single concrete move. It closes on Your Next Move: the one thing to do before the day ends.

How long is a Playbook?

About twelve minutes. Short enough to watch in the gap before the meeting it’s made for.

What’s the difference between this and asking AI?

A chatbot gives you an answer. A Playbook gives you a Position, a chosen Play, a Plan, and Precedent — the structure of a decision, not a paragraph of advice. You open the situation you’re in rather than describing it from scratch.

Do I need to watch them in order?

No. Each Playbook stands alone. You open the one that matches the situation in front of you — there’s no sequence to follow and nothing to complete first.

What is Your Next Move?

The single concrete move you leave with — a question to take back into the room and answer there. Every tool in a Plan ends with one. It’s the answer to the question the brand name asks.

Next on the shelf

Your next playbook
Share this Playbook ->