How to staff a design system team

After some time and research, I think there’s simultaneously a lot of transferable knowledge, but also just the right amount of specific things about staffing design system teams, for this post to be — hopefully — useful to someone who’s thinking about just that: going from 0 to some number of people on the team.

The whole post is split into three sections: prepare, do, and evaluate.

Let’s go.

Prepare

Two big things to do to prepare:

• evaluate the current organization
• think big, start small

Evaluate the current organization

You start a design system team when there’s a clear promise of positive business outcome. You staff the team when there’s a clear picture of all organizational forces and how they impact different aspects of making the team successful: getting the right people on board, giving them a meaningful career, providing them with relevant feedback channels, and helping the team work towards the business goals.

As a manager, you probably want to reduce the amount of “unknown” in most situations, and getting people on board is one of them. To enable your people, do your homework: evaluate the organization in its entirety and find points of leverage. Those can be individuals and teams that, if your team works with them, can significantly help the design system succeed. They are managers and makers, sometimes in roles that aren’t obviously connected to design or platforms, and it takes time to find them. Your time is now — while your team has effectively zero people.

Think big, start small

My personal gold standard of design systems work is when the team can scale in a sub-linear proportion to the rest of the org. If per every Nth person joining the design system effort the team can make it work for an organization of ~N² makers, that’s fantastic! Which brings us to the “think big” part.

Thinking big is a three-step exercise:

• imagine the organization just tripled
• live through the short burst of panic
• then think how to help the org, at 3x its current size

It’s gonna go messy, but that’s okay. In the end, you should have an idea how the — hypothetically tripled — org can still do product development and hit the goals that a design system can help with. If it’s consistency of the UI across the entire product, it’s neither trivial to achieve in a growing org, nor easy to ensure at a large size of it. If it’s developer velocity, it’s going hit your team with inbound requests at 3x the volume — think what structure you’ll need to put in place to make it work.

Overwhelmed?

Start small. It’s hard to hire one person, let alone an entire team. It won’t go as planned. If you think big and have a plan, but start small and work with the situation at hand, it’s going to give you conviction and energy to move forward and ultimately fulfill the mission that your design system team is there for.

Do

Doing is a big one:

• scope the work for the team; or, phrase the vision in a way the future team members will understand
• craft job descriptions
• get help from the org
• start hiring
• build up the rituals as you go

Scope the work

Vision precedes staffing: only start staffing when there’s clear vision (think also: target state) for what the team is going to aim for and — with luck, skill, and hard work — achieve. But there’s more.

The problem with typical vision statements is that they don’t translate easily between different mindsets. What sounds reasonably ambitious and focused to a general manager or VP might sound like total rubbish to a UI designer or software engineer. Depending on who’s going to land on your team, you want to reshape the vision statement into something closer to a high-level scope of work. If it’s reflected in a handful of biz and tech metrics, this should also work.

Craft job descriptions

Probably the most tangible and, to most managers, most rewarding part. I’ll spend a bit more time here.

Over the past few years, I’ve struggled with placing design systems teams in the org. Is it a design team? A developer experience team? Platform? After looking at different companies, I don’t think there’s any clear pattern yet. Platform seems to be the most frequent option though.

First off, define the roles on the team. In the beginning, that might be premature, and you’ll want the first handful of people on the team to be as versatile as possible (avoid pure generalists though). Remember think big, start small? Think about specific roles you’ll need on the team and start defining expectations for them.

One thing, avoid dead-end careers. This might happen if you insert a role that is too specialized into an organization that is simply not ready for that, either because it’s not yet at a suitable scale or pace of growth, or because there’s no demand for most of the skills elsewhere in the org. Ideally, you want to give people you’re going to hire options to either grow at your team or to switch to another team without dropping a level or two.

Think about the duties on the team. What is something that design system people do that needs to be done on a daily basis? Define roles as combinations of these duties.

