A Relaxed Look at Getting Engineers up to Speed in a High Performance Organization
I’m writing this having recently onboarded a dozen new engineers at Drift (a 65% increase in the size of our team!). Folks varied in level from Intern to Senior Tech Lead, and they were ready to see what Drift was all about.
These are my learnings, and you can bet this is a work in progress. Here goes!
Before I jump into methods, let’s talk outcomes.
The worst outcome would be a group of overwhelmed programmers, fully dependent on others for instruction. They wouldn’t know their role in their team or their department, and they wouldn’t be able to connect their day-to-day work with the success of the company. Worse yet, they could start on the path of failure, driven by ego and defensive mindsets.
The best outcome would be a set of individuals with a sense of purpose, the tools they need to be autonomous, and with a learning mindset. They will have experienced success, and understand their role in the success of those around them. They have the will and skill to get shit done!
Do these look good? I think this paints a solid picture of what we want. Now let’s achieve results as quickly as possible, and optimize from there.
Robust Purpose vs. Adaptive Execution
You could take an immersive approach and drop someone directly into the work. Perhaps pair them up with an accomplished engineer, and have them do real work. They’ll learn to adapt within your system, and they’ll learn how to execute. Chances are, your new hire won’t know where the company is going, how it’s going to to get there, and their role in this journey.
You could also take a highly-structured approach where you get a robust training that covers every principle, product, and milestone of the company as it grows into a multi-billion dollar enterprise, and everyone’s role in getting us there. In this case, they’ll have a purpose, but your new hire isn’t going to know how to do their job effectively.
We balance the two. Folks meet in the morning to learn about the company (where we came from, where we’re going, and our product offering). In the afternoons, we dive into engineering work.
While we are driven by frugality and scrappiness here, we have unbelievably talented people. I have the opportunity to partner with Kari Howe (who developed talent at Hulu & Amazon) while she builds out robust company-wide programs. Her work has directly impacted my success onboarding engineers.
Thank you, Kari!
Engineering Autopilot
I came across a quote that perfectly sums up the effect of good onboarding. “The goal is to feel so comfortable in the role that you go on autopilot”. The person quoted is a 2nd place finisher in the 2016 World Champion of Public Speaking. “There is no substitute for experience” he says, about building up the skills to accomplish a task.
“The goal is to feel so comfortable in the role that you go on autopilot.“ — Aaron Beverly, on developing skills
For that reason, our engineering onboarding is primarily composed of shipping engineering work. If you’re not creating muscle memory for the day-to-day work, you’re failing.
1. Success Paths / Failure Paths
After introductions, I lead off with a discussion about what success and failure. Together, we develop a picture of the habits and priorities of what a successful engineer at Drift looks like.
An example outcome of the “Success Paths / Failure Paths” exercise
We develop this list in real time as a group. I’m able to pull from the unique experiences of each engineer in the room, while framing things in a Drifty way. If we don’t complete the picture, I’ll ask some leading questions. I’m also sure to explain WHY each of these is valuable and how they play into one’s success.
To further cement these guardrails for success, we characterize the failure path. These are more-or-less opposites of the success path.
2. The no-op Deploy
If onboarding is a rocket ship, the no-op deploy is the ignition. Up to this point, there’s been a lot of talk, lots of account setup & access, so this is important. This is our day 1 win.
In this step, we get our local dev environments set up (with the help of automated scripting), and spin up a backend service. Each person makes a formatting change and we get to work sending it up the deploy pipeline. From branch to PR, builds, validation, and then we promote to production.
Not only are we isolating their focus (first deploy, then learn our application code), but we’re creating small, almost inevitable, wins early in the process.
3. Customer-centric Engineering
This is a short (15m) chat I give in front of a white board. I introduce them to the concept of a center as a point from which an activity or process is focused.
I explain, the are many centers, and we offer examples of self-centered, team-centered, financially-centered. Eventually we get to customer-centered.
At Drift, we are customer-centered. For engineers, this mean we orient our product work around the success of our customers.
It’s my hope that new folks internalize this principle. I think taking a few minutes to review this ahead of real product work really helps.
4. Pairing
We pair up new hires at this point. Ideally with a senior engineer and a junior engineer. Pairing discourages people from silo’ing off while in a new setting, and it tees up the expectation that they collaborate, and do visible work right out of the gate.
5. The First Ship™
This is a big deal. It’s our big focus for the next 2 days, and they need to complete it in order to “graduate” from onboarding. Here’s the deal:
- It represents customer value — peer-reviewed & validated by PMs/Engineers; Potential work goes into a visible backlog that anyone can contribute to or comment on.
- It’s right-sized — an existing Drift eng. could complete it in a couple of hours.
- Plan in pairs, share with the group — when pairs receive the work, they are given 10m to investigate and plan their solution. We review these aloud, and analyze the solutions as a group. I help them create a validation plan.
- It’s done when it’s done — We do what it takes to get this done. If we stay after hours or come in extra early, we do that. If we need to bleed into Day 4 of onboarding we do that. It’s critical for high-performing organizations to model responsibility and complete ownership over your work.
6. “Graduation”
When that The First Ship™ lands in shipyard, it’s a celebration of a job well done. Like I said, the task should just be a few hours of work, but this assumes much about dev environment, code snags, and a ton of validation and testing. For a brand new hire, these things will take longer, and we account for that.
From here, they join their teams. Ideally, it’s how we wrap up on Wednesday afternoon.
We celebrate wins in the #shipyard. Comments visible from Sales & Product & CS
7. Post-graduate work (for me)
While Kari surveys the individuals to collect feedback on their overall experience. I survey the teams receiving them. The product managers, the tech leads, and anyone who is assigned as a guide or mentor receives these questions:
Stats go into a google sheet. I assigned myself a target of 9.5/10
I owe the team two documents after each onboarding:
- Onboarding Sentiment — A living table of survey results, participants, and composition of the new hires (i.e. — all senior? all interns? mix?) along with action items based on the survey’s qualitative data
- Onboarding Learnings — My own notes broken into four columns: Good / Bad / Do More / Do Less. These are my personal observations and notes based on feedback I collect from others during the process. I include planned iterations on this document as well, based on these notes.
A sample onboarding outline (engineering only)
This puts the learnings and strategies above into practice with a 3-day outline of events (Google Sheets). It’s a rough outline, but it may help folks understand how we executed on this.
Come Hang With me
That’s all for now. I hope you learned something, please do tweet at me, or check back in the article for a quote you like and tweet that (it would warm my cold heart).
Last (and of course) if a high-perf engineering team is your jam, hit us up!
References
The Aaron Beverly quote was found via How to Tell a Story
The “big and robust or small and adaptive?” narrative was inspired by The Critically Important Role of Product Teams in Strategy, Innovation & Org Structure