If you want your new engineers to hit the ground running, give them a soft landing
This is the status quo at many a fast-moving startup: new engineers plunge into their positions bracing for a harsh reality. Fresh from an environment in which they were confident in their day-to-day work, they must hope to succeed in spite of gnarly legacy code, inadequate documentation, unintuitive raw tools and processes, and co-workers that help only reluctantly (if at all) because they are too busy. It is an awful first impression.
But paying careful attention to the on-boarding experience pays dividends, and is a key to transforming new engineers into strong, effective contributors. Positive patterns are easier to establish early on, not once the engineer has settled into a routine.
At Asana, we strive to build a culture centered on focus, productivity, growth and development—and that starts on day one, not some unspecified time when you become a “real” employee. We’ve put a lot of thought into our on-boarding process, which we’ll lay out below.
Minimize Chores
The first step is to remove as many rote tasks as possible from the new engineer’s list of responsibilities. We want him or her to focus on being a member of the organization, not on doing chores.
To facilitate this process, we have all of the components of their workstation acquired and set up ahead of time. We give them a $10,000 budget to customize it and then get them what they need before they show up. In the days before their first day of work, we set up their desk, install a standard disk image and run a standard setup script on their machine. All that’s left are the unavoidable personal customizations.
The goal of the whole operation is to ensure that the engineer doesn’t spend most of their first day “setting up their workspace.” We have much bigger plans for them.
My Buddy And Me
Those bigger plans start with a buddy. Each new engineer is paired up with a colleague with at least several months of tenure at Asana. For the next few weeks, this buddy will be be the primary person responsible for the new hire’s experience.
The buddy system provides benefit in two ways:
New hires never have to wonder “who should I ask” and “is it worth taking this person’s time?” When we pair the new engineer with his or her buddy, we clearly communicate that we expect the buddy to spend a significant amount of time and energy on the onboarding process. Meanwhile, we give buddies the leeway they need to reduce their other commitments.
It puts a single Directly Responsible Individual in charge of the new hire’s experience. Because buddies are invested in the process, they notice when the new hire is struggling with a problem. They facilitate discussions with experts on the team. They spend extra time pair-coding. Since someone is tasked with paying attention, it’s much easier to optimize the experience.
The buddy system also creates explicit opportunities for the new engineer to give feedback to the organization. New hires provide unique value: the ability to see the organization without the curse of knowledge. They cycle in new ideas and help prevent institutionalized biases. Valuing a new hire’s opinions early on sets the tone for their future contributions.
Adding Value On Day One
We have a rule at Asana that all new engineers must ship something on their first day. It could be a tiny product improvement, or a fix to a bug or a typo—anything. But it has to get out to production.
This practice is part of a commitment to continuous deployment and is inspired by other companies who have done the same. The rule serves multiple purposes:
Demonstrates the entire lifecycle of a change to the software, from idea to launch.
Provides confidence to the new hire around putting code in front of users. The worst that happens is something actually breaks, the code is quickly reverted, and everything’s okay again.
Re-enforces the culture of continuous deployment within the organization, which has many of its own benefits.
Meet the Tech and the Team
A lot of what we accomplish together is grounded in trust and in our working relationships. Good tools (like Asana) facilitate these relationships, but are not replacements for them. We kickstart our fellow engineers’ effectiveness by seeding their relationships early on.
During the new hire’s first few weeks, the buddy schedules a series of learning sessions on various engineering topics, such as a walkthrough of our codebase, our cluster architecture, our datastore, reactivity, our testing framework, and so on. Each session is a one-on-one with another engineer.
Like many processes at Asana, the functions of these sessions are stacked, yielding many different benefits from one activity:
The session leader and the new hire get one-on-one time to discuss something technical, establishing a relationship.
The session leader gets to exercise being an authority, a component of developing leadership.
The new hire gets high-quality information about a topic highly relevant to their work.
Of course, to scale our knowledge transfer across all employees (not just new hires) we also maintain a solid base of internal documentation. And each new hire is assigned one of the sessions that had inadequate written coverage, and cooperates with the expert to write up what they’ve learned. This process distributes the onerous chore of documentation, and helps us build our knowledge base over time.
The Starter Project
After a new hire has been exposed to an organization’s principles, tools, and and processes, there is often still a sizable gap between learning and synthesis. Many organizations are content to let this gap close incidentally, in fits and starts, wherever the engineer happens to be focusing their attention at the moment. While prioritizing learning based on needs is a passable default, we think introducing some core concepts in a safer environment can be more effective.
To that end, every new hire gets the same starter project: to build a small chat application using Luna, our in-house framework. They are expected to spend about 2-3 days working on it. The project is fairly open-ended, though the engineer is given lots of hints about things they can try building.
We designed the chat project to expose new engineers first-hand to many of the core concepts of building an application on our framework. The project’s open-ended nature allows engineers to direct their own exploration of the system. Since building a chat app on Luna is very similar to the day-to-day work on Asana, the skills the new engineers learn are directly transferrable. However, because the scope is much smaller and the environment more controlled, the engineer can learn the concepts more easily, without distraction.
Great Success
The benefits of our approach are real: our new engineers tell us that they were invigorated by their on-boarding experience, instead of exhausted, and they are excited by how quickly they become productive. Though our on-boarding process requires a lot of upfront energy, we’ve found that it pays to think carefully about how a new engineer is introduced to the organization, and how the experience might shape their mental model of the company.
They are, after all, its future.
