Let me count. So there are 9 designers and 7-8-9 engineers. And then we have two folks working on accessibility, design manager and two directors. There are more people working on the docs who are not on the team page.

Back when the design system was just started, I think it was only 2 people. When I joined the company around a year ago, there were about 4-5 developers and 5 designers. So the team scaled almost 2x in the past year.

I think the design team has actually not grown that much overall since some people have also left prior to this year. On the other hand, engineering team was tiny – two people on the Ruby side, two on React side and designers were also writing CSS.

So what has changed? From what I saw, there’s just more adoption and interest in Primer doing more. For example there is one big focus on accessibility and without design systems being accessible, products can be accessible either.

Also when I was still interviewing, they have mentioned that React library was more of an experiment and by the time I was joining the company, the experiment proved to be working. Because of that we started adding more people to the team. At the same time more and more teams at Github are trying out React which helps us justify the investment.

That’s something that has changed a lot in the recent months or the last year. We used to have this luxury of being able to go into the product when you’re shipping a breaking change and fix it yourself. Nowadays we have more products using the system and the overall component inventory has grown so we can’t keep up with the amount of work if we keep the previous approach.

Instead we’re switching our focus towards documentation, tests and working on the feedback we receive from the teams. We also encourage other teams to contribute to the system instead of building everything ourselves.

For example, we’ve released a major version of the library with a few breaking changes so we’ve started thinking about how we can automate the migration months ahead. At the same time we’ve been working with the team so that people can see what’s coming. So that’s different from working on just one-two products. But since I know how those products are working, I still use them for testing the releases.

A lot of times we’re looking for a workaround that would unblock the team. For example if they need a tiny change in a specific part of the card, we can suggest temprorarily moving from the pre-built component to a manual composition of box container and layout utilities.

Thankfully that works in many situations. And then sometimes we might not have a requested component. In those situations we are encouraging teams to build the component themselves and later on we’ll replace it with the component in the system. You’re basically telling the person to do what they feel is right for the component and on our side we’ll already know if the solution works well for the product or has any flaws. This also means they don’t have to go through all of our extensive requirements lists to include a component into the system.

My day-to-day work is changing a lot. I started leaving two of the days to focus on the meetings, which is Monday and Thursday for me. So that’s basically 40% of the time I spend on topics like planning and support, while another 60% is spent on the feature development and bug fixing.

I’m lucky enough not be inbolved in the “spreadsheets” type of work since we have managers and directors handling that. Also because I’m senior, I can still spend 60% of my time on the individual contributions, while if you move towards staff it becomes vice versa with just 40% of the time spent coding.

We have a few staff engineers in our team and I’ve seen people getting promoted to staff design positions in the design system area as well. I find it tricky to be an engineer in the design org though because it changes the people you’re sitting in the room with.

Since it’s design engineering, you’re a part of the design org but you’re still working with the engineering IC (individual contributors) track and their ways of measuring your performance. I haven’t seen enough people to go through a promotion cycle in this environment yet but the experience can be different based on the people making the decision. If there is not enough engineers on the promotion panel, it’s hard for them to relate to the work you’re doing. On the other hand, it’s good to have design represantatives there when you’re work is design or accessibility oriented.

For example, I’m reporting to the director of design engineering and she reports to the head of design. So you kind of need a healthy mix of roles to make this work.

That’s a good question. There is not much difference when it comes specifically to design systems. I think responsibilities are similar but kind of projects you might be working on or organisational conversations might be different and depend on the team you’re working on. I’ve been recently on a call with a group of our staff engineers and if you listen to them, they would work on completely different things with the only common thread being that they impact multiple teams.

Another important highlight is mentoring. All of them are mentoring other developers and are helping them grow and get more relevant experience.

I think one aspect that is the most obvious to me is how long Primer exists. Having a library released 10 years ago means that we also have users from all those 10 years. The product is quite big and if you made any flaws in the library design, it’s really hard to change now.

For example, a conversation we had recently was if we should reuse CSS from vanilla library in our React components. In theory, it should be pretty simple but you’re instantly thrown back to 10 years of products using the library where it won’t be easy to replace.

So I think that’s the tricky part since you’re basically glueing two versions of the design system together so all breaking changes from one library are also breaking for the other one. Different combinations of the libraries used is also possible. There are products that were using the vanilla library and are now adopting react one and are taking a performance hit while migrating.

I wasn’t there when the project started, but I think that was the release of dark mode at GitHub because we had to rethink how CSS gets shipped and how we treat design tokens. What helped us is that at that time CSS variables were available in all browsers we’re supporting. Still it was a complete re-architecture of our CSS and it took us 1.5 years to complete the project, including the product migration. That’s way longer that anyone could estimate originally.

As for me personally, I spend a lot of time working on accessibility and it’s very challenging to handle all the small behavior edge cases. For example, I’m working on the menus and when you navigate to the menu through keyboard – where should the focus go? It’s easy to understand that in a Storybook environment but the moment I start integrating it with the product – I see so many edge cases and places where something is already built on top of the current menu implementation.

That’s a general tricky part of maintaining a library for a long time, when your first implementation wasn’t perfect, so people start building on top of existing bugs and they suddenly become features. And when you try fixing those bugs, your fix becomes a breaking change.

I’ve been contributing long enough to see consequences of my actions so that’s a hard question. But I think one topic related to this is about the guidelines for building your own components. When building design systems for the first time we’re usually naive that system could include all UI components but you’ll always need more components in the product so you would rather focus on extending or composing them.

Since we were using styled components, everyone would just build custom components using this styling approach and now we can’t switch it out because of the amount of layers built on top of each other.

I think we could be in a better place now if we would have started with a recommended way to build components and kind of own the styling layer not only for components but also for the product.

For me that’s definitely the team as they’re all cross discipline. Everyone is a bit of a designer and a bit of an engineer. Each person has their own specialisation but there is a lot of overlap. We never had conversations where engineer would mention something and designers wouldn’t get it.

At the same time people on the team understand our scope really well. We can’t move fast and break things. Our team has to be intentionally slow, think about the changes for a while, sleep on it and then decide. And the whole team likes this way of working.

Both of these make working in the team much more enjoyable. Even though it takes longer for us to go through the implementation and ship features, I think the end result has a higher quality.

A common challenge when just starting is to get the team funded as it’s a huge long-term investment. So when I was working on design systems in the past, what helped us was not just telling the people what we want to build but showing the work. On one hand, we showed them all the ways in which the product was broken and where it would benefit from having a design system. On the other hand, we built prototypes and demo them to show how our development process could look like if we had more adoption and more people working on the system.

Design systems mean different things for every company so you have to adapt it in a way and show some results before getting any buy-in from the leadership.