Remote Onboarding Software Engineers at Product Hunt
I'm often asked about the Product Hunt onboarding process for remote engineers. I even talked about it on the Scaling Software teams podcast.
For context, Product Hunt is currently around 20 people. We are remote from day one.
I became head of engineering about two years ago.
During this time, we've hired five engineers who have passed through variations of this onboarding process. For a couple of them, this was their first remote job. For one, it was even his first full-time job.
All of our engineers are full-stack.
The onboarding process has two goals:
- Teach the the company's core values.
- Master the core mechanics of the day-to-day work.
The onboarding buddy
To everyone being onboarded, we assign an onboarding buddy.
Currently, this is always me, but this will change as we grow.
The onboarding buddy gives the new hire appropriate tasks to learn our tools and processes. They should be available to help with any questions or issues the new hire might have.
One of our core values is constant system improvement. We use onboarding as an opportunity to improve the system. Questions and suggestions coming from the new hire are essential. We've made a lot of improvements based on those.
The following is the checklist for an onboarding buddy:
## Tasks for onboarding buddy
* setup GSuite account (link)
* use Pre-2-factor organization unit, when the hire has set up their two factor, move to our primary unit
* add to dev group in GSuite (link)
* invite to Quip (link)
* share onboarding docs to new hire (link)
* ask for birthday and store in team calendar as a recurring event - "Birthday ? [name] ?" (link)
* store start date as a recurring event - "PH Anniversary ?[name] ([start year])" (link)
* give read/write/share access to the team calendar (link)
* invite to Slack (add to the @developers group) (links)
* make them admin in Product Hunt and Your Stack (links)
* post about the new hire in `#general` Slack channel (template)
* schedule daily 30 min calls with the hire
* follow the onboarding guide (link)
* give access to accounts (links)
* ... a long list of accounts for external systems
The "(link)" is a direct link to the web forms to create the needed accounts.
We use a lot of checklists and templates in the process. (Over time, those will become automated scripts)
Daily meetings
For the first couple of weeks, the onboarding buddy and the hire have daily ~30 minutes meetings to sync up.
Those are like combined one-on-one and daily standups.
We don't do daily standups in Product Hunt, because everyone is in different timezones and we rarely have more than one engineer working on the same project.
When the hire is comfortable, those meetings switch to twice a week, then become weekly. Usually, by the second month, there is no need for this meeting anymore.
First meeting & the "Welcome" presentation
History is important. It is beneficial to know our historical context. I have found out that stories are the best way to showcase the company culture.
Because of this, the onboarding buddy shares with the hire a "History of Product Hunt" presentation.
The presentation explains how Product Hunt works, our revenue streams, how we got where we are, and some cool war stories (my favorite part of the presentation).
This presentation is updated for every new hire since new things happen between hires.
During this first meeting, there is a walk-through of the onboarding and development processes, technical architecture, and systems. Useful links and documents are shared with the new hire.
Onboarding for hire
The onboarding tasks are split by milestones - day 1, 2, 3, week 1, 2, 3. Usually, onboarding takes around six weeks.
Tasks are picked so that the new hire gets to work in various parts of our systems.
First day - commit and open pull-request
Every change in Product Hunt goes through a pull-request review process.
The usual first feature is "Add yourself to the team in our about page". This helps them feel like part of the team.
We haven't automated this via the admin UI, because it's a useful first task. ?
For new hires to be able to do this, they have to set up their development environments and various system accounts. We have a list with all accounts the hire has to set up with direct links to setup forms. For the dev environment, we have a boot script, which should install everything.
Of course, this script breaks from time to time. When this happens, fixing it is the first contribution of the new hire. ?
Second day - merge, deploy and review pull-requests
Deploying the changes to production shows how our whole pipeline work.
We are an intentionally small team, and everyone can review every pull-request. It is essential to get into a habit for this.
New hires should start to review pull-requests from day two.
Even if they don't have the context, the pull-request description and code should be self-explanatory. By asking questions, new hires help us improve them. The hire is encouraged to ask questions when they don't understand something.
There is nothing better than a beginner's mind asking questions.
Asking questions when you don't fully understand something is a behavior that should be nourished from day one.
First week - demo for a user-facing feature in our Monday all-hands meeting
We are a company with a very low number of meetings. Usually, most engineers have around two meetings per week: an optional project-specific one and our Monday all-hands.
During Monday, all-hands meeting is where new hires are introduced to the whole company.
We have a couple of fun rituals around introducing new hires. Like doing a round table of everyone in the company presenting themselves with a new product they recently found.
Demos are an essential part of Product Hunt culture.
The features the new hire works on in their first week, are always user-facing demoable ones. They are smaller, isolated, and don't require in-depth system knowledge. They always provide real value.
The goal for a new hire is to start to produce user value in week one and demo it.
A couple of times, people start mid-week, so in their first all-hands meeting, when they are introduced, they also do a demo. This is a great introduction. ?
Second week - create/extract something reusable
As mentioned earlier, one of our core values is a systematic improvement.
The new hire should extract something which other team members can use by week two. It can be as simple as a function. It can be a combination of something we already have.
We encourage our engineering team to think about how to build reusable components and functionality. When people think about making something reusable, they make it more decoupled.
Third week - remove something legacy
We are a startup, we experiment, iterate, and remove what doesn't bring value.
We need to have reusable tools, so it easier to build new experimental features. Our systems need to be decoupled, so it is easy to remove the elements.
Nothing in our system is sacred.
The third week is showing this to the new hire. They have to remove something we don't need anymore.
By the fifth week - engineering team call and pairing
Every month the whole engineering team has a meeting where we sync up.
One of the things we do this meeting is to schedule a remote pairing session between team members.
Everyone on the team does at least one pairing session with someone on the team once a month.
We use remote pairing as a way for team members to socialize and learn together.
By their fifth week, the new hire should have paired with someone else on the team, other than the onboarding buddy. This is important, because, in their early weeks, the new hire communicates mostly with their onboarding buddy.
By the sixth week
By the end of the onboarding, the new hires should have implemented all of the following things:
* tests
* Ruby unit test
* Ruby end-to-end test
* TypeScript unit test
* GraphQL
* mutation
* resolver
* field, type
* React component
* hook
* css
* svg
* full-page end to end
* complex form
* database change
* fix a runtime exception
* fix a bug
* Sidekiq background job
* Periscope chart
* document something
* admin related feature
* worked with Invision
* suggest process change
* shadow a community team member
Those are mechanical steps that encapsulate the day-to-day work an engineer on the team does.
Conclusion
This process works well for us. We are continually adjusting and evolving it.
Even writing this blog post made me clarify some of our onboarding documentation.
It is crucial for the new hire to produce value quickly and to feel like they're part of the company.
If you have any questions or comments, you can ping me on Twitter.