Hey Reader,

The other week I was talking with a new Product Owner on the team. Well, not necessarly new, since it's been a while she joined the team. But we discussed her experience onboarding to the team.

And as often happens, it was a difficult journey.

I remember joining many new companies and teams, and I would usually have to figure everything out on my own. Somehow, the onboarding process was not very well defined anywhere I've been.

When you get started everything is new, and it would be great just to have a checklist of what you need to do and what you need to learn. Especially, the company terminology because it gets frustrating quickly when everybody keeps saying things like EIP, BBT, Phoenix, etc. as if those words mean something...

I thought that it is such an important part of any team, that it's weird it's not taken a bit more seriously. So I embarked on a journey of defining a good onboarding process for the team. Any team.

So let me cover several key sections that I think any onboarding process should have. But first, let me address the subject line of this email where I mention the "buddy system".

I remember this was a quite popular way of onboarding people where someone from the team is assigned to be the newcomers buddy who will explain everything, and walk them through the main processes, make sure they have needed access to tools, introduce them to people.

All that is actually great and I definitely recommend having something like this. This basically allows the new person to have a friend at work immediately, even before any relationship-building starts. But that cannot be your only way of onboarding. Especially if your "buddy" doesn't have a checklist of their own to follow.

One person may turn out to be a great buddy and think about everything. Another one may get busy and forget about some important steps to take. So make sure if you do have a buddy system, you also have an onboarding checklist for them to follow.

Ok, let' get back into some key topics that should be covered during onboarding.

How to Scrum

Of course, if the team is using Scrum, or any other specific process, be it Kanban, SAFe, Disciplined Agile, or whatnot, then you need to have some good educational materials on it.

And I don't mean: "Hey, we use Scrum. If you don't know what it is, go to scrumguides.com to read about it"

I mean an actual overview that walks someone new over the key elements of the process. Especially, if you don't have a dedicated person who can do a workshop or training on a regular basis for newcomers. (if you don't do it, I think you should start)

Once again, it can't be just a copy-paste of whatever official guide exists because it's too decoupled from reality, from their work. You need to make it immediately applicable to their day-to-day.

For example, if you are

Meeting the teams

The next important section in your onboarding process is the people-oriented one.

When it comes to the team itself, you should provide information about:

• who is on the team
• what kind of knowledge each of the team members has
• what are the questions you can come to them with

And also encourage the new person to go and meet each team member one-on-one in their first week.

Then you may want to direct them to other important people in your organization. It may be a team lead of another team your team works a lot with. It may be a designer who jumps into some of your meetings. It may be a DevOps Coach who builds the continuous delivery model.

Make sure they know who the players are!

Your tools and access

This one may seem straightforward... but I've seen it sooooooooo many times that someone new can't access some essential systems they need even months after joining.

So make a list of every single solution and tool your team uses. Even if it is seldom used. Then write up who the owners of those systems and access to them are.

This should go on your onboarding checklist for the new person. This can be something along the lines of: "We use Jira for task management. Link: <link>. If you don't have access, please contact systemowner@email.com"

This ensures that you don't forget any important tools, and it also puts this task into the hands of the newcomer.

Your documentation

Obviously, if you have well-organized documentation, this has to be on your onboarding checklist highlighting the first and most important pages. If you don't have it... well, you know what you need to do now.

Now, you need to do this right! Often teams just give the new person the link to their whole wiki and send them to "read-up" what's there. This is an insurmountable task! You need to break it down.

Think about what parts of the wiki are the absolute must-read and list direct links to those pages on the checklist. The person will dive into other topics when necessary. Don't overwhelm them with information they won't need. They already have lots to learn!

And here I want to highlight one important wiki page that you definitely should have... the acronyms and abbreviations. This is really essential! It can help you cut the time the new person needs to be fully operational. Otherwise, they'll be attending meetings with little understanding of what the heck everyone's talking about. Even simple things like team names need to be on this list.

Anything product dev-specific

This would be something defined by the developers on the team (if you have a software product, of course). Often this is the ONLY onboarding checklist or process that exists.

Make sure it doesn't take over all of the time for the newcomer and they also work on other tasks that I mentioned above. Understanding the technical side of the product is required, yes. But it's not the only thing they need to know.

​

Anyway, I think this is everything that I had to talk about today.

If onboarding is something that you would want to learn more about, let me know. I'm working on some page templates that can definitely become a comprehensive guide.

​

In case you missed recent publications and podcast episodes:

📈 Technical debt for non-techies with examples ​Watch the video →​

🎨 What do developers want from Scrum Masters??? ​Find out the secret →​

📘 The Agile Audit Podcast Episode 4 ​Listen to the insights →​