Design system: How to build an engineering team?

[Dear readers, I’ve decided to move my content to a different platform — Manage Frontend if you enjoyed reading my writing, please spare a minute and subscribe to my content on Manage Frontend. Thank you!]

I’d like to introduce a series of articles about my experience and lessons learned while building design systems in a large-scale organization.

I am skipping the part which explains how to convince your organization that you need a Design System in the first place — every organization is different and no matter how many arguments you provide it might still not be possible to change this need unless it gets approval all the way from the upper management.

I hope this information reaches well those who are ready to build a Design System but do not have all the details on HOW.

Before starting anything one must understand that the development of the Design System is a long-term process, it can easily take at least half a year before you can use initial results and at least one year until the system reaches the initial maturity level. Even then, the process is not finished as the system is going to be like a living organism that evolves and changes over time.

As with most things, initiatives such as building a Design system can not really happen without a dedicated team, hence the first article in the series is: How to build an engineering team?

How to build an engineering team?

While working at Toptal, I came to a point where the engineering department finally got approval to build a development team whose goal was to implement React library for our Design system. At that point, I was unofficial engineering manager of what soon became a fully staffed team. Thankfully I wasn’t alone and I had a colleague along my side with plenty of experience working in the company for many years. Given you are handed almost a blank piece of paper to work on, it is extremely helpful to have someone by your side planning the upcoming work, helping to bounce the ideas about hiring plans, etc…

I strongly believe that the team developing Design system should consist of a mixed people — some hired internally — with plenty of experience of existing systems, teams, processes, etc.. and some people hired externally — who can bring in a fresh breath of air, new ideas and otherwise balance things out in the team.

So having a team of 2 was already a good start, but we knew we need more — in most cases developing a comprehensive UI components library can be considered far more difficult than building out a product features hence you need a full team (preferably 5–6 engineers which can join gradually) to support all the incoming work.

Dedicated hiring pipeline

While two of us initially had already started brainstorming how we are going to build a Design system library (see my next article “Design system: How to build a library?”) in parallel I’ve prepared and opened a hiring pipeline to find the rest of the team members.

The company already had an open hiring pipeline for Frontend engineers to join product teams, but, I’ve decided to spin up a dedicated hiring pipeline aimed to find people with the specific skillsets for the Design System engineering team.

Why have I decided to go this way? First of all, I believe that while any Frontend engineer can build a component (basically everything is a component in React) not every engineer has the same level of view when it comes to how those components should be used by tens of teams effectively. It may not be enough to hire senior FE engineers if they don’t have the vision needed to successfully develop a library (unless you have available resources to coach and mentor them — which in the initial phase of Design system library development is not the case).

Structure of the hiring pipeline

I knew from the very beginning that I want to have a good balance for the number of applications that we may get, and the number of actual interviews that I personally would have to do. I didn’t want to spend 1 month full-time doing only interviews, the beginning of the team was pretty intense on its own and we also wanted to get a foundation for the library in place. The structure that I’ve decided to use went as follows:

• The dedicated job description on the careers page
• The initial stream of candidates was reviewed by the recruiter (not interviewed yet) and sent to me for evaluation
• I’ve taken a quick look at their resumes and specifically focused on the answers that they gave to open-ended questions (more about that in the section below)
• Those who passed would proceed to the recruiter’s interview
• Next candidates go through a technical (verbal) interview (we called Tech 1), where we would ask various technical questions just to learn more about the candidate, what relevant experience they have, etc…
• After successful Tech 1, candidates proceed to Tech 2 — where they have to do a live coding session — a simple task to handle a few API requests, build UI to show the results, etc… We did understand the stress that it may create and because of that, we kept providing guidance in case people get stuck. (I would actually change this format so that candidate could do a homework assignment without any stress and then would do a code review sessions together with the candidate instead)
• Last, there was an interview with the director of engineering. Usually, I would participate in both Tech 1 and Tech 2 so this last interview is more of a formality as none of the candidates were ever rejected after this interview.

Questions that I like to ask in the job description

While it’s easy to put a requirement in your job description for “Building libraries” or “Developing design system” it may not be as easy to find such people because of a limited talent pool out there.

Going with overly generic requirements may also lead to a larger audience than you’d like and asking for too specific requirements may have an opposite effect — shrink the audience.

No matter what you list as requirements it might still be pretty difficult to filter out the people only by reading their resumes and looking at their past experience.

You may put a requirement “Building libraries” but if this is nowhere mentioned in the candidate’s resume — how do you avoid wasting time for interviews where you just learn about this?

For that reason, I’ve decided to ask a couple of open-ended questions that involve the skills that I’m looking for so that I could evaluate their answers and make a decision whether it’s worth taking candidates to the next interview stages.

Questions in no particular order of importance:

• What does application architecture mean to you?
• Describe your idea of good, clean code?
• What measures do you take to ensure code reliability?
• Describe the biggest technical challenge of your career
• Share an example of something you have failed at. What did you learn from that experience?
• If faced with the choice to use existing code or create a solution from scratch, how would you decide?

The amount and type of questions are entirely customizable — it’s up to you what is the most important aspects that you’d like to read about even before having a live conversation with a person. As one of the recruiters told me — they could ask those questions during screening interviews, however, I believe allowing candidates to provide these answers with the application will also let them answer in extreme detail and show whether they are truly interested in the position.

Moreover, I like to use answers to those questions on a Tech 1 interview — sometimes as a conversation starter, sometimes when I feel like it would be good to get some clarification, etc…

Skills that I am looking for in candidates

Here is the list of the actual skills that I personally look for Design System engineering team:

• Architecture — in my opinion, it is very important that the candidate cares deeply about frontend architecture. Even though the library itself doesn’t have much impact on the overall application architecture, it can certainly have enough influence. It is important to understand various building blocks of the application so that it is easier to plan and implement library code later on.
• Clean/readable code — it’s generally something that you would look for when hiring ANY engineer, however, while I wouldn’t put so much importance on other roles, I think it is extremely important for engineers in the Design System team. The reason is simple — the output of the DS engineering team will be the code that is used by many people in the organization, essentially it becomes like an inner source repository read and worked on by many people outside the team. The goal is to make everything as smooth as possible so that external contributions could be easily made to the codebase.
• Testing knowledge — again, something that you would like ANY engineer to have, but in this case, just the knowledge about basic unit testing would not be enough. You can only test as much with unit tests in the UI library, you have to go above and beyond, become creative and consider various testing methods so that you can ensure well-rounded quality — visual regression, performance, integration with other components, cross-browser, etc… Every bug, every issue within library code can have a multiplying effect, block people from delivering new features, create frustration, etc…
• Keep it simple stupid — throughout my career, I’ve seen various complexity code and I’m not talking about complex functionality. I’ve seen complex functionality yet relatively simple code, which is easy to understand and follow. I’ve also seen the opposite — simple functionality implemented using complex, over-engineered code. It might be fine to work with over-engineered code in a scoped environment — people get familiar with it, there is no active maintenance needed, etc.. however, library code tends to be read and modified more often than anything else, so it’s extremely important to keep it simple at all times. No matter how experienced an engineer you are — at the very least you should be able to read the code, better if you can easily contribute.
• Don’t reinvent the wheel — I know how tempting it might be to write your own software for a problem that you are tackling, however over time I’ve learned that it eats so much time, resources and eventually leads to worse quality than less-featured, but off-the-shelf solutions. I think it is really important that people working with library development do not try to solve each and every problem with their own solutions — as the saying goes — pick your battles. I think that majority of engineers can write a new solution, but those with experience can find a way how it could be avoided, how existing tools can be used to satisfy the requirements.
• Eye for design — this one is probably the one that I’m most relaxed for — while it’s nice to have, I don’t think it’s 100% necessary. I believe while working with the design team, having a good eye for design may help when considering alternative, easier design solutions.
• Soft skills — while members of the team do need many hard skills to successfully work in a team, I think having good soft skills is also very important. After all the team is supposed to communicate with other teams, provide support when necessary. It’s very easy to end up in a heated discussion, so every member of the team has to have the ability to defuse even the tensest situations.

I can not tell the best method how to validate if a candidate possesses those skills, though usually for me the best is to get this information out during the interview. I don’t have a strict process or a list of dedicated questions that I ask, I like to initiate conversation ask a bunch of different questions, and see where it takes. I noticed that with great candidates, there usually is no problem to go with a conversation on and on, those who do not have the necessary experience usually start to struggle or don’t have much to say.

Strategy and vision

It’s not enough to build a team of experienced people, you need to define vision and strategy where you as the team are heading.

Personally, for me, the initial vision of the Design system engineering team was always to make product development more efficient, allow for a consistent and higher quality UI by providing all the necessary building blocks. I also knew that as a side effect having a common UI components library will encourage collaboration between different teams.

Stay tuned for other articles in the series to learn all about the strategies we used for the team and library development

Results

I am happy to say that 2 initial hires that I made for the DS engineering team were among the best engineers I had to work with — one is now Principal engineer and another — Frontend Architect. To this day I use similar practices to identify good candidates even if I’m not hiring to a specialized team like Design System engineering.

The library that the team built is still up and running and is actively and successfully used by more than 10 teams and more importantly, makes UI development much more efficient and consistent.