 I'm going to start my talk and I know we're slightly late, so I'm just going to get going. So I'm talking about building and scaling design organizations, design teams, design organizations, whatever you want to call them. And this is a bit of a change from the previous talks that have happened, right? The previous talks that have happened today have all been about craft. It's been about becoming better at the kinds of things that we do, whether it's design, whether it's collaboration, whether it's technology, all of these things have been about how do you do design better? It's been about design systems which allow teams to collaborate. What I want to do with this talk is I want to talk about how do you create the space for doing better design at an organizational wide level, right? How do you create enough space, enough, you know, it's either literal space or do you have space for the design team to be available? Do you have space for the design team to get better at their craft? Do you have the budgets to bring in things that you need to get better? Do you have the mind space to start thinking about things like professional growth and development of your designers? So who is this talk going to be interesting for? And I think that's, you know, reasonable question. You either are a part of a design team or an organization or you run one or you want to run or be part of a design team or an organization. So and a quick note on the last one, if you decide that you want to run a design team or an organization, quick word of advice is don't. So why am I talking about this at this conference, right? The first reason is because there's very little information out there about building effective design organizations, right? There's lots of information about how to, I don't know, vertically center text. There's lots of information on how to make better design systems, right? There's lots of information about how to use different and better design tools. We had pages speaking about design systems. We had other people talking about, you know, different products like Figma, which allow for better collaboration. But there's very little information out there about how do you grow from being a small design organization with maybe one person, two people, two? How do you make that larger? How do you make that better? How do you scale it up and still do good work, right? I think that's the key part of it. Yeah, it's not just about adding numbers, right? You don't want to say, okay, now I have a 50% design team. That doesn't work. You need to have the right kinds of people. You need to have support structures in place. You need to have other people who do nothing except ensure that the team has the software licenses and computers that they need, right? The other reason that I'm doing this talk is that most design teams, most design studios are run poorly. Most design teams are run poorly. Most independent studios shut down very quickly after they've been started. Most, you know, lots of design studios that I know in India. Most of them shut down within three to five years. That's pretty bad. And I think like if you talk to, if you are part of a design team, if you're a designer yourself, or if you have friends who are designers, you've probably heard stories about how designers make terrible managers and how their manager is really, really terrible, right? So I've organized this talk into two or three parts. The first part is, yeah, what are the conditions that you need? Or what is the environment that you need to run and build an effective design team? The second part, which is a large part, is a pathway to show scale, right? How do you actually grow from not having any designers, right? I'm sure if you've been in smaller startups or even larger ones, you've probably been in a situation where there's been barely anybody, maybe an engineer is working on design or sometimes the CEO or a product person. How do you move from that point in time to a place where you have, I don't know, 50, 60 designers all working together and doing good effective work? So, who am I? I run a small design studio called Uncommon. We are a design and development studio. We primarily build and design mobile apps for our clients. We've worked with lots of people over the years. Yeah, lots of, I think we've worked with, I just checked. We've worked with most Indian unicorns, even though I dislike that term. I'm going to be using it at the price during the talk in different contexts. And one thing that I do a lot these days is that I help our clients. It's kind of funny because they outsource their design to us, but I help a lot of our clients in source design. So that's building in house teams, helping those teams build the capabilities that they need to do effective work, right? So, self-help book time, 12 qualities of effective design organizations. I stole this from another popular book. Okay, I'm going to jump into things. There's three things that I'm, well, not enough contrast, first lesson. But there are three things I'm going to be talking about. The way I've structured these 12 items. The first part that I'm going to talk about are the foundations of what's required, the second thing that you can't see is output. And the third thing that you can't see is management. And I think there are components under each of these that are required to build effective design teams, right? So the first thing that I think is necessary to build an effective design team or an organization is what I call a shared sense of purpose, right? Now you've all heard and some of you may have had the misfortune to have actually needed to come up with one of these mission and vision statements at some point in time in your career. Or maybe you've interacted with your companies and they're awful, right? They're trite, they're cliched, they just should not exist in most cases. But where can they be useful, how can they be useful, right? There's very little articulation a lot of the time about what is, why does our design team exist? And that reason will be different for each design team, right? So a shared sense of purpose helps act as a first pass filter, right? It helps externally articulate how the design team operates, right? Do you for instance say that quality is going to be the thing that you focus on? Or is it going to be speed, right? Are you a team that believes in iteration, which is what I think is the right answer? Or do you think that one should build things right the first time, right? Visual delight versus it works well? Or are you going to be like Apple and say, I want to do all of these things, right? So it's also a useful reference for the team internally to look back on and say, hey, are we actually doing what we said that we're doing? Are we actually working in an iterate manner, right? Are we actually doing the best possible work today? Or are we just shipping stuff out of the door because that's what we need to do? So that's often a useful checkpoint for internally. It also externally helps as a first pass filter so that people can say, do I want to actually work here? Is this the kind of work that I want to do? Is this a philosophy that I can identify with and believe in? The second part of the foundation, right? Is at a leadership level, right? You do need to have leadership, which is and I think these terms are key, right? You need to have them being focused and you need them to be empowered, right? I'll go into those two words in a little bit more detail. But the first thing that leadership does is that it provides cover for a team, right? It ensures that the team can do the work that they need to. Leadership also provides guidance. It provides direction. So you essentially are the North stars to say that, okay, yes, this is how we're going to do things. We're going to say no to this particular request. We're going to ensure that you have enough time to do X. They negotiate between different parts of the organizations as well, right? They're the seat at the table. We've heard this term a lot. Design needs to have a seat at the table. So they are the representative of the design team at the table when they're talking to the executive, right? Then they do boring things, but essential ones which are like fighting for budgets, priorities and you know, whenever there's a conflict between teams, between say an engineering team, between the design team, between legal, between finance, HR, they are often the representative or they need to be the representative of design at that point in time. So the first part, right? Focused. With focused, what I mean is that often what happens is that design reports into a different division. I've had clients who've had design teams which are reporting into say the engineering team. Often they will report into product. What that means is that the energy of the leadership is at that point diffused into these two different areas and they often don't have a strong sense of what, how design can contribute positively towards this. So design needs to be owned by design leadership, right? You need to have the ability to think about how to mentor the design team. You need to build that team actively, right? And if you're doing multiple things, if your design leadership is also your engineering leadership, it's unlikely that they'll be able to do those two things well. And so usually what will happen is that he or she will, or you know, your leadership will end up prioritizing or focusing on the team that they know well or they know better. The other part is, yeah, about empowerment. They need to be able to say no. They need to be able to say that, hey, we need four more people. We are understaffed and there are too many things on our plate right now. They need to say that, hey, we don't, we can't use the existing recruitment pipelines. The people you're bringing in are, or you know, the recruitment agency that we're working with are terrible. So yeah, that's a second foundational value that we need to build effective design organizations, right? Focused and empowered leadership. The third thing, and this is, is authentic user empathy, right? What does that mean? Design is a discipline which lives under the larger ambit of human-computer interaction, right? But I think that we focus on those last two initials and not too enough on the first one, right? We think about computers. We think about screens. We think about how performance, right? We don't think enough about the humans within that equation. And it's critical for the design team to be able to empathize with users and be able to understand what their lives look like and how these interventions, these design or engineering interventions that we're doing, how those fit in in their lives. Do your users look like you? In most cases, if you're doing work for, if you're doing work, your users may not look like you. They may not have the same backgrounds as you. They may not have the same lives as you. And it's really important to be able to understand who they are and make decisions that support their lives rather than things that you think are right. So for instance, a good mark of this within a good or an effective design organization is there sufficient time spent with going into users' contexts and seeing them live their daily lives, looking at how the design interventions that you make are being received by them. The other part about this which is really useful is also that this is a easy way to make the subjective area of design really objective. If for instance you're having disagreements about color, about, you know, I think that this is the way to go or actually this, but I see this button all the time or this screen is really simple. Actually being able to show people around you or in other teams that actual users had a problem at this stage or they resonated really with this particular visual choice will actually lead to that discussion being far less subjective in nature. Quick example on this. We worked with a ride sharing, a bike taxi company where the driver app actually just had buttons. And what happened is that the app was being used by these drivers who were on motorbikes in similar to an Indian environment, dusty, loud, busy, etc. And so there was a lot of accidental key presses which would happen which would do things like move to the next step which was like end the ride or I've reached this place even though the person hadn't actually got there. So a small intervention might be to move that, to ensure that you don't have accidental key presses. So can you move say a button to a slider rather which requires a much more deliberate action which is unlikely to be triggered by, you know, your phone touching, you know, part of your body through your pocket, etc. So being able to understand how users, you know, exist is really key to being an effective design organization. The last part of the foundational aspects are about how do you communicate that design which is, you know, often looked at as a really creative discipline which doesn't really have a relationship with business. How do you communicate that it actually has value within the business context in which we live? Other functions typically don't understand that design is important and therefore don't give it the space that it requires. Designers are also, I think, equally guilty of not being sufficiently articulate or not taking the time to understand the other areas and how design can play a role in actually driving business value. If there are other designers in this room, we can't say that we are creatives and we don't think about business at all. So, you know, don't talk to me about whether, you know, the last 20 hours that I've spent really polishing this animation actually was meaningful or not. That's a really broken conversation which should not happen. We see this a lot today, especially with, you know, platforms like Dribble, etc., which just emphasize the visual aspects of design, lead to design which is produced for Dribble and not actually solving business problems. So it's really important to be able to understand where design drives business value and then constantly be able to articulate that both within your organization as well as externally. So that's the first part. So that's the foundation of what I believe are the, of what I needed to build an effective design org. We'll now jump to the part that is most visibly designed, right, the output aspects. So the first part within the output or the fifth quality of an effective design org is that it supports the entire journey, right. And what I mean by that is that design needs to have an impact across an entire organization. I think you've probably seen this in your own organizations. There's perhaps a product organization and then there's a marketing division and those don't necessarily talk to each other, right. Or maybe you have other parts of the organization which are completely disconnected. Customer support is not something where say design plays a role. But it should. Because all of these different parts of your company are places which have an impact ultimately in terms of your customers, right. Quick example of that is for instance, if your product, say like you have, say you're running a mobile app and you have a bunch of notifications which the product team is pushing for because that drives user engagement, right. But at the same time maybe your marketing team who isn't talking to your product team also wants to push their own notifications to users. Now, end of the day what happens is that your customer or your user gets spammed with 15 notifications and then just chooses to disable notifications on your particular app. So you're essentially losing that channel because you're not looking at design holistically across your organization. The perfect example and perhaps the cliched example of an integrated design organization is Apple. I believe Johnny, I've spent a year and a half working on the design of their campus because ultimately they believe that design played such a fundamental role that they needed their physical space to also have design thinking applied to it. So that all the things that, you know, collaboration and I think if I remember correctly he talks about how the most important thing was to be able to see the trees. So I guess when you have a trillion dollars in value you can prioritize the trees versus polishing your mockups. So yeah, supporting the entire journey. The other thing is that I think and as designers I think we're really responsible for this is that we don't always look at all aspects of scale. We spend a lot of time on what I call surface of design. So we spend a lot of time thinking about colors, about typography, about this layout versus that layout. And we don't think enough about how does this, how does design clear role across my entire organization? How does this impact the way that my brand is perceived? So the rough demarcations, the big picture where looking at everything and how does design impact this to going into things like structure. How do I frame my design briefs? Are my design job descriptions being written appropriately? Am I getting the right people in? Two things then and then moving down to strategy. So flows between your app, information architecture, service design. So looking at how does the, you know, if you're large enough to split your offering into multiple pieces, does your login experience have similar characteristics to your checkout flows, for instance? And then finally, of course, you do need to do really, really good surface work as well. You need to spend a lot of time thinking about the craft and art of what your offering finally looks like. So design needs to effectively deliver at all of these levels to be effective. The other problem with design is that we don't have clear cut standards for saying that this is good design and this is bad design. There's many different ways to measure it. It's often subjective. It's like, I like this. It's often about who has the loudest voice in the room. At least technology has some metrics. You can talk about, okay, the code has 20% more bugs than it used to. You can talk about this page is 40% quicker than it used to be last week and that's a clear improvement. But whereas with design, it's very difficult to have clear hard metrics and to be unless you often have post facto metrics. So you see that, okay, this page performed better in conversion than the previous iteration of it. But you don't necessarily have a metric at the time of delivery. You can't necessarily say, okay, this is objectively better than this screen. So it's really important for the design organization to create meaningful standards to measure themselves by and then to stick to those standards and not dilute them over time. We need to externally articulate them constantly so that people know what to expect. Other teams know that, okay, until things are at this particular level of quality, it will not be shipped. And I think this is universal, but in design, all other parts of the organizational, perhaps unintentionally, discourage this level of quality. Raise your hands if you've heard any of this. I need this yesterday. Can you just put this quick fix in? Can you make the logo bigger? Why do you need so many people? These are not unusual things to hear. And it's not even poorly intentioned. It's just the way that organizations are structured. And so you need design to be able to uphold and stick to their standards of quality. The other part is that you need to value delivery over perfection. And this is the only time I've taken some animation liberties. But yeah, you've heard about real artists ship. As designers, I do think we have a tendency to get bogged down into getting things perfect. And we need to move towards getting stuff out on a far more regular basis. The idea of continuous delivery, which exists in software programming, needs to also be present in design. We need to have continuous design through this thing. And I think if you were there earlier for Abhinav Stock, where he's talking about Figma, that's a good example of continuous design. There's no, this is ready, but you can jump in and look at it at any point in time, regardless of where within the organization chart you fall. The other aspect of this is that it reduces the stress of the launch, which is often a scary thing. If you have continuous design delivery, then you're not worried about this large launch, which goes out, which is looming on the horizon, probably late and where you have to get things exactly perfect. The concept of something being ready to ship, rather than something being done, is a critical concept. If it's ready, let it go out there. And the good thing about the medium in which we all work, is that there's room for improvement, room for iteration, which can always happen even after something is done. So, coming to the last bit about the foundations, which require, which effective design orgs will require. And this is something that designers naturally chafe at, managing, having managers, having management. It's often seen as process which hinders me. But this is something I believe very, very strongly, that for the long-term health of an organization, or of a team, you need not just design management, but you need good design management. You need management to think about what is professional growth look like for all members of my team. You need people to look at what makes my team happy and effective. How do you ensure that you don't get disillusioned while being a designer? So, the four points that I think make sense here are, again, the H in HR. We are all humans, treat people like they are, and not as resources. Sort of linking back to the earlier point, design doesn't have as much definition as other disciplines. What's the difference? I don't know what the difference between a UX, UI service, creative technologist, product designer, any other titles that you can think of, user experience, programmer. I don't know, I've heard like 30 titles for people who fundamentally do similar things. That often corresponds to salaries, to compensation, etc. So, we need to be flexible around things like titles and ladders, and be willing for different parts for people to kind of grow through. The other part is, design is often an understaffed or overstaffed. So, if you're understaffed, then design team is just stressed out a lot and not delivering effectively. If you're probably overstaffed, then people don't have much to do. And I think that designers especially, want to see their work go out into the world. That impacts that a lot. Is there a budget for education? Because design like technology is an extremely fast moving field. The kinds of design tools that I know about and I've used are rapidly becoming obsolete. I believe that today if I want to be really effective, I have to learn JavaScript and be making prototypes in framework now. So, the other thing that's also hard is to allow team members to also move to other positions or other disciplines. That's also a reasonable growth path to expect. And that's something that say somebody who started as say, somebody who's working on content, now wants to move into design. An effect or rather a healthy design org would be one that allows that transition and growth. The other thing that I think that design teams do poorly and which we could do a lot better is to have far more diversity in terms of people's perspectives and backgrounds. The thing I see all around me is that design teams often look very, very similar. And it's really simple. Build a team that looks like yourself. That's easy. That's safe. That's comfortable. You know how this person works. You know what motivates them, what drives them. You can make the same kinds of jokes. Everybody gets along. But unfortunately design requires divergent thinking. Design is one of those few, not few areas, but I believe divergent thinking is fundamental to coming up with really, really strong design. Especially in India, where you have so many degrees of diversity that aren't being fulfilled. Gender is one large area which design does a little bit better than engineering, but not much. The others are even harder. There's caste in India. There's class. There's people's orientations. There's religious diversity. There's also language diversity. Most of the design teams I work with, all speak or design teams have seen. English is the lingua franca, but the intended audiences, especially in a country like India, are far, far different from that. And that has a huge influence. If you create a diverse team, that also helps ensure that your assumptions and biases are at least questioned. And that ensures that for instance, if you have a design team which is all male, all between the ages of say 20 and 30, you're going to get a particular set of design solutions. And those design solutions make certain assumptions about say how comfortable people are with technology or what's important in people's lives, etc. And this is hard. You have to ensure that you have to remove bias, which is present. You have to remove bias in recruitment. You have to remove bias when you're hiring, when you're promoting people, even when people are growing within the organization. But it's key. The other aspect is how much collaboration happens and how do you create that space for collaboration? And by collaboration, I mean that feedback is encouraged. Feedback is both encouraged to be made as well as to be taken. Mistakes are encouraged. Mistakes are really, really important. As somebody who's been doing design for a while now, I will tell you that it's very rare that you know that a design is right when you put it out there. There is a lot of experimentation, a lot of mistakes, which you need to have that space to make that. With collaboration, you need to ensure that there's sort of a critical piece of ensuring a collaborative environment is that there's respect. There's respect for each other that feedback happens in a way which is frank because that's really, really key. But you're not compromising your quality standards for this. This is the whole idea of creative abrasion where you have divergent perspectives and you fight them out to ensure that the best solution comes forward. Again, going back a little bit to the previous slide, how do you ensure that, how do you create structures that ensure that all the voices are heard and not just the loudest voice or the person who leads the organization finally says, let's do it this way. Jumping into the last bit, how do you ensure that operations happens effectively? And because design typically emerges from a very sort of creative loose space, operations is often something that's overlooked, but it's really important to ensure that you constantly remove what I call the sand from the gears so that things move smoothly, people can do the best work that they can. So that's really important. Basic things like coordination, file management, access to hardware, software, whether people have reasonable working hours. These are all key parts of operations which need to be taken care of. So essentially, this is, you know, sort of if we sort of look back at these three things, we need to move away from, you know, sort of very crude productivity metrics, like how many designs have I made this week, right? It's almost as meaningful as asking, how many lines of code did you write this week, right? Treat people like humans. And it's especially important here because in some sense as designers, we exploit our own humanity, right? Because the way that we work is that we take that empathy that we feel for people or we build systems to create empathy for other people and then we convert it into our design products. So since we're doing this so often, it's really important that the organization ensures that designers are treated like people. So I'm going to pause here for a sec because I think there's a good time to, if there are questions, and if not, I'll jump into the evolution of designogs and a bunch of ways to get from zero to many. Yeah, so I think somebody has a question. Hey, so two questions. One is how do you ensure or how have you ensured the baseline of objective quality in the design work? And secondly, what checks and processes one needs to put in place in order to make sure that the highest paid person's opinion or HIFO does not take precedence over everything else? Cool, great questions. I think this I'll start with the second one. So often when we are asked to approach a design problem, right? We jump into like one of the first processes that people jump into is this one called brainstorming, right? And I think brainstorming is awful, right? It's fundamentally broken. It doesn't allow for great solutions to come out and it prioritizes the loudest voice in the room or the person at the top of the pecking order is or her solution to be prioritized. There are lots of ways in which you can change that. For instance, if you are familiar with the design sprint, I don't know if some of you have run them or even part of them. There's this whole concept of how there's a really nice phrase that they use which is escaping me at the moment, but essentially brainstorming quietly together, right? So there's an actual exercise where everybody comes up with solutions to a particular problem on their own. And after that, the solutions are, you know, maybe put up on a wall, for instance. And then you can go and look at which aspects of which solutions you like. And then there's a bit of a voting process, et cetera, which happens, right? That's a small way to ensure that the loudest voice doesn't always sort of win. The other way is also ensuring that, you know, the small things, like ensuring that everybody is heard. You know, we do really silly ritualistic almost things like, you know, giving somebody a particular object and only when they're holding the object can they actually speak, right? It's a shortcut to ensure that everybody gets heard, but it actually works. It works much better than just allowing anybody to sort of say something. I think the other thing is also in terms of how you structure and ask for critique and feedback, right? And that's a whole other topic, like we could go into 30 minutes just talking about structuring critique. Like I said, right? One of the underpinnings has to be respect. The others have, because only when you have respect can you have really frank feedback. And only if you have really frank feedback can you ensure that you're not diluting your quality standards. So that's sort of a stab at your second question. The first one is harder. And the way that I don't know if there's this, you know, as many different ways as there are organizations, the way that we particularly have solved or are trying to look at this is by saying, has your design been looked at by somebody else, right? Have you worked on this with another designer, for instance? So we've borrowed the concept of pair programming from, you know, extreme programming and mentors like Nillenso, etc. And we've applied that to design. So we do pair design. We also then ensure that we build in user testing into all our cycles before saying that this is ready, right? So everything goes through a round where it's exposed to actual people. We look at their reactions and then we iterate on that, right? So it's not as subjective, hopefully. Then it is, yeah. Does that answer roughly? Okay, cool. Any more questions? Otherwise, I'm going to jump into this part of the talk. So this is stage one, right? You, oh, okay, I'll run. Stage one is the initial pair, right? And this is really, really important that you always, that when you start, you have two people working together. You have somebody who leads the team and you have somebody like a product designer, right? This will be a little bit more relevant towards digital design because that's what we do. It's really important to have these roles as distinct separate ones so that if you remember, we talked about delivering at all levels of scale so that people can, both people can think at the levels of scale that they are suited to, right? You have enough time for the head of design to start thinking about prioritization, about planning. How do these requirements match what needs to be done in the future? And you have a product designer who can actually go really, really deeply into the craft of how does this look and work and so on, right? Yeah, so there's, these are kind of the characteristics, right? They need to be creative. They have managerial roles. They have operational roles, but there's still a maker at this size, right? You're two people. You still have to be a maker, right? From two, you slowly go towards stage two, which is a full team. And this is roughly what that looks like, right? You still have that head of design. You have now say three to four product designers, right? This is still a sort of a manageable number. We found that teams of roughly six to seven are roughly how many, roughly as large as a design team can take without needing further management input, right? We're introducing two new roles at this point as well. You have a communication designer. So that's somebody who, sorry, works on collateral. It could be somebody who works on illustrations. It could be marketing materials. It could be, you know, graphic design broadly. The other important role at this size that we've noted is a content strategist, right? Our interfaces are full of words, right? That's 50% of the available screen real estate. And it's really important to think about how those words are crafted for us. And as the previous talk also talked about, as voice is becoming an increasingly important part of design, you do need to have somebody who is thinking about how tonality, how do you basically communicate different states of a machine to people using language, right? Then we jump through, you know, from a team to an organization. So this is where we were at. And basically what we do is we double this, right? So one of these product designers, actually it could be anybody, right? One of the people within the team typically grows into a team lead kind of role. And we establish a second team, which somebody, the person who's, you know, heading design then overseas in more detail. Yeah, there has to be some people skills, but they do have domain expertise. So they're still respected as a maker themselves. The other role that we introduce at this stage is also, is the one of a user researcher, so a UX researcher, right? And the job of a UX researcher is to take the, you know, sort of output of the team to eventual users and look at how they respond to it, right? So there's generative aspects, there's evaluative aspects, right? So evaluative is looking at how things work. Generative is actually going in and saying, hey, these are potential areas to solve problems in. So this is the part at which things start getting tricky. I call this stage coordination and complexity. This is where we sort of left the team. And now we're going to grow it by saying, okay, we're going to introduce a new role, which is a design manager who is now completely responsible for that team, right? The head of design does not play a role at all in managing that team. And we kind of scale it up, right? So roughly, you can, you can sort of roughly build a team of this size without needing too much more management, right? So you have about two or three management level people. You double the size of your user research team. And then you add two more roles, right? There's what I call a service designer, and then there's a program manager, because at this size, you've probably got unwieldy enough that you need somebody to do all those operational tasks full-time. And you also have a service designer who ties the work that all these three teams are doing together. So if there's one team which is, let's go back to our e-commerce example, there's one team which is looking at login, there's another team which is looking at the product page, and the last team which is looking at checkout, you need to have one person who sort of says, hey, how do these three things work together and are the flows between them seamless enough, right? Yeah, strategy and structure, yeah. Then finally, we move to a larger design org where essentially the leadership becomes far more distributed, right? So we sort of left people here, and oops, we get to this, right? Which looks really colorful, but is really interesting. And actually I'm just going to jump back one, sorry, didn't realize I'd left my animations in. Essentially what we're doing now is we're going to double this, right? And we introduce a new role, which is the design director who plays the same role as the head of design in the last stage, right? So they're managing one team, and then there's another design director who manages another team. The research team now has gone to four people, so it probably needs somebody who's head of research who looks at how does that team actually grow much further, look at their professional development, right? The only new role, yeah, we have a bunch of other things, right? We have another service designer to tie everything even more strongly together. You probably need two or three program managers at this point in time. So there are two new roles at this stage of an organization evolution that you're talking about, right? One is creative technologist, and this is a really fun and interesting role where essentially this is somebody who's perhaps doing prototyping full-time. Now if any of you are there for Shri Hari talk, we talked about how we're building a, you know, simple, this product called Simple with a sort of a subset of the features of the main app, and it could be completely throw away, right? A person who's doing creative technologist could be somebody who's looking at prototyping, could be, you know, building these experiments, lanes out, etc. And we're also introducing a new role, which is the creative director. Now what happens at this scale of an organization is that the head of design is unlikely to be actually able to look at craft and how best to enforce quality standards. So you now do need to have somebody who can actually look at, is this work the most, are we, you know, really going deep into the craft of all our distinct areas? So there are a couple of distinct areas, right? There's product design, there's content strategy, there's communication, there's research, and there's creative technology. The creative director will sort of look at and chart out a growth or set quality standards for all of these different teams, right? Yeah, so creative leadership. And then this person, the head of research leads the research team, is this basically hub for a bunch of insights. So anytime you want, the leadership wants to know answers to a particular problem, this is possibly who they would approach, right? And yeah, there's a creative technology. So these are quickly the design roles that exist divided between leadership and an individual contributor, right? So that's essentially sort of a roadmap to scale. And depending on your needs and your organization, it will look different for you, right? If you're an organization, say, which has a lot of physical events, maybe you have a lot more communication designers, right? You have people who are working on, say, a physical space design, like the design of this event and banners and standees and so on. If you're somebody who does a lot more digital stuff, maybe you have more product designers, maybe you have teams of six rather than five or four, right? So there's plenty of variation that this model actually allows for. I think the key thing that I'm trying to talk about here is the support that you need at different levels as you grow your team along this path. So any questions so far on this? I think we're running out of time, so I'm jumping through a bunch of things. I'm not going to talk about professional growth and design hiring, but if you do want to talk to me about either of these things, feel free, we can chat outside. There's lots of stuff here, right? To unpack, if you're interested in any of these areas, there's a whole bunch of books and journals and things that you can jump into. I'd suggest all of them at different points in time can be interesting. There's quick reads, like design is a job. There's sort of manuals like org design for design orgs, and then there are sort of the classics like the Mythical Man month and Cathedral and the Bazaar. All of these elements of all of these influence the thinking here and in building orgs, right? So I'm going to stop there. One quick thing if you, yeah, and ask for questions, and we can even open it out to be more discussion oriented if you like. Cool. If you do want to connect with me, I'm on Twitter and you have my email address as well. Thanks.