If you had visited Airbnb’s office yesterday you probably would have noticed something: clapping. I’m not sure why, but sometimes a team will applaud a small victory, then more people will start clapping, then suddenly the entire product and engineering area is a din of applause and cheers. Most people don’t know why they’re clapping, they just want to show support and have fun.
Maybe that’s what good culture is about. Defaulting to an attitude of support and celebrating others’ successes. Every company has some kind of culture. Some maintain it with meticulous attention, others just let it happen and hope for the best. Either way one fact remains: good culture creates an environment where people can do their best work, bad culture is soul-destroying.
I’ve been at Airbnb for a little over a year now. Previously I’ve been an engineer and manager at many companies including Facebook and Yahoo. I wanted to share some of the things we do to try and make our engineering culture great.
Engineers own their impact
At the core our philosophy is this: engineers own their own impact. Each engineer is individually responsible for creating as much value for our users and for the company as possible.
We hire primarily for problem-solving. When you have a team of strong problem-solvers, the most efficient way to move the company forward is to leave decision-making up to individual engineers. Our culture, tools, and processes all revolve around giving individual contributors accurate and timely information that they can use to make great decisions. This helps us iterate, experiment, and learn faster.
Making this environment possible requires a few things. Engineers are involved in goal-setting, planning and brainstorming for all projects, and they have the freedom to select which projects they work on. They also have the flexibility to balance long and short term work, creating business impact while managing technical debt. Does this mean engineers just do whatever they want? No. They work to define and prioritize impactful work with the rest of their team including product managers, designers, data scientists and others.
Just as importantly, engineers have transparent access to information. We default to information sharing. The more information engineers have, the more autonomously they can work. Everything is shared unless there’s an explicit reason not to (which is rare). That includes access to the analytics data warehouse, weekly project updates, CEO staff meeting notes, and a lot more.
This environment can be scary, especially for new engineers. No one is going to tell you exactly how to have impact. That’s why one of our values is that helping others takes priority. In our team, no one is ever too busy to help. In particular, our new grad hires are paired with a team that can help them find leveraged problems. Whether it’s a technical question or a strategic one, engineers always prioritize helping each other first.
Structured teams, fluid responsibilities
Being able to decide what’s impactful is possible with a clear company strategy to guide the decision-making process. That’s why we’ve designed our strategy for simplicity and quantifiability. It’s simple enough to fit on a single page and every employee at Airbnb knows how their function relates to the big picture. Knowing what your team’s goal is helps you decide how to use your time, which minimizes time-wasting debates about the existential stuff. And because each of our major goals has a numeric target, we can measure the effectiveness of various projects, learning quickly from our successes and failures.
Our team structure also maps to our company strategy: we work in tight working groups of generally 10 people or less with efficient lines of communication. Teams are primarily comprised of engineers, product managers, designers, and data scientists, and some teams partner with other departments within the company. There is strong collaboration between functions. Payments includes people from finance, Internal Tools includes people from customer experience. It’s common for engineers and designers pair up and figure out how to make something work in realtime. The best ideas come from close collaboration.
This year, we have ten teams focused on product development and four teams focused on technical infrastructure. Each team is concerned with a specific aspect of Airbnb as a business, and defines its own subgoals and projects on a quarterly basis, using the overall company strategy as a compass.
Although each team owns non-overlapping pieces of the business, collaborating across teams is common and encouraged. For instance, we have discrete Host and Guest teams, since we tend to think of hosts and guests as separate user demographics, each with their own set of needs. But since the interactions between hosts and guests are what make Airbnb special, these teams contribute to their counterparts’ roadmaps, share goals, and partner up on projects, while retaining enough separation to build specific expertise about their constituents’ use cases and needs. Fostering collaboration across teams helps us cover gaps.
It’s common for engineers to switch teams or contribute to areas beyond the scope of their immediate team. For example, it’s routine for a product-focused team to contribute to improving our infrastructure in the workflow of their projects. Engineers have freedom to change teams when the work in another group more closely aligns with their interests and ability to drive impact. In fact, it is encouraged. Managers can facilitate this process, but it’s up to the individual to find the team where he or she can have the greatest impact and initiate a move.
Cultural standards in the development process
The development process at Airbnb is flexible by design. We don’t want to build in different directions, but we also don’t want to be so standardized that we miss out on better tools and methodologies when they emerge. We believe in shaping good judgment in individuals instead of imposing rules across the team.
When our process changes it happens organically from within the team. Code reviews are an old but a good example of this. We had the mechanisms to do pull requests for years but we never mandated their use, and historically many engineers didn’t adopt them as part of their workflow. In fact, in the early days it was common practice to merge your own changes directly to master and deploy the site. This is kind of like juggling chainsaws blindfolded — looks cool when you pull it off, but eventually you’re going to lose a finger.
At some point a few motivated engineers started highlighting great code reviews at our weekly engineering all-hands meetings. They’d highlight some of the most helpful or thoughtful code reviews they had seen over the week. Soon more engineers started adopting pull requests and a tipping point was reached where it became strange if you didn’t ask for code review. Now it is just how we do development.
At the same time, this cultural shift was mirrored by advances in our tooling. A small team of engineers took it upon themselves to build out our continuous integration infrastructure, enabling the engineering team to run the entire test suite in minutes anytime they checked in a branch. Lowering the barriers to good behavior with tooling catalyzed the team’s cultural change.
This is one example, but there are countless others including how we adopted our project management tools and bug tracker. When we discover a better way of doing things we facilitate awareness of the idea then let it stand on its own merit until it catches on (or doesn’t). This way teams have a lot of flexibility with how they accomplish their work and we create opportunity for new good ideas to emerge.
Any engineer can contribute to any part of the codebase. All repositories are open to all engineers. This is possible because of our culture of automated testing, our code reviews, and our ability to detect anomalies in production through detailed monitoring. The standard etiquette here is borrowed from the open source world: someone from the team that maintains the codebase you’re touching should review your changes before you merge.
This model makes it easier for engineers to unblock themselves. Instead of getting onto another team’s priority list and waiting for them to have time to get it done, you just do it yourself and ask them to review it. That code review happens quickly because, again, helping others takes priority.
Once code is merged engineers deploy their own changes. In a given day, we’ll deploy the site 10 times or more. Our build-and-test process takes under 10 minutes to run and we can complete a full production deploy in about 8 minutes. Because it’s so fast, we ask engineers to deploy their changes as soon as they’re merged. Smaller change sets to production mean less chance for conflict and easier debugging when something goes wrong. It’s common etiquette to be present in our engineering chatroom as you deploy your changes. Our bot announces when the deploy starts and completes and the engineer announces they have verified their changes in production. During this time the engineer is also responsible for watching the metrics to make sure nothing bad happens.
Of course, bad things do happen sometimes. In these cases we may rollback the site, or fix and roll forward. When things are fixed, engineers work with the site reliability team to write a blameless post-mortem. We keep all post-mortems in an incident reporter tool that we developed internally. Post-mortems heavily inform proactive work we do to make infrastructure more reliable.
Career advancement, tracks, and impact
Another one of our beliefs is that engineers can progress just as far as individual contributors as they can as managers. There are two tracks by which engineers can progress in their careers: management and individual contribution. The pay scales are parallel, so there’s no compensation advantage for getting into engineering management at Airbnb.
In fact, becoming a manager isn’t about getting promoted; it’s about changing the focus of your work. Managers are facilitators. They exist to get obstacles out of engineers’ way. That can be career obstacles, prioritization, or technical help; pretty much anything. Their primary responsibility is to support the people around them.
We also value technical strength in our managers. Each manager is involved in dozens of technical decisions a week. Without a strong technical background, their influence in that process can lead to poor results. For this reason, all managers start as individual contributors. They can transition into management when they’re familiar with the code and development practices and, more importantly, when it feels like a natural move. We don’t airdrop managers.
An individual contributor’s primary responsibility is technical execution that drives impact to the business. They are responsible for finding and doing high impact work. In that process another value is to leave it better than you found it. Every project should improve our technical foundation. That responsibility falls to individual contributors and this means that engineers are driving technical decisions and holding each other to high standards of technical work. It also means that engineers negotiate feature trade-offs and deadlines to make sure enough time is given to do quality engineering.
Another way that we help engineers progress is by helping them build their individual profiles outside the company. We do this through blog posts on our nerds blog and through open source. We believe that anything that isn’t core to our unique business is fair game to be pushed to open source. We always want to be contributing useful technology back to the community. We encourage it as a way to help increase awareness around the engineering work we’re doing and to showcase some of the best work by our engineers.
Summing up
Right now, we are still establishing the foundation and practices that will carry us forward over the next several years. Things that seem like trivial decisions today will be amplified 10x down the road when we’re a much bigger team. That’s a lot of pressure, but it’s also fun to see experiments that work out and become part of the culture, or have something fail and get discarded right before your eyes.
Not fucking up the culture is paramount. When you’re growing quickly, it’s important to keep the environment creative and fun. Our engineering team meets every Friday for an hour of technical presentations, animated GIFs, applause, appreciation and cheers. We do multi-day hackathons twice a year that are each worthy of their own posts. I meet with small groups of engineers every week just to ask questions and listen to ideas on how we can improve. We have a nerd cave where engineers can hang out and listen to records while they work. We could probably do an entire post on how we stay connected and have fun as a team but I’ll save that for another day.
What makes Airbnb special is that our culture connects engineers to the company mission and to each other more strongly than anyplace else I’ve seen. Engineers own their impact here, prioritize helping others, default to sharing information, and continually leave the code better than they found it. Our culture empowers engineers to do their best work, and helps them get excited to come to work every day.
Check out all of our open source projects over at airbnb.io and follow us on Twitter
Originally published at nerds.airbnb.com on June 5, 2014.
