Onboarding Is an Experience, Not a Document: Deciding Sticks Better Than Reading

In the last post, I looked at why onboarding matters in projects from a PM's point of view. The conclusion went like this: goals, scope, decision makers and change processes can be handed over in documents, but how to judge the situations you keep running into doesn't travel well on paper.

This post picks up the next question. So what does good onboarding look like?

Plenty of onboarding material, and people still get lost

A lot of onboarding looks the same. A few wiki links, a company intro deck, some process docs and a friendly "Ask me anything." The First Run site lists four reasons this kind of onboarding often fails:

Problem	What happens
Repeated explanations	The team explains the same company and project context to every newcomer
Documents that go unread	There's plenty of material, but it's hard to finish or remember
Slow ramp-up	Until people face real situations, they don't know how to act
Role-specific standards	Developers, PMOs, planners, designers and publishers each need different things

The one I think sits underneath the others is the third. Even people who have read every document get stuck, because knowing a rule and recognizing the moment it applies are different skills.

Say the onboarding doc reads: "Scope changes must come in as change requests." Everyone nods. But the real moment doesn't arrive wearing a "change request" label. It arrives on a Friday afternoon two days before launch, when a friendly client contact messages you: "Could you just tweak this one line of copy?" Recognizing that message as a change request is not a skill you get from reading the doc one more time.

Four conditions of good onboarding

So where does that instinct come from? I think good onboarding needs four things.

1. You make decisions in situations that resemble real work

This matters most. It means changing the basic unit of onboarding from a document to read to a situation to judge. A situation has context, it has options, and each choice has consequences.

I went through the same thing studying for the PMP. Most PMP questions don't test facts directly. They describe a project situation and ask what the PM should do first. As I wrote in Part 1 of my PMP review, when I memorized answer sentences, I got the question wrong again as soon as a few words changed. So in my error log I stopped copying questions and started collecting judgment rules: "If ___, first ___." Onboarding works the same way, I think. What should stick isn't a list of rules. It's judgment in context.

2. Each role has its own path

A developer and a designer can join the same project and face completely different situations in week one. The developer has to make calls on API errors and debugging, the planner on conflicting requirements, the designer on design system rules and usability reviews. Onboarding that shows everyone the same slides fits nobody.

That doesn't mean you only need to know your own role, though. Projects run on collaboration, and conversations get much easier when you understand what keeps the people next to you up at night. A path that starts with your role and then widens to the roles around you is the second condition.

3. You get reasons, not just right or wrong

"Correct" and "Incorrect" don't teach much on their own. At work, choices are rarely simply right or wrong. They're better or riskier. One option is the best move, another is fine but not ideal, and another looks harmless now but carries real risk. That's why feedback needs both a grade and a reason.

Situation — Friday afternoon, two days before launch. The client contact messages you: "Could you change the text on the checkout button? It's a quick one." You're a developer who joined the project this week. What do you do first?

Choice	Grade	Why
Share the request with the PM and let them decide whether it becomes a change request	Excellent	A change right before launch can affect QA, translation and UAT, so the decision belongs to the decision maker
Ask the client about the impact first, then summarize it for the PM	Good	The direction is right, but negotiating on your own before a decision can set expectations
It's small, so fix it now and tell the PM after it's deployed	Risky	Well meant, but it skips the agreed process and adds regression risk right before launch
Say you're busy, suggest Monday, and don't write it down	Poor	The request disappears and comes back after launch as a bigger issue

Compare Risky and Poor. Neither is a good choice, but for different reasons. Risky is the danger that comes from trying too hard. Poor is the problem that comes from letting something slip. Hearing that difference, with the reasoning, is what changes your call the next time a similar situation comes up.

4. There's a safe place to be wrong

Pick the Risky option on a real project and you pay for it after launch. Onboarding is one of the few times you can be wrong without paying that price. For that to work, it has to be clearly OK to get things wrong, and you need a way to go back and try again. Not a test you fail once and move on from, but a practice ground where you see why you missed and take another shot.

Document-based vs. experiential onboarding

Put the four conditions side by side and the difference is clear:

	Document-based onboarding	Experiential onboarding
Basic unit	A document to read	A situation to judge
Path	The same material for everyone	A path per role, widening to other roles later
Feedback	None, or right/wrong	A grade, the reasoning and a learning point
Mistakes	Made for the first time on real work	Made in practice first, then retried
Done when	You've read it all	You can make the call

To be clear, I'm not saying documents are useless. For information you need to look up, like goals, scope and decision makers, documents are the best tool. But onboarding that ends with documents leaves out the hardest part for a new member: the first moment they have to make a call on their own.

That's why I built First Run

When I asked myself what format could hold all four conditions at once, my answer was an RPG. That's why I built First Run. Here's where the four conditions live in it:

• Judgment in context: quests built from real work situations ask what you'd do first. They're judgment questions, not facts to memorize.
• Role-based paths: there are quests and mentor NPCs for five roles (developer, PMO, publisher, planner and designer), and from level 3 you can take on other roles' quests too.
• Feedback with reasons: every answer is graded Excellent, Good, Risky or Poor, with the reasoning and a learning point.
• Safe failure: missed quests can be retried on the Review Board, and at the end a result report lists your strengths, areas to work on and recommended review quests.

All of it can be customized for a company or a project. Quests can be built from your real work scenarios and project rules, with NPCs modeled on your mentors, your office map and your branding. In other words, a scene like the example quest above can be filled with your own team's real situations.

Onboarding documents aren't going anywhere. But where the documents end, the moment a new member first has to decide alone begins. I wanted people to live through that moment safely, before it happens on a real project. That's why I built First Run.

Try it yourself — the demo is free in your browser, with no sign-up, in Korean, English, Japanese and Spanish. Play First Run →

The next post tackles the last question in this series: why a game, of all things, and why play matters at work. I'll look for the answer in Johan Huizinga's Homo Ludens.

Frequently asked questions

Do we still need onboarding documents?+

Yes. For information people need to look up, like goals, scope, decision makers and procedures, documents are the best tool. What documents struggle with is practicing judgment, deciding what to do first in a specific situation, so I think it works best to add experience-based practice on top of them.

How is First Run different from an e-learning quiz?+

Instead of recalling facts, players choose what to do first in realistic work situations. Each answer is graded Excellent, Good, Risky or Poor with the reasoning and a learning point, and missed quests can be retried on the Review Board.

Which roles does First Run cover?+

Five roles: Developer, PMO, Publisher (HTML/CSS), Planner and Designer. From level 3, players can also take other roles’ quests to build cross-role understanding.

Sources

• First Run: Custom Game-Based Onboarding RPG
• PMP Error Log: 6 Steps to Turn Wrong Answers into Judgment Rules