I started my software development career at 14 years old, after taking over the Apple IIc that my older brother bought for himself. After 11 years as a hacker building demos and games, I turned “professional” by joining a very informal and innovative startup. Until that point, the satisfaction of solving technical challenges and getting my code working (and performing well) and the “glory” of sharing it with others is what motivated me. But an unexpected turn toward leadership and management made me realize that helping organize and mentor groups of individuals so they can maximize their ability to solve bigger problems was an even more interesting task.
People management proved to be quite a challenge by itself, one that has required constant learning and personal introspection. At the very end of 2011, Facebook offered me an opportunity to leave management behind (after 14+ years) and focus on technical leadership, without disconnecting from my passion for personal development, team dynamics, and mentorship.
Facebook’s engineering culture is unique, and after mentoring peers and doing some introspection, I came to realize that many of the culture's strengths and challenges have common origins, simply observed from different angles. I discovered that the very existence of some of these challenges are rooted in the most critical choices we made to build our strengths. Articulating some of these subtle linkages has proven helpful in guiding people in mentoring sessions and understanding how to thrive as an individual and a company.
It seemed worth trying to share this limited “wisdom” in a form that could be more broadly accessed by people outside of Facebook. It reflects only my personal experience, opinions, and understanding of other people’s experiences. You will likely have some very different opinions, and you will certainly have had a different experience. Mine are no better than yours, and my hope is that sharing them will inspire you to think through some of this in ways you haven't before.
Many software development companies believe in and practice “individual code ownership.” This may not sound like such a fundamental principle, but it actually goes a long way toward defining how a software organization works. At first glance, individual code ownership appears to have some nice benefits:
At Facebook, we don’t believe in or practice individual code ownership – pretty much the exact opposite. This can be a shift for many engineers joining Facebook with prior industry experience because:
Despite the benefits of individual code ownership, I believe that eschewing it is one of the most important choices Facebook ever made. Two key values of our engineering culture are our focus on impact and our commitment to growth, both as individuals and a company. Both are in deep contradiction with individual code ownership, at least as I know it from other companies.
Let’s look at how individual code ownership can negatively impact both a company and its employees.Company impact: stifling debate and crippling innovation
The culture of the “code expert” results in a world of sclerosis and stagnation where really bad things can occur. Here are just two examples:
Some organizations attempt to solve these issues by putting different people in charge of generating disruptive ideas (like architects or product managers), while component experts are in charge of the implementation. This only displaces the bottleneck of innovation and formalizes it further, with even worse results if both parties don’t work well together.Company impact: reduced ability to adapt to disruptions
The stagnation driven by individual code ownership is often part of similar broader cultural challenges that can literally kill companies.
Two of my previous employers were once innovative (and/or lucky), and had large successes. In both cases, the engineering and product organizations turned themselves into organizations whose primary role and purpose was to maintain, support, and only incrementally improve the phenomenal success they inherited. Individual code ownership thrived. People only wanted to solve new problems by incrementally evolving the successful solutions of the past, making any disruptive innovation extremely difficult.
If people still used the products these companies created (in this case, WAP browsers and PDAs), the companies might still be doing quite well today. But obviously both of these markets were disrupted and these organizations were unable to reinvent themselves to adapt to or even grow from these market disruptions. In both cases, a small minority within the companies tried to drive disruptive innovation, but failed.Individual impact: stunting individual growth
While initially a new owner of a specialized area will grow and learn to his or her personal benefit, this won’t last. Here are just a few of the reasons why:
From the above, individual code ownership clearly dampens people’s long-term impact. It also affects their short-term impact, for the following reasons:
Individual code-ownership provides some attractive benefits at first glance: better designed, maintained, and supported code, and longer life-span for components and services. Unfortunately, it does it at the cost of introducing rigid definition of roles, which can limit innovation and company and individual growth.