When I first started managing JavaScript Infrastructure at Facebook back in 2016 I made a huge mistake: I split the team into three groups: One focused on Yarn, the package manager, another on Jest, the testing framework and the last one on Metro, the JavaScript bundler.
This was great in the short-term. I was able to bring people together to make these tools great individually. However, two things started happening:
1: When we were asked to take on additional responsibility, or solve an ambiguous problem, the team tried to fit it neatly into one of those projects. When something related to package management required changing Facebook infra, the team threw their hands in the air and said “Sorry, we can’t build this into Yarn - it’s an open source project!”
2: The people made those open source projects their identity. They would do talks and represent the project on Twitter. They felt heavily invested, and it made it even harder to motivate them to solve problems that Facebook needed to solve internally.
It wasn’t their fault, it was mine. I set up the team that way, and encouraged them to take ownership. Through this experience, I learned that teams have to be structured around the problems they are solving instead: Package Management, Testing, and Bundling – instead of the concrete implementations to solve those problems.
It’s much easier to make a roadmap focused on how to achieve a goal and say “Currently, Jest is the right solution for this problem, but maybe in the next quarter we’ll migrate to something else”. Don’t tie your identity to code and when you set up a team, focus on the solutions to problems.
