Too often in tech companies, new team members are treated to a fantastic recruiting process only to join a team that lacks any formal process to onboard them. I’m not talking about watching new hire videos or memorizing corporate mission statements here!!
How often do you hear someone proudly self-identify their team/company hiring culture as “Sink-or-Swim?”
Is Sink-or-Swim really a hiring strategy, or a management failure? Sure – I know in college we all had “weed-out” classes. But when your business is investing money in hiring a new team member… shouldn’t we be extremely motivated to help every new teammate swim… not sink?
So... What’s the goal of onboarding? And does Sink-or-Swim help or hurt that goal? Isn't your team's goal to rapidly assimilate someone into their established culture & processes, so they can seamlessly get up to speed and contribute to the mission?
Often times, the most overlooked aspect of an engineer’s success is how they were assimilated to the new culture & processes.
Anyone in business will tell you a customer won’t last long if they are ignored as soon as they sign the deal! Likewise, businesses can’t afford to let new hires waste time getting up to speed. The most overlooked aspect of an engineer’s success is how quickly and effectively they assimilate them to your culture & processes.
The best way I’ve found to onboard new team members? Use onboarding projects that introduce them to the core concepts, foundation operations, and framework of the same product they will work on. In addition to product knowledge, require that they actually use the tools and processes of the team to complete their work. Onboarding should be a guided process aimed to rapidly assimilate someone to established culture & processes.
And isn’t the success of any new hire the end-goal of hiring them in the first place?
Designing the onboarding project itself is much easier than it seems. By having new team members recreate the base logical building blocks of our core app logic, we can assign tangible functionality they can study and build on their own. Writing unit tests solidifies their understanding of the application’s core logic and ensuing complications. The resulting library they created is the foundation upon which they build a POC of the very product team they will join. What could help more than a week or two of guided ramp-up on the product, processes, and culture of your team?
Agree or disagree with my thinking here? Love Sink-Or-Swim tactics? Drop me a note with your thinking!
