I used to be the trainer for an organization. When someone new joined, I’d take them one by one through the steps, through the workflows, and through the basics of how Asana worked. It was thorough, but it was a time sink — for me and for them.
I’d have to find time on my calendar. They’d have to wait until I was available. And in the meantime, they were sitting there with nothing to do but read documentation or sit in meetings they didn’t have context for yet.
So I changed the approach.
Why generic training doesn’t stick
Most onboarding flows start the same way: point a new hire at the platform’s academy courses — Asana Academy, for instance — and say, “Go through these.”
Those courses are well-made. They teach the tool. But they use generic examples that have nothing to do with how the organization’s system actually works. A new person finishes every module and still doesn’t know:
-
What the actual project structure looks like
-
Which workflows matter for their role
-
How the team communicates about work in context
They learned the mechanics. They didn’t learn the system.
The fix: a simple 2-step flow
Here’s what I started doing instead. I built the onboarding around two core pieces — see the system, then own the work from day one — and I made it self-service. The results were immediate.
Step 1: See the system
Instead of walking each new person through the workflows myself, I recorded a series of short videos. Not generic training — screen recordings that showed the team’s actual projects, the actual task templates, and how a piece of work moved from start to finish in the actual Asana setup. When someone was onboarded, they watched those videos. They could pause the video and take the steps mentioned at any point.
This saved me time as the trainer — I made the videos once and moved on. If they had questions, I was always there to answer. But just as importantly, it saved them time. They didn’t have to wait until I was available to meet. They could start their onboarding within their first few days or their first week — when they had less work and plenty of time to watch the videos and get set up. Instead of sitting idle, they were learning at their own pace, on their own schedule.
Step 2: Own the work from day one
Here’s the part that made the biggest difference: I assigned new hires their own onboarding tasks on day one. Not adding them to an existing shared onboarding project, but creating a separate project just for them. Part of those tasks was watching the videos from Step 1. As they watched, they learned how to complete tasks, make comments, and move work forward — by doing their actual onboarding tasks.
This is where practice and ownership merge into one continuous flow. The onboarding tasks are the practice, and they are real tasks. The new hire practices by owning meaningful (but low-stakes) work from the start.
Why a separate project per person? Because when someone is added to a shared project, they worry about messing something up for someone else. A private onboarding project removes that anxiety. They can explore, make mistakes, and learn without fear.
Plus, different people in different roles may have different onboarding needs. There are basics that are universal, but managers can add role-specific tasks that are unique to that position. A separate project makes that easy to tailor.
The pieces every new hire needs to know
There are a few practical things that make or break this transition. If these are missed, the system won’t stick. I’ll keep it at a guideline level, because the specifics depend on the team, but without these the flow won’t land.
-
Customizing the My Tasks view. Every person works differently. A new hire needs to set up a default view that makes sense for them — what they see first, how they sort, what they prioritize. There may be general recommendations on how to do that, and then the person can adjust as they use it, get more familiar, and see what they need.
-
Getting familiar with the Inbox. This is where updates and comments land. If they don’t get comfortable checking it, they’ll miss context and fall behind.
-
Changing notification settings. Out of the box, most platforms send a lot of notifications. If a new hire doesn’t adjust those settings early, the inbox floods — and they’ll tune everything out, including the things that actually matter. Setting this up in the first few days saves a lot of frustration later.
The onboarding project that ties it all together
Once the videos are done in the two-step flow, the next logical piece is to create an onboarding project. When a new hire joins, a separate project is created just for them. That project becomes their single reference point for everything they need to do — not just getting familiar with the platform, but the real work of getting set up in their role.
Video links can go in task descriptions. All the tasks that need to happen are laid out, with due dates that automate based on when the project is created — first week tasks, second week tasks, first month tasks. The new hire knows exactly what’s expected, when it’s due, and where to find the context they need.
And here’s the best part: it doesn’t matter what work management platform is used. The same process works for any of them. The principles are platform-agnostic.
The real win
The goal isn’t just efficiency. It’s comfort.
Within the first week, a new person gets a taste of how things operate and how the platform works. They’ve seen the system and started owning real work — in a safe, structured environment. So when they get their first real project assignment, they’re not starting from scratch. They already know where things live, how to move work forward, and who to ask if they get stuck.
They feel productive. The rest of the team isn’t fielding basic questions for weeks on end. And the person who set up the system gets to spend time on higher-value work instead of running the same training session over and over.
This is one of those areas where a little structure upfront saves a lot of time and energy on the back end. If this kind of intentional onboarding flow sounds like something that could help a team, I’d be happy to talk about it.
Read the full article on Substack →
From the SmartWork Bulletin