As a student going through the cooperative education system at the University of Waterloo, I have the opportunity to start at a new internship every 8 months. This means one thing — a ton of onboarding. I’m definitely not an HR expert, but as I’ve been onboarded four different times at three different companies in the last two years, I have some idea of what makes for a good start at a software company.
At the beginning of September, I started my co-op term as a software engineering intern at this startup going through hypergrowth. What’s hypergrowth? — think, learning to ride a bike by pushing yourself off at the top of a steep hill and figuring it out as you go.
This philosophy makes for a pretty unique first week, and provides a few lessons that I believe can be applied to the onboarding process at any company. Here’s a few things which I think stood out.
Week One Meetings
Every new job starts more or less the same, with a day one Welcome Meeting with HR. You know the one: welcome to the company, what we do, hardware handout — basically a rehashing of what you should already have found out when you researched the company and your position (you did that, right?). After that, the office tour and then the handoff to your team and a goodbye forever from HR. You then normally find yourself reading wiki post after wiki post and watching video after video, personally in charge of your own onboarding.
Things were a bit different this time. After the typical day one meeting, the rest of the day was free to meet your team, get used to the office culture, and push code to production (something I’ll talk about a bit later). The rest of the week was filled with in-person onboarding meetings with all new members of the company, from other interns to directors, covering topics from company culture to software architecture. I’m going to stress the importance of these initial meetings being in person, as it allowed for direct question and response and the ability to grow rapport with everyone being onboarded. For once, I didn’t feel alone or abandoned and I knew exactly who to reach out to with my problems and questions.
Pushing Code on Day One
On my first day, I was paired up with a mentor on my team with the goal of pushing code to Production (and into the hands of millions of users) within hours. Sure, it wasn’t a big change – just adding my name to a project file that can be reached via API call – but there is a lot more going on here than meets the eye. Pushing code on day one forced me to get the environment up and running, my IDE set up, tests executing, and a brief introduction to the build pipeline – a quick and strong start to the week.
Being able to push code on my first day is really a testament to a bunch of things working well: development machines and identities being set up properly by IT, continuous deployment as part of the build pipeline, and the confidence that the new developers won’t break anything – or that if they do, it will be caught by the pipeline (a great way to stress test).
I realize that this sounds difficult, but really, this should a goal for every software company — it’s 2015, the tools exist, it has been done at numerous companies, and has proven to be extremely valuable and not just for onboarding.
Emphasis on Doing
At a startup in hypergrowth, I’ve learned that things change constantly and rapidly. Therefore, there is little sense in constantly updating video playlists or wiki pages to help with onboarding. Instead, start building software – you will learn that way. This is emphasized on day one by shipping to production, through your first week and onward. Just keep pushing. There’s a fairly obvious caveat to this way of doing things: constant guidance is an absolute must. This is why, at Hootsuite, you’re assigned a dedicated training guide, even before your first day.
Paying it Forward
Being in hypergrowth means your company will be hiring, a lot. This in turn means the feedback loop on onboarding is on the scale of days or weeks, instead of months or quarters. This allows for your feedback on onboarding to directly affect the next group of new hires (which for me was the next Monday). The whole week I was asked to fill out quick surveys gauging the quality of each session, how useful I had found it, and any points of improvement I could see.
Constantly being able to adapt and improve is something I believe should be a staple at every company, especially software ones. Hypergrowth or not, the take away is that any member of the organization can make things better for the next cohort by adopting a mindset of continuous improvement: quickly and constantly trying, reflecting, and adapting via experimentation and feedback. Hypergrowth is simply a catalyst that will help you see the results faster.
About the Author
Jacob is a Software Engineering Co-op on the Platform Team at Hootsuite. He is passionate about Hackathons, Full Stack Development, and the Big Picture. Follow Jacob on Medium @jacobw.