Onboarding Done Right - Part 1

Seeing many onboarding processes and building many myself (often incomplete and wrong early on) - I've decided to create a small series of essays that will describe areas you should tackle within new teammates onboarding. Onboarding is unique moment in time and critical for understanding the context of the project you're trying to build.

I'm not going to talk about your swag bag, new computers, and intros on team all-hands, etc. I hope we all understand that the main thing in onboarding process is to make your new teammate feel welcome, useful and productive as fast as possible. Usually teams get the "feel welcome" part right but cut corners on things that make becoming "useful and productive" easier and faster.

I initially wanted to focus on onboarding for business focused teammates - like marketing, sales, community, BD - essentially what I call distribution focused side of the house. But I found out early that big picture onboarding is applicable to everyone in early stage company. In early stage projects everyone can and should grasp the whole context of what you're trying to build and why.

Big part of being productive and useful is about being able to make a lot of decisions independently. To make the right decisions you need to understand the vision and context of the project you're building.

So let's put some structure around how to do it effectively.

Read First

First order of business should be to read through a onboarding document someone made for you - usually founder or the person hiring you. When there's no document, that's ok - just browse and read through internal wiki that will have (usually obsolete and incomplete) info on the following important points:

• project vision - what's the guiding light of why you work on things you work on. It is almost always there but sometimes vague, but this part you already heard and that's why you're joining.

• history - how was the idea for the product/service you're building born and what is the vision for the product/service and the problem space you're occupying.

• team members - ideally role description with some personal facts, preferred ways of working, contacts, photo, hobbies.

• tooling - what tools do you use for what purpose, who is admin, how they work together - especially if there's more teams with separate tooling.

• main company & team rituals and ways of working - list of regular meetings, preferred ways of solving problems, escalating issues or reaching decisions.

• business fundamentals - business model, how we make money, positioning, etc.

• product metrics dashboard - or how to access data we track (hopefully you track something)

• business metrics dashboard - or how to get to what we track (hopefully you track something)

• customers - this is usually not gonna be there but should be - who are our buyers and/or users and where do they come from (I could say customer personas but it has such a bad rep of being over-formalized that I won't)

• community - where it lives, how we are interacting with it, what is our vision for those interactions, who's in charge of that.

Ways of Working

Let me talk a bit more about onboarding into the ways of working in the company you joined. There's most likely some separation between product/eng. and distribution side of things (marketing/sales/BD or other teams).

• First order of business is to understand how are product and distribution teams structured today. What org and reporting models exist and how are backlogs for issues and new ideas managed. If there's no backlog for new ideas - create one now!

• Second thing to understand is the working cadence and methodologies team is using. You're looking to understand teams velocities and if they differ among teams then why is that the case.

• This goes together with understanding how meetings are structured, how is meeting preparation done and shared, what's the role of meetings (solution find, decision making, yapping) what are key meetings and get invitations.

• Third point is to understand any established norms for communication, collaboration and documentation of things. Super important! You want to document everything. Early teams often ignore documentation of assumptions and results for most of their experiments, assuming they're saving time - but they're not. Quite the contrary, they're missing a chance to save a lot of time in the future as new people join. If documenting things rigorously is not an established norm yet - try to make it happen now!

• Next look for understanding of how are shared resources used, accessed, updated -> this should usually exist for things like - designs, data, website, blog writing, social media templates, ...

Get To Know Them

After you went through whatever is available in writing, you most likely have ton of questions so the next order of onboarding process should be to meet everyone on the team (if small team), or everyone relevant for your success (if large team). Schedule a short 1:1 with each one of them with the goal to get to know them a bit better and to get your questions answered. You also want to get subjective opinions or views on topics that interest you.

It is very likely that every person will have a little different take on many of the points you read about - from tech stack, product direction to business and customers. Pay attention and ask questions around all things that differ from what you've read/heard so far.

One of the most valuable things every new person brings to the team, apart from obvious additional skills, is a set of fresh eyes that can see stuff you can't see if you're buried in shipping product and solving problems all day every day. Use that set of fresh eyes to question things, to provide your "uninformed" perspective and share experience from other places. In the right team these things can have enormous value.

I will come back to fresh eyes and how to use them in later part of this series.

Conclusion of part 1 of 3

This is it for today. I've glanced over general points that should be included in every onboarding process you create or go through. Next time I will talk about what business points you should include in your onboarding and then we'll look at product related points in the last essay after that.

The point of going over all aspects of your project is that you most likely don't have all of them figured out or documented. And if you have an early hire, then you as a founder need to go and figure these out with your team right there.