Another thing that helps, craft a skill matrix: for every duty that the team is going to cover, for every skill that is required for the design system to succeed, what’s the role that should have it covered? This small exercise is actually useful to define roles when you don’t have a concrete list in mind.

Talk to your peers in the industry — the design systems community on Twitter is super helpful!

Steal parts of job descriptions for similar roles from other companies.

Get help from the org

Get help from a few product managers. PMs are often looking for opportunities to get less operational and more strategic, — with some luck, you’ll get some feedback, advice, and early buy-in, from the people who are closest to the product, on what expectations from the rest of the org the design system people should be ready for. Use that.

Also, get help from a few executives in the company. Execs typically have their eye on certain business outcomes, so it makes sense to get as much information on what exactly those outcomes are, and think how designs system could, at least indirectly, help achieve them. This should help inform the leadership qualities you want to look for, as well as the distribution of them among the team members.

Finally, get some of the makers — designers and engineers — involved in the interview process. There should be a handful of people that have continuously exposed systematic approach to doing things, ability to forecast effects of the decisions, and high level of diligence and follow-through. Get help from them and compensate their work if you have the budget.

Start hiring

Having the job descriptions and more or less certain set of expectations, go warm up that hiring pipe.

Reduce job descriptions to the interview questions. Share them with the talent acquisition managers who are going to ask the candidates about their work experience and thus should be able to filter bogus answers from genuine proof of skill. Train peer interviewers to dive into specific leadership qualities that you want on the team.

If you’re familiar with how hiring works, there’s not much extra that you need to do.

Build up the rituals

As people start joining, the team’s microculture and the rituals are going to start emerging. Manage them. You want the rituals to serve the team best at current stage, no less, no more.

Remember think big, start small? Ideally, you should anticipate, starting from the first person who joins the team, how the way the team works is going to transform over time and with more and more complex problems that the team is going to be able to take on.

Evaluate

Evaluating how things are going is an essential part of management. You can’t rely on just doing — please, please take time to look back, walk through data, talk to people, and make conclusions on how things are going and whether things are going the way you need them to:

• refine the rituals, job descriptions, etc.
• help ‘em grow!
• and always feed it all back into the vision

Refine the rituals

As the team grows, the rituals will need to change. At the time of writing this post, I don’t have a definite layout of how exactly rituals change and what to be prepared for, unfortunately, but the core idea is that what worked for two people won’t work for four, and things change roughly every time the team doubles in size.

Help the design system people grow

If you’ve already taken care of defining career progressions (best case, in a formal way), it’s time to match them with how people actually perform and where they can make greater impact with the skills and knowledge they’ve acquired or improved.

Specifically in design systems work, I’ve noticed that a lot of growth happens through org skills: ability to prevent disasters, unblock individuals and even entire teams, and push the right points of leverage at the right times. This is much on the soft side, which feels really weird for someone with the title of a software engineer, but that’s exactly the high-impact work that the team can do. Part of your job is then to make sure this matches what the makers on your team see as a meaningful career progression, and if not, help them find a spot in the org that better suits their expectations towards what the company can give them in terms of learning and career progression.

Another thing is tiny surface, global changes: things like changing value of one design token that reflects in the entire product’s UI changing in ways beyond predictable. For this to happen, the adoption should be pretty high already, but even before that, there’s a lot of this kind of decision-making even inside the design system itself. Working through a couple such (potentially breaking) changes can be a good challenge for people who are new to design systems. For more senior folks, architecture work with broader impact can feel more fulfilling and result in tangible professional growth.

Feed it all back into the vision

This is very hard and time-consuming, but it’s important to regularly refine the vision statement. As you keep staffing the team with experienced people, and they apply the vision statement (what should be) in their day-to-day work (what really is), you’ll want their feedback on whether the two are aligned and feed it back into the vision statement when it makes sense.

---

This post is probably going to be updated one or two times, because there’s a lot of information specifically applicable to design systems still missing. Meanwhile, if you have feedback or would like to add or edit something, ping me on Twitter, I always appreciate that.