Building & Scaling Design Teams

Aashish Manchanda at UXDX Community: Building UX Teams. Video: https://www.youtube.com/watch?v=v3-q3OC5OLU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why hiring and scaling need more thought

[00:00:00] Aashish: Thank you so much for having me today, following the great talk that we just had. I'll extend the conversation along the same lines. The topic we'll be discussing throughout the next 20 to 25 minutes is building and scaling UX teams. My idea was that a lot of us might not be in a managerial position; a lot of us might be in an individual contributor position at the moment. On the screen you can see some of the fellows that I'm currently working with, the amazing design team at Scaler. What we are doing at Scaler is trying to build the tech school of the future, where we make sure that people who are getting into tech are really ready for the job opportunities out there.

[00:00:42] It's a combination of an edtech and job-tech company, where we make sure that the learnings required by the industry are given to these students. We have an agnostic team of around 25 to 30 people at Scaler right now, working especially on the product design part. Now, when it comes to managing a team or building a team, there might be multiple stakeholders that you have to come across and engage with in order to make sure it is the right time to build a design team, and whether it is the right time to scale that team or not.

[00:01:12] As I mentioned in the beginning, a few of us might not be coming from a managerial background. For those people who are currently working as UX ICs, or even if you're from a different background, just treat this presentation as a reference point for what you can do even while working as an IC. These are things you can improve upon to scale the team at some point, or maybe you're looking to step up in the game and at some point you want to go ahead and become a manager in your own team. These pointers will be helpful for you to build and scale your own design teams.

[00:01:49] Before I jump into the specifics, a small introduction about where I'm coming from. On the right-hand side you can see the beautiful team. Not everybody was there in the office that day, but this is the majority of the team that we have here. I'm currently leading a product and design team at Scaler. The platform itself is huge, around seven to eight million active users throughout the whole platform. Apart from working at Scaler, I also do consulting outside, and I keep doing stuff in the crypto space. I keep on building more and more products with Bad Unicorn[?], more like the mischiefs that you might have heard of, and I'm also active in angel investing and all that stuff.

[00:02:27] Why I felt this is something we need to talk about is because when it comes to hiring and scaling teams, very little thought goes into whether this is the right time to scale or not. We usually just look at hiring as the answer when we feel that bandwidth is the only issue. But just having bandwidth as an issue should not be the only reason you go ahead and start hiring.

[00:02:51] To sort out the whole conversation, I have laid down four pillars that will decide whether it is the right time to hire or not, and if you are planning to expand your team, what steps you might need to take to make sure the company is going in the right direction. Secondly, if you're working as an IC, individually contributing to a company as a designer or as a product manager or from the tech background, these pillars will help you retrospect on your journey as well: where do I stand in terms of expanding my role in the company? Let's say you are currently working as a design IC but you want to become a design manager at some point. These are things you need to make sure you are following when it comes to scaling those teams.

Pillar one: hiring and recruitment

[00:03:36] Laying down those four pillars very quickly, first comes hiring and recruitment. As I mentioned in the beginning, a lot of us start hiring right up front when we feel there is a crunch in terms of bandwidth from the design team. But are you really in a state to hire more and more people or not? A lot of people confuse hiring with scaling, but the two are not really the same. There is some overlap between the two, but they are not exactly the same terms.

[00:04:04] When it comes to hiring, you should definitely look into the business goals you have in front of you. Where do we want to go? Are you planning to have any new avenues coming into the picture that you want to hire for? Because let's say today there is a crunch in terms of design that you are facing. That might go away within a week or two. If you hire somebody, but your work was more of a temporary issue for the company altogether, then one month or two months down the line you cannot just go ahead and say to the people you just hired that they are not required anymore. So make sure that when we are hiring, those people are assets and not liabilities to the company. What is the bandwidth that is required? What are the future plans of the company?

[00:04:49] Then comes the why. If it is clear that we need to hire some people, then you need to make sure the requirements of the job are really, really specific. For example, in a small company, let's say I'm building a team of seven to eight designers, or seven to eight people in total in the company, and we are just in the seed stage right now. I might want somebody who can wear multiple hats, who can help the marketing team as well in making graphics and all that stuff. But if I'm at a later stage, I want somebody specific to do something specific. Let's say I'm a team of 20 or 25 people right now. I might want somebody who can go ahead and engage everybody to work on the design system right away. That might be the right approach to deciding what role I'm really hiring for.

