Manage episode 233441274 series 1418007
When Facebook was scaling in its early years, the company developed engineering practices that were unlike any other organization before it.
In addition to unique engineering problems, the Facebook product itself was also unique. When a product has as much traction as Facebook did in the early days, how are you supposed to manage the direction of that product?
Should you double down on the core competency of the product, and make it as good as possible at simply connecting friends to each other? Or should you rapidly expand into adjacent systems like messaging, groups, and photos? How should you allocate developer resources when you have problems to be solved at every layer of the stack, from backend infrastructure to frontend performance?
At a typical company, you would put all these engineering problems and product opportunities into some kind of project management software and assign developers to work on them, and gradually make steady, measured progress. The downside of that approach is that it slows down the pace of product creation and experimentation, and turns software development into a top-down, bureaucratic process.
At Facebook, developers self-assembled into teams that did what needed to be done. The engineers who were the most productive and charismatic could quickly build a reputation for themselves and become technical leaders. These “influencer engineers” within Facebook had a proven track record, and would become magnets for other engineers who wanted to contribute to the projects with the most momentum.
Facebook is a case study in the ability for developers to self-organize into groups who are working on projects that are meaningful to the company and personally satisfying to the individual engineers. Many engineers in the software industry work under a less capable manager who has complete control over their creativity. This leads to employee churn, dissatisfaction, and burnout.
Facebook’s ability to move fast is predicated on its ability to match engineers with problems that are interesting to those particular individuals. Whether you want to work on newsfeed or developer productivity tools or machine learning research, there is a path within Facebook to finding a problem that is both important and fun.
Nick Schrock worked at Facebook for eight years. He is best known as a co-creator of GraphQL, a tool for efficiently fetching data through a federated request language. GraphQL was the result of years of evolution of internal tooling within Facebook.
Nick has discussed the creation of GraphQL in other podcasts, and we will have a more dedicated episode around a retrospective of GraphQL in the near future. Today’s episode is about the process by which developers at Facebook self-organized, and Nick’s ideas around how to identify a need for an internal tool.
Since leaving Facebook, Nick has parlayed his experience in developer tools into Dagster, a programming model for data applications.
1020 episodes available. A new episode about every day averaging 59 mins duration .