Culture! Ship it! Go!
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. Folks varied in level from Intern to Senior Tech Lead and were ready to see what Drift was all about.
Before I jump into methods, let’s talk about outcomes.
Possibility #1: the worst outcome would be a group of overwhelmed programmers wholly dependent on others for instruction. They won’t be able to connect their day-to-day work with the company's success if they don’t know their role in their team. Worse yet, they could start down the path of failure, guided only by their ego.
Possibility #2: the best outcome would be individuals who start with a sense of purpose. With access to support, a mission, and a growth mindset, they will experience success and understand their role in the success of those around them. They have the will and skill to GSD™!
Robust Purpose vs. Adaptive Execution
With those outcomes in mind, you could take an immersive approach and drop someone directly into the work. Try pairing them up with an accomplished engineer and having them pair up on a problem. Chances are, they’ll learn your system and how this engineer executes their work. However, this is like learning how to ride a bicycle by changing the tires. Your new hire will miss the forest for the trees and fail to internalize the big picture.
You could also take a highly structured approach where you get 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 execute. You’re investing in a team that waits for their next instruction.
You want to design a program that balances the two. Today, new hires meet in the morning for a couple of hours to learn about the company (history, positioning, goals, teams, metrics, investors, and the product).
In the afternoons, we dive into engineering work.
While we are driven by frugality and scrappiness here, we have unbelievably talented people. I can 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 in onboarding engineers.
Thank you, Kari!
“The goal is to feel so comfortable in the role that you go on autopilot.“ — Aaron Beverly, on developing skills.
Engineering Autopilot
“The goal is to feel so comfortable in the role that you go on autopilot.” Aaron Beverly finished 2nd in the 2016 World Championship of Public Speaking. “There is no substitute for experience,” he says, about building up the skills to accomplish a task.
Our engineering onboarding produces self-regulating teams, which create valuable engineering work. The many dimensions of the role are framed in different ways to reinforce a customer-centered, learning-oriented, and risk-tolerant thinking pattern.
1. Success Paths / Failure Paths
One fantastic exercise is a discussion about success and failure. Together, we develop a picture of the habits and priorities of what a successful engineer at Drift looks like.
We develop these two lists in real time as a group.
I pull from the unique experiences of each engineer in the room to answer the question, “What does good look like?” As I go, I interpret the behaviors in (mis-)alignment with Drift’s values. Notably, explaining WHY and HOW these behaviors play into one’s success at Drift is essential.
We also fill out “failing” behaviors to further cement the point. These are more-or-less opposites of the success path and don’t align with Drift’s values.
This is also an excellent moment for healthy debate. Like Patrick Lencioni says, “Be aggressively authentic” in your values-creation. At Drift, our values (see Drift Leadership Principles) must not be generic, consensus-driven, or common sense. They were designed to help people make decisions independently and with conviction.
2. The no-op Deploy
If onboarding is a rocket ship, the no-op deployment is the ignition. Up to this point, there’s been a lot of talk and account setup & access, so this is important. This is our day one 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
In this segment, new engineering hires are introduced to the concept of a center as a point from which an activity or process is focused. We discuss the many “centers” (self-centered, team-centered, or financially-centered).
Eventually, we get to customer-centered.
At Drift, we are customer-centered. For engineers, this means we orient our product work around the success of our customers.
My goal is that new folks internalize these principles. I’m careful to reference customer-centricity (and other values) as we develop our first features.
4. Pairing
By now, new hires have enough lay of the land to create something valuable for Drift’s customers. We pair them up with a senior engineer (regardless of their previous title or experience). Pairing sets the expectation that collaboration and visible work are how you succeed at Drift. We also want to discourage people from closing themselves off. A new job can be intimidating and overstimulating, so we keep close tabs on new hires to ensure they have fun and are learning.
5. The First Ship™
This is a big deal. It’s our big focus for the next two days, and they need to complete it 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 and share with the group — when pairs receive the work, they are given 10 minutes 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. We do that if we stay after hours or come in extra early. High-performing organizations must model responsibility and complete ownership over their work. It teaches the lesson of right-sized scoping and overcommitment, and HOW to maintain work-life balance responsibly.
6. “Graduation”
When The First Ship™ lands in #shipyard (our slack channel for customer-facing releases), it celebrates a job well done. Our guardrail “do visible work” bears fruit here. After all, only work that has been designed, written, peer-reviewed, validated, and deployed can appear in #shipyard. If the success metric is “posts in #shipyard,” leadership may assume that the engineering feature pipeline is healthy.
Posting in #shipyard is also their final task as the onboarding class. The following day, they join their teams.
A #shipyard post consists of 1) how the feature impacts customers and 2) visible evidence.
The product, engineering, and other teams typically celebrate with comments, questions, and many, many emoji reactions.
7. Post-graduate work (for me)
While Kari surveys the individuals to collect feedback on their overall experience, I survey the teams receiving new hires. The product managers, the tech leads, and anyone who is assigned as a guide or mentor receive these questions:
I owe the Senior Leadership Team and L&D 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 notes are broken into four columns: Good / Bad / Do More / Do Less. These are my observations and messages based on feedback I collect from others during the process. Based on these notes, I also include planned iterations on this document.
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 this.
🤷♂️ What’s it like to work at Drift? 🤷♀️
Hang With me!
That’s all for now. I hope you learned something; please 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-performing 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
