An onboarding experience is an important process that directly shows a new employee how the company functions and impacts how successful a new engineer is. The startup I joined had an onboarding process that wasn’t as terrible as other horror stories about people showing up to work without their equipment ordered. However, I thought the experience wasn’t an excellent experience either, so I set out to make some changes. There were a few rough spots that could be ironed over:
- The welcome on the first day was a bit cold
- A typical engineer spent the majority of their first week to set up their development environment
- There wasn’t a solid onboarding plan to express what the expectations are
“Here’s the kitchen where you can get coffee. The meeting rooms are over there. This is where your team is. There’s your seat and here’s a webpage on what you need to do to get started.” is an okay impression, but not a great experience. It felt like a bare minimum onboarding experience that many companies will give.
Being in an old startup that existed before the influx of new startups, there weren’t benefits such as catered meals. A welcome lunch wasn’t part of the onboarding practice at the company at first. Changing this took a few tries, but it became an event that existing employees liked. Who doesn’t love a free company paid lunch at a restaurant? The benefit of this event is it created an opportunity for employees to talk to each other and to get to know the new employee better. Kick-starting the team bonding right from the beginning.
Welcome E-mail or Slack Message
I remember my first day of work, where I had to repeatedly answer the same questions many times when talking to new coworkers. It was another okay experience, but it wasn’t a great one. To improve upon this, the hiring manager sends out a welcome e-mail or slack message with a picture and short bio of the new employee on the day they start. This message introduces the new employee to the rest of the group along with some information that is commonly asked such as:
- The person’s name
- What team the person is joining
- Where the person came from (university or previous employer)
- Hobbies outside of work
- Other interesting tidbits like a favorite author
Doing the welcome message changes the conversation from “Hey. I haven’t seen you around before. What’s your name? Is today your first day?” into “Hi Jim! Welcome to the team. How’s your first day going?” It gives a nice feeling that people already know there’s a new employee and how they look.
Ever seen a friend’s social media post of their first day at work? Usually, it shows a ton of swag like pens, notebook, coffee mug, water bottle, backpack, t-shirt, or a zipped up hoodie. Welcome swag is considered a nice to have, but it provides the employee with useful accessories, creates a sense of belonging, and gives the company free brand advertisement in return.
One type of welcome swag items that has a high impact are decals, which are a type of sticker that has become popular in recent years. It’s cheap to make, and people love sticking these onto their laptops, their suitcases, and many other places.
The Developer’s Environment
Vanquishing Tribal Knowledge
“You’ll have to talk to Bob who is the expert on setting up Visual Studio for development. Then you’ll have to talk to Jane about setting up your code repo account.”
There was a lot of tribal knowledge that a handful of engineers had, which made it more difficult than necessary for new engineers to get settled in. The bright side was the new person would have face to face time with a bunch of people. I ended up interviewing the various gurus and writing all of the knowledge down into a comprehensive “getting started guide,” which included:
- Team member names and their contact information
- Important e-mail groups and slack channels
- Standard developer equipment
- Where to find important docs such as architecture and coding best practices (i.e., using four spaces or a tab)
- Where to find “how to” guides for setting up various software or doing a particular process
To further build upon this concept, I encouraged the team to have everything important written down because it would become common knowledge accessible to anyone. There wouldn’t be a need to hunt down the expert that knows how to set something up anymore.
An excellent reason for having less tribal knowledge is the “bus factor.” The concept is if a person disappeared tomorrow, what important information or essential ability would be lost. For example, there is only one software engineer who knows the release process. The team would be in a world of hurt if that engineer disappeared the next day.
Bus factor — Wikipedia
The expression “hit by a bus” describes a person either dying or more generally disappearing suddenly from the project…
The first steps done was to document the current developer’s environment with all the steps to install the necessary software and how to create the correct configurations. It was a step in the right direction, but observing this whole process made me realize that it still wasn’t a great experience. Who wants to spend their first-week reading documents to set up their machine and downloading the many gigabytes of the codebase. It’s quite a time sink that is a waste of an engineer’s time.
An improvement is to use a software configuration management tool such as Puppet or Chef. Using this software made the experience much better where a person can just run one terminal command and let scripts setup almost everything. There were still small manual nuances such as usernames and passwords, but it automated the majority of the machine setup process. The next optimization step would be to offload this work to the IT department.
Having an onboarding plan gives new employee guidance on what expectations are. It also helps the department because it’s a written down plan that can be revised and improved for the next new engineer.
- Greeting from hiring manager when the new employee comes in who shows them where they will sit and who their team members are
- Welcome slack message with a picture and short bio
- Getting started guide given to the new employee
- Welcome lunch with the engineering department
- Afternoon check in from the hiring manager to check on progress
- Everything set up and ready to start developing
- The engineer begins on a simple “hello world” style project to learn the codebase
Then what this person should accomplish in week 1, week 2, 30 days, 60 days, and 90 days.
Familiarized with the source code repository layout
Read best practices and code style guidelines
Working knowledge of how to use the product from a user’s perspective
Completed code refactor or technical debt projects
Working knowledge of tech stack and important processes
Able to write code in the project
Always question if there’s a better way to do something. Sometimes it’s the small subtle things like adding a warmer human touch that can make a big difference between a generic and a fantastic experience. Then there are bigger changes like automating an entire mundane process. Someone needs to start the change and that begins with a “can’t this be better?”
Don’t settle for mediocrity