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.
Code Ownership
The apparent benefits of individual code ownership
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:
- System components have clearly identified owners (or “experts”).
- The code is maintained and there is someone to fix bugs and collect and selectively implement feature requests.
- Owned code is often believed to be better written (as it’s maintained and refactored by experts), better quality (owners fix more bugs), and better supported and documented.
- Owned code is commonly assumed to provide better return on investment, as it is maintained, supported, and used for a much longer period of time.
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:
- There is not just one designated expert to answer our questions, implement missing features, or fix bugs.
- There is often no one to impose consistency, even at a granular level, within a single component. Code is likely to age faster.
- There is a lot more opportunity for people to bring up new frameworks or components (that often overlap and compete with existing ones) without providing adequate support and maintenance.
The hidden costs of code ownership
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:
- The ideas of the expert are no longer challenged. The gap in knowledge and “expertise” only grows with time, and the title and position of “expert” can be used unfairly to win arguments.
- Innovation can be crippled, as new ideas are expected to come from the individuals who are least likely to generate truly new ideas (because they’re so deeply involved in and biased by the details of the current design and implementation), and these individuals are given implicit or explicit authority to dwarf disruptive ideas from the outside.
- The official role and recognition of “code experts” implicitly dampen and narrow the creative contribution of new engineers. It is easier and more natural for them to just follow the lead of the “experts” instead of diving in and forming their own opinions and ideas. Over time, this may result in a “lean back” syndrome, where people feel they should care only about their own narrow piece of the puzzle.
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:
- The expert inexorably drifts from a creative owner to the comfort zone of expert caretaker. Knowledge of the code and how to use it becomes more important than new ideas to improve it, or reinvent it. A belief in the value of stability leads to ignoring fundamental gaps in favor of fixing bugs or implementing minor enhancements to extend the code lifespan, while dwarfing real innovation. The expert is literally encouraged to create and think less and less in favor of just helping people with basics, answering questions, and doing easy maintenance.
- As the expert becomes “indispensable,” he or she gets praised and treated well without having to take much risk. At a personal level, this comfort and security can often result in apathy, lack of personal growth, lower motivation, and a fundamental lack of significant impact.
- Worst case, a person in this situation can end up thinking of his- or herself as someone who can only contribute as a deep and narrow expert, who will usually only change companies to go do something similar for a competitor (themselves thrilled to have stolen an “expert”). Even if they feel they need changes, letting go of the security and easy recognition of their area of expertise is a scary decision to make.
Individual impact: shrinking short-term impact opportunities
From the above, individual code ownership clearly dampens people’s long-term impact. It also affects their short-term impact, for the following reasons:
- Impact results primarily from our ability to focus on the right opportunity. * In this context, “focus” implies a narrowly and precisely defined project scope to generate as much impact as is practical, with as little effort as possible, as quickly as possible. Such narrow focus is not natural for a code owner, who is usually biased toward “long-term value,” proactive maintenance, polishing, and other deep engineering instincts that compromise impact.
- The “right opportunity” implies that a broad set of opportunities is considered. Being an expert in a narrow field increases your ability to contribute quickly, but it cripples the breadth of opportunities you’re likely to consider. Even if you’re aware of higher impact opportunities outside of your area of immediate expertise, the very fact they would require more research, ramp-up, and learning will likely bias your choice toward an opportunity within your “owned code,” even if absolute impact is lower.
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.
