Design system: How to efficiently scale development?
Learn how to get the most with limited resources in large organisations
While in the first two articles of the series I’ve covered how to build an engineering team and how to build a library the next challenge for the team is to figure out how to efficiently scale design system development?
Building software for your own team can be fairly easy. Once you start collaborating with another team you start bumping into the first challenges. Eventually when you have to serve tens of teams in the organization things can become hectic unless you have a good process in place to efficiently scale and organize your work.
Your team is a bottleneck
Being a platform team comes with a huge burden — eventually, the team can become a bottleneck for product teams' development. It becomes hard to impossible to execute every incoming external request in a timely manner. Tradeoffs have to be made as well as rigorous prioritization has to be put in place. However, by organizing smartly you can minimize these risks
Building communication channels
A regular check-in with external teams is a powerful communication method that allows prioritizing your team’s work more effectively
Sync and async channels — you can either use messaging tools (async) or real-time meetings (sync) but it would be best if you’ve done both. Async channels are better for discussion but sync wins when decisions have to be made. Create a slack channel (async) and organize at least bi-weekly 30-minute meetings (sync)
Gather the requirements — help teams develop a habit to look at least a couple of iterations into the future. This makes it possible to identify new library features or modifications to existing ones that the team will need
Pool the requirements — you might learn that multiple teams are in the need of the same thing, hence it might make more sense to prioritize the certain type of work that will have the biggest impact on multiple teams
Be transparent — share with everyone what makes certain items of a higher priority
Gather feedback — it is also very important to continuously improve the work you do and the best way to do so is by gathering frequent feedback. Formalize a process and a format in which the team’s representative can share feedback. Evaluate every possible aspect of a team’s performance — code quality, work prioritization, communication skills, responsiveness, etc…
Adopt InnerSourcing
Once the adoption of the design system library grows within the company it is very likely that your team will become a bottleneck. While hiring more people to your team could be the answer to this problem — it might not always be a feasible option. Instead, you should consider adopting innersourcing methodologies.
InnerSource is a software development strategy that applies open source best practices to proprietary code
Rather than reinventing the wheel use what’s already well-known for the majority of software engineers — the open-source model. Apply the same methods that many big open source projects successfully use.
Encourage external contributions to your team’s codebase by providing full support — find a time to pair on more complex features or at least discuss in advance different approaches, onboard first time contributors, write up contribution guides
Automate as much as possible — code style checks, automated testing pipelines, tracking performance metrics, automatically generate documentation —basically minimize the number of extra work contributors needs to do
Enforce strict code review process — while automation should reduce the load on the team significantly you should not fully rely on it, make sure team members review every single contribution as if it was their own. After all at the end of the day ownership of the library still belongs to the design system team
Prioritize external contributions — in order to keep other people motivated to contribute to your codebase keep the turnaround time low. Prioritize code reviews, provide actionable feedback, if necessary pair with people until completion
Focus on long-term vision and strategy — once you have a good process going on allow your team to invest more in research and development. Design system library is a living creature that needs to evolve and get better over time
You can also read in detail about innersourcing on GitHub or GitLab.
What are the benefits of innersourcing?
Increased collaboration and knowledge sharing — the design system library’s codebase should no longer be a black box, everyone should be able to contribute. Writing code for the library will also teach people how to use it better at the same time it creates an opportunity to gather ideas for further improvements
Significantly increased throughput — the number of changes that can be released should no longer be bound to your team’s resources only
Overall satisfaction — external teams should no longer be upset about things that aren’t a high priority as they can implement them themselves and unblock any work
Higher-quality code and process—it is easier to look after the work when you are dealing with a small group of people, however, once you start adding more and more contributors you must continuously improve (otherwise problems may start accumulating) ways how you deal with various situations in your work process which naturally leads to a higher-quality code and the more efficient process overall.
Final thoughts
Alleviate the pressure on your design system engineering team by allowing you to “outsource” a big chunk of the work to other teams in your organization. Let your team worry about the infrastructure of the library and focus on a long term vision and strategy for it