If you want your new engineers to hit the ground running, give them a soft landing

Greg Slovacek

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.

  1. avatarMarius Janusaitis

    Greg, well written – thank you for sharing. Internal documentation and knowledge base is implemented on Ansana or smth else?

    1. avatarGreg Slovacek Asana Team Member

      We write most of our documentation in markdown, and have our own simple ruby-based server that serves up pages, creates a table of contents, hyperlinks, embedded diagrams, etc.

      1. avatarDwayne

        Hi Greg,
        Thanks for this article. Great recommendations. With this same theme in mind, I’m looking to not only better support new engineers, but also reinforce ongoing support to my entire team with better ways of creating and publishing technical documentation. I’ve been researching markdown and some approaches for my dev team (small: 7 devs). Would you be willing to share more details/recommendations of your ruby setup that processes your markdown content into published html?

  2. avatarManish

    Thanks Greg!

    Also, I would like to know what Asana do for interview process in any upcoming blog, if possible. kind questions asked, what they looking for technical as well as attitude-wise.

    Thanks again for this article

  3. avatarjwjb

    Really loved this article explaining the onboarding process for new employees at Asana.

    I have been looking for an online project management solution for the last few years and although Asana falls short of many desktop applications I have used, its ease of use and ability to get up and running by just watching a few minutes of your excellent training videos far outweigh these perceived slights.

    Although I have just started using Asana actively for the past few days I was able to understand and organize a billing project better in these last few days using Asana then I have been able to with these other tools over the last few weeks since the set-up time using Asana is so friction-less and a no-brainer without all the overhead and expenditure of time and energy of some of the other products I have used require to just input all the project data.

    Kudos to Asana which is a great tool and it indeed is refreshing to hear of a company positively focusing on their employees from the get-go and throughout their tenure without the sink or swim ethos so common in other companies.

  4. Pingback: A stand up benefit. $10,000 to pimp your desk from @asana « 9 INCH MARKETING

  5. avatarmax hodges

    I see that Asana is mostly about to-do lists. But is there some feature, like in basecamp, for just having a conversation or passing information to someone without it being a task?

    for example I may want to share some training information with my team, inform them about a new company policy, or get their input when deciding priority of a project.

    I guess we should just use email for that instead? But since I’m new to Asana, I just wanted to ask in case there is some feature I’m not aware of yet.

    Cheers
    Max

  6. avatarJason McHugh

    Hey Greg. Nice post – I enjoyed reading it. It is great that Asana can provide this level of structure and support for your new hires. :)

    Jason

  7. avatarLe Passineau

    I�d should verify with you here. Which is not something I often do! I take pleasure in reading a publish that may make individuals think. Also, thanks for allowing me to comment!

  8. avatarAshely Heverley

    An fascinating dialogue is value comment. I feel that it is best to write extra on this matter, it won’t be a taboo topic however usually individuals are not sufficient to talk on such topics. To the next. Cheers

  9. avatarGeraldo Freytas

    A formidable share, I simply given this onto a colleague who was doing a bit evaluation on this. And he in actual fact purchased me breakfast as a result of I discovered it for him.. smile. So let me reword that: Thnx for the deal with! However yeah Thnkx for spending the time to debate this, I really feel strongly about it and love studying extra on this topic. If doable, as you change into experience, would you thoughts updating your weblog with extra particulars? It’s extremely useful for me. Large thumb up for this weblog put up!

  10. avatarphentermine

    weight loss you’re not suffering, generally there isn’t any drama which comes with going on a diet. You’re not depriving, don’t have any tension or perhaps urges. You may think the only real disadvantage would be that the amount of time it requires – gradually is the approach to take. Slower improvement will result in here good results.

  11. avatarJesse Smith

    Great writeup Greg. You briefly mentioned pair programming, but I don’t get the feeling it’s a main tenant of your process. My team does frequent pair programming and it seems to me that it would help you meet your goal of having a new hire “ship on the first day.” With pairing, they can ship a feature that is actually in the backlog, not just something they knew they could do on day one :).

    Thanks for the article!

Leave a comment