[00:05:33] Extending the same: do I need someone who is good with design systems? Do I need someone who is really good with UI skills when it comes to design? A lot of people come from a good problem-solving background: give me any business problem and I'll try to solve it with design. But a few people are coming from the UI design perspective altogether: I'm really good with graphics and design, just give me any wireframe and I'll make sure it's the most beautiful UI out there. So depending on the persona you are trying to hire for, do not just decide when you are sitting in an interview that this person is really nice. Understand your requirements first. For example, I want to hire somebody who has really good research skills, which will help me understand where the product direction should go. So on your end, before getting into hiring, just make sure you know you want these kinds of skills.

[00:06:21] Now, if you are working as a designer right now, try to retrospect: what are my key skills, the things I'm really good at, and the things I want to be good at? For example, if I'm a designer who is really good at research tasks and activities, I might want to double down on those things and prove that these are my key skills: give me any task on these things and I'll make sure it is the best work out there. It's good to wear multiple hats all the time, but you should have some specific key strengths: these are things that I'm really good at.

[00:06:56] Then, when it comes to hiring, is the candidate open to learning something new or not? For example, if you are in a whiteboarding round and you see somebody who is really bad at UI skills, or maybe they don't think through the UX of the whole page, are they really willing to learn from your feedback, or are they not taking up the feedback really well in the critique session? Those attitude problems, I feel, come up at a later stage when you have to face them, and they become liabilities for a longer and longer time.

[00:07:30] Time management is the other thing. What sort of availability are you looking for? Do you think the work you are looking for is temporary, and it would do the job if I just go ahead and hire somebody on a contractual basis? Then collaborating towards scale. This is the same point I mentioned: scale cannot be achieved by just one person who is trying to build or scale the team. Efficiency comes along the way, and it's about whether the person being onboarded onto the team is really into collaborating with other people. And then again, the problem-solving skills.

Pillar two: developing and empowering

[00:08:04] Now comes the second pillar, which is developing and empowering, where we make sure we are making the best of the people we have hired. When it comes to building a team, you must have seen that every designer and every tech person will have their own set of qualities that they're really good at. So try to make sure, based on the qualities the designers have right now, which team and which product they should be part of, because that really decides the outcome for that designer as well: understanding that this person is really good with UX, or UI, or research tasks. If you are working as a designer, I'll suggest that you identify your top qualities and try to engage yourself in those tasks. Try to volunteer for those tasks as well. For example, if a sprint is coming along for a new page across the company, try to be a part of it, because you feel it's something you really enjoy doing.

[00:09:00] The second part, which I learned the hard way, is: is this really somebody who wants to take ownership? As a lead or design leader, you want everybody to become self-sufficient and take ownership of the tasks they are working on. But let's face the truth: not everybody is made to take ownership. Some people really need some hand-holding on the journey. So it's your job to identify who you should be giving ownership to, and who the people are that you should be making eligible to get that ownership going forward.

[00:09:34] "Always push for one role above" is my key idea whenever I have to give someone a responsibility. If you are at product designer level one or level two, always try to make sure you are managing upwards, so that it's not somebody coming to you daily at a stand-up asking what you are doing today. The key idea for how you should be going ahead is that you should be the one managing upwards: telling them, "I have done this, and I think we should be doing this next." What happens in that scenario is that the person who was managing you will try to get inputs from your side as well whenever something new comes up.

[00:10:16] The second thing, which I have seen mostly in companies, is about the ROI of designers. We basically ask them, "What are the needle movers that you have worked on? Can you share those needle movers?" and all that. It's really hard to point to those needle movers. So what ends up happening is that we, as product people or design people, try to create little needle movers: let's make this change, which will change this, and then we can show this change. Never get into that cycle, because once that happens, you start taking shortcuts over and over again. Needle movers are fine to have, but let's not enforce needle movers as the only key takeaway.

[00:10:57] Then the feedback circle, which I'll focus on more in the collaboration part as well. Never wait for performance reviews to understand where you are lacking, and try to learn more and more skills over time, because design is an ever-growing field. You will see a lot of things coming along: from Adobe XD to Figma, a lot of things have changed, from Lottie files and all that stuff. It's an ever-growing stage. Keep organizing workshops that push people to learn. If you are an IC, try to learn it yourself if your team is not doing it for you. And building towards scale, which I'll focus on in the next slide itself, comes under collaboration and communication.

Pillar three: collaboration and communication

[00:11:33] Now that you have made sure the hiring is done right, and you have made sure the key qualities of every designer have been utilized in the right way, it's time to understand how we can make sure the collaboration and communication between those people is as efficient as possible. Not everything needs to be a business ROI. We need to understand that every activity you do inside a design team cannot be related to the business return on investment of your time. There will be some activities outside work that will help your team engage with each other.

[00:12:13] For example, there's an activity we organized called the Buddy Program, which we recently launched at Scaler. Each company has multiple pods. For example, there could be a marketing pod, and then within the design pod itself there might be some products that each designer is working on. What happens over time is that people get isolated in their own pod. Somebody who is working on marketing and creating graphics might not get to know a lot about what's happening on the dashboard, and that reduces the collaboration between those people.

[00:12:46] So we need to make sure of the collaboration, and it doesn't necessarily come from working together. You can put those two people into some activity, let it be a fun activity, or just open up a discussion. What we did in the Buddy Program was organize a 45-minute call between two random people who were not working together at all, and give them some icebreakers to talk about. The outcome of the Buddy Program was really impressive: these people were getting feedback outside their pods as well. Let's say I'm working on marketing and I designed something new. I might go outside into the comments and ask, "How do you people feel about this design?" Design is a collaborative task altogether. One person can design it, and a group of people can also design it. So why not take inputs from as many people as possible who can give critiques that are really useful to improve the design, instead of some isolated person working on a design by himself?

[00:13:42] The second part: don't make people hate their jobs. I often push this in teams: good design cannot be a forced outcome. That's why I let them enjoy the company of other people as well. For example, if you and I are working on different projects but we're really good friends with each other, I might just show you some designs and get your input more passively, rather than asking you in a group in a more professional way. Those are the activities that do not have a direct ROI in that sense, but really help the team members engage with each other and get feedback.

[00:14:14] Now, leaders need to set the path that ICs won't find on their own. If you are an IC right now, I'll suggest putting more focus here, to understand what you should be doing to move up that ladder and what you can do in terms of managing upwards. Design systems, documentation and libraries: these things come in when you are scaling your team, when more and more people are joining and your designs are getting so complex that you need some sort of hierarchy in the system itself. I won't suggest that if you're a team of two to three people you go ahead and start building design systems, because that is a good exercise for sure, but this might not be the right time to build a design system.

[00:14:59] Documentation, for example: let's say you are working on something for six months, and now somebody else has to take over that same task. Or you worked on something, and six months down the line you feel this is not working. Now you have to go back and see what you did about it in the first place, but you don't have any place to go and see what happened. In that case documentation works really well. So even if you're working as an IC, do focus on these things over time. The game is not about adding design systems or starting to document things. The whole game is about identifying the right time to implement these things.

[00:15:37] The last part of this pillar is bringing those minds together. As I mentioned in the collaboration part, have those sessions where you are critiquing a new product that is going to go live, let's say in the next sprint, and you are bringing in everybody from the product and dev teams. Because of the problem-solving skills, which I have seen personally in my experience: when the product and dev teams come in with their background and share some knowledge about why this thing will take more time, you tend to start thinking in that direction.

[00:16:11] For example, if today you are sharing your thoughts with the developers, and they share that this design will take more than a month just to build, then in the next iteration, at some later stage, you might think before even starting to move things into Figma: will whatever I'm trying to design fit into the product and dev loop or not? Will it take so much bandwidth or not? Should I go ahead and design an MVP first before working on something huge? So collaboration, not just within the design team but with other stakeholders as well, helps really well over time when it comes to product building.

[00:16:51] The second part is that when you start engaging with other team members, try to reduce the gap in hierarchy. I faced this problem: one of the interns in my current company said, "I didn't ask you this question because I was really nervous to ask it, since you are really high in the hierarchy." I felt that should not happen in any team. People should feel confident when they have to put their thoughts out there. It's your job as a leader, or even if you're working as an IC, to make sure you are sitting at a round table whenever you are having a discussion.

[00:17:29] The more ladder structure you have in the organization, the more things go to the PD1, and then to the senior designer, and then to the lead designer. Hierarchy is fine, but the discussions and brainstorming sessions should happen at the round table. That reduces the friction, saves us a lot of time and builds a lot of confidence in the team. If you are an IC, try to build this structure within your team, so that at least with the people who are at your level at the moment, you're having those discussions right up front.

Pillar four: scaling the design team

[00:17:59] Now coming to the fourth and last pillar, which is scaling the design team. Let's say you have ensured that you have done the hiring right, you have developed people and made sure there are collaboration tools out there that are working really well. Then comes the question of whether this is the right time to scale the team. Scaling the team could have two different threads. One is scaling in terms of the number of employees, or the number of designers you have in total. The second is scaling internally, in terms of the efficiency of the team.

[00:18:27] Scaling comes with its own problems. Adding more people might end up reducing the efficiency of the team and increasing the managerial bandwidth, so that a lot of people spend time managing those people as compared to working hands-on. So the first step is to understand: do we really want to go ahead and make those changes within the team to scale it in that sense?

[00:18:52] There is a saying that is followed in the top tech companies, for example, that for every five developers you have in the company, you should have one designer, to make sure the bandwidth is used really well. This ratio could be different for every company. Companies that are really design-centric might have a one-to-one designer-developer ratio. Companies that are not really centered around design might have a seven-to-one ratio as well, depending on the product they're building. But you should have a clear understanding of where you stand and where you want to go. What is the ideal ratio we want between designers and developers, in terms of story points or bandwidth, or whatever way you internally understand the bandwidth of a team or team members?

[00:19:38] Do you need someone from outside the company to lead the team or not? Having somebody from the outside takes a lot of time to set the context, and it sets off a lot of people in the team itself who feel that they were eligible for that role. So make sure you are encouraging team members first, before going out and finding somebody to come and lead your team. Hiring leaders is difficult for sure. It's more than difficult; it's quite messy to hire leaders, because managerial skills cannot be identified within just a couple of interview rounds. You need to really understand whether the person I'm taking from outside the company, or maybe promoting within the company, is really eligible for this role or not.

[00:20:27] And make sure you do what we did in the hiring and recruitment part, which is set the expectations right up front. Even if you are working as an IC, I'll suggest you ask your manager, or whoever is working one step above you, "What are the expectations of me if I want to outgrow my role over a specific period of time?" For example, let's say you're working as a design IC at the moment, and you go ahead and ask your manager, "What should I be doing in the next six months to make sure I outgrow my current role?" You get that visibility. This could be your manager, or your mentor, or whoever you feel is the right person to get help from.

[00:21:11] The inputs could be that you need to understand how to scale those things up in a way that makes the system more efficient. For example, try to use the auto layout[?], and make sure the libraries and component libraries are really well updated in the stack. Try to make sure you are able to handle a couple of interns who do not need a lot of hand-holding from somebody who is one step above. The metrics or these key points could differ from company to company, but one essential thing is to have visibility of those expectations right from the start. Let's not wait six months for somebody to come back to me and say, "These were the things I was expecting of you, and you should be doing these things in the next six months." Be more proactive about what you should be doing in the next five, six, seven months.

[00:22:03] And the last point, as I mentioned: get someone outside the design team involved. We as designers have a lot of bias. Let's say you are a manager and you have a lot of crunch in terms of bandwidth. You know how the saying goes: never go grocery shopping when you are hungry. When you are a designer facing a bandwidth crunch, you will go ahead and hire a designer with a lot of compromises. Get somebody from the product team or the tech team involved, to make sure you can define the ROI of the design team and understand whether you are at the right ratio or not. Because before hiring anybody, the first question should be: can I improve the efficiency of the team up to the mark? If I feel it cannot be improved, only then go ahead and start hiring for more roles, whether it's the lead or the ICs or whatever the role could be.

[00:22:58] Summarizing across the four pillars we just discussed: hiring and recruitment; developing and empowering; collaboration and communication; and then the last part, scaling, where you could be scaling the team members, or you could be scaling the systems you are following, design systems, libraries and documentation, where you make sure things become easier over time. Let's say a task was taking three weeks last year, and doing the same task today takes only two days. Then you can say you have increased the efficiency of the team, and you have scaled the team up to this point. Scaling does not mean only increasing the number of designers you have. It also means you have scaled to a point where it takes less time to do the same things that used to take a lot of time.

[00:23:44] That was it from me in terms of the four major pillars where you want to stand out. I'd be open to any other questions you might have, and maybe Rory can come up on stage and ask those questions. If you have anything outside this as well, I'd love to hear more from you on LinkedIn, or these are the handles I have provided where you can reach me. Over to you.

Q&A

[00:24:09] Rory: Thank you very much, Aashish. It was very detailed, and apologies for the little hiccup at the start, but I think you got through it and shared quite a lot of information there on how you can scale your teams. If anybody has any questions, please feel free to comment and put them on whichever platform you're on, and I'll share them with Aashish.

[00:24:31] I had one question. It came from literally your last point there, about getting somebody else involved. It reminded me of Amazon's bar raiser program, where they do the same thing: you have to get somebody outside, because there's too much temptation to fill your team. With your outside person, do they have veto power, like in Amazon, where the outside person can literally say no even if the manager is really desperate to get somebody in?

[00:25:03] Aashish: Yes, we do. This person usually is not outside the organization altogether, but somebody from a different management team, or from within the team itself. For example, if you're hiring for design, somebody from product, or at a higher scale the AVP of product, or maybe somebody at that stage might come in. They won't be given a lot of context about who we are hiring for and why we are hiring. They will just be there more for the cultural fit and the attitude check of the candidate, and to make sure we are not rushing the decision of hiring the person.

[00:25:38] Rory: It's good to hear. I think it's a great practice if people can emulate it. The other question I had was on empowering, where you try to act at the step above where you currently are. I've seen this where people are a bit frustrated at their team because everybody wants to be the step above and nobody wants to get their hands dirty and do the actual work. How do you recommend people manage that, where yes, you need to get your day job done, because otherwise your manager is going to be upset with you, but you also need to be thinking about how you can get that step up?

[00:26:19] Aashish: For sure. The first step, when it comes to hiring, I'll definitely say: check this in the hiring itself, that you're hiring somebody who is ready to learn those things instead of just working in their comfort zone. But if you're trying to improve yourself on that specific point, I'll suggest you try to get outside the comfort zone where you are doing just the things you are asked to do, just for the sake of the job you are getting paid to do. Think of the points where, let's say even if you leave this organization, or you have to step up your game in some way, or you go ahead and start something of your own at a later stage, what are the key learnings you want to gain?

[00:27:06] For example, if I am working here, I might be working not necessarily in the design part when looking at one step above. I often sit with product people and try to learn their problem-solving skills, and with the tech people to learn their problem-solving skills, so that you can engage yourself in those conversations. The best part about engaging yourself in conversation with those people is that you will start understanding the value of good questions. Once you start asking good questions, your thoughts get valued over time, and as your thoughts get more value, people will be asking you for your thought processes whenever a decision is being made.

[00:27:43] Instead of your lead coming to you and telling you that you have to design this thing, why not bring in a culture where the lead is coming to you, discussing the problem statement and asking for inputs from your end as well? So when I say try to be one step above, that is what I'm saying. Not just going ahead and doing work where you are being given a PRD and you are just designing solutions. Try to become engaged in the thought process and try to solve the problems for those users, and that will bring you up the ladder automatically. You pushing forward and doing more and more work won't make a lot of change compared to a change in your thinking process and the quality of the questions you ask.

[00:28:22] Rory: Brilliant, that's a fantastic answer. I think that actually brings us up to time, so thank you very much, Aashish, for sharing all of your insights and thoughts.

[00:28:35] Aashish: Thank you so much for having me here.