Accelerating product development with an integrated Design Team - with Shruti Ramiah @N26

Welcome to the Product Bakery. I'm Christian and today here with my co-host Alex as well as Shruti from N26. Hello. Cool. So, yeah, maybe to quickly introduce you, Shruti. You started design, you went to the Copenhagen Institute of Interaction Design and then from there on moved, you worked at IDO, you are now working for N26 where initially you were pretty much like leading or heading the research team and now you are responsible for the whole design team at N26. So maybe to give everyone a little bit like a better understanding also of how your work looks like. How big is your team at the moment and how is it like sitting within the organization at N26? Thanks for having me first off and for the introduction. The team we have is a little over 30 people. We are across New York, Barcelona, Vienna and Berlin. So we're really a distributed team and we are about two thirds product designers and one third user researchers. We work super embedded within our product organization. So the design team sits under the CPO. That's the setup that we have at the moment. So this means you collaborate like very closely with the CPO as well. What are the main touch points that designers have like throughout the organization? How do they work also in their day to day life? So designers, researchers, all of our team work super closely with product and engineering and data and product marketing. So really in deep cross-functional teams, we have teams with embedded designers, but we also try to create sub communities that we call design collectives. So these are at the level of a topic area or a segment as we call them. So that each designer, each researcher has a few people who understand the problems that they're tackling. Day to day can give them good meaningful feedback and you're not briefing everyone every time you speak to somebody. What was the thing you were working on? And I don't remember. And can you give me some context? So we work in this way where we have deep embedding within the product teams, the cross-functional teams and very close collaboration with product and tech, but also a bit of more community around the designers and researchers to have a sense of belonging, a sense of feedback and growth as well. And I imagine obviously also as N26 grew massively over the past, how did this change in the history? Like I imagine you were not always working in this kind of embedded and then having like sub teams structure. Yes, absolutely. So firstly, I have to say having embedded designers or a team being able to embed at the cross-functional level is really a privilege because that requires a certain scale. And we didn't always have that. But also what we managed to do was really grow the team at pace with product and tech. And that's, I think, one of the big learnings for us that growing at pace is really important. So you always have fully functional teams and you're not stretching people too thin across too many topics. The collectives are definitely something that's new. We only started it this year. So we launched it at the beginning of the year based on some feedback that we've been receiving along the way, responding to the growth of the team as well. When you are 25 people, it's hard to have an effective crit. So you can't do design critiques the same way that you did before. You struggle to have clear lines of feedback, clear sources for inspiration. So a lot of what the collectives comes from is the feedback that we heard in 2019 and the things we wanted to address in 2020. We realized when we did that it was not the typical model and it is also therefore challenging. We've had to do a lot of explaining, helping people understand. So wait, does this mean I don't belong in the cross-functional team anymore? No, of course you do. So there has been some need to explain and respond and set clear understanding responsibilities. But on the whole, it's an experiment that we think is working well for the goals that we have and are continuing to keep exploring and iterating that. We've done a few rounds of feedback also with our product management and our engineering counterparts because they feel the impact of that as well and trying to make sure that everybody is coming along for the ride and seeing a positive impact of the collective structure. I do have to say, I've never heard of this idea of collectives. So how was this idea born? Where is this coming from? And maybe you can help me better understanding. Yes, absolutely. It's not surprising that you've never heard of it because we'd never heard of it before either. I just thought you were going to say that because I'm a product manager. No. To be honest, every year we go through some rounds of feedback and iteration, right? When you have an organization growing at the pace that we've had, it's really important to keep sensing. And some of the feedback that we were receiving in the last year was around fair distribution of work, need for a community for feedback, closer collaboration between designers and researchers. And Christian Hertland, the head of design at the time and I together were looking at all these different challenges and also looking at the changes within our product organization. So again, talking about moving at pace with your product teams and saying, within this changing environment, what kind of solution can we design? Really looking at it as an org design problem and saying, what are the structures or processes we can design to help our teams get what they need? It was definitely a tough decision because it was going away from all known standard models. We didn't want to go into a pure pool or consultancy model. It definitely doesn't suit the organization we are. And at the same time, we didn't want to go into a completely fragmented embedded model where there's no ties between the different designers. So it was a bit of a solving for the problem we have. So designers solving whatever the problem is, whether that's an org or product design and coming up with this concept together and iterating it with our product management team, our product leadership, with our CPO to make sure that it also fits the objectives and the structure that we have at the product level. Cool. I'm pretty familiar with these kinds of problems, especially as the team grows. And I think one thing that you also see is what you mentioned around like critiques and team meetings that you have. The engagement gets lower. It's also much harder to really, I always felt people are less honest. The bigger the group gets and the more, because it's fairly easy when you're a small startup, it feels like, okay, we're all friends. It's very familiar. I can tell whatever I think in every sort of meeting and this changed. What I'm curious is like, how did you really collect all this feedback? Did you have some sort of like workshops also to run this through? Can you maybe elaborate on this one? Yeah, absolutely. So the first and most useful thing is just constant observation. Just even looking at a Slack channel, you can tell how engaged the group of people is, how effective is the conversation going on? How well are people getting the guidance that they need? So just a lot of observing. Then all of us are having one-on-ones with our direct reports, seeing the problems that they're having, seeing the challenges that they face, what do they bring up? So I guess the lesson there is to make space within one-on-ones to also talk about topics like how is the work environment supporting you and not just about solving the problems in the content or the design. And then we do run regular feedback circles. So whether that's surveys or having round table sessions to get feedback, to hear what's on people's minds, what are they challenged with? And I would say that's been super helpful because coming into that reflection session at the end of last year, we really felt like we had a good grip on what the problems are that we were solving for. You're also working with something like ENPS or ways to measure the happiness factor or efficiency within the teams? That's an idea. We haven't done that. I think we do have obviously the company-wide engagement surveys that give us a temperature for the team and other ongoing feedback. One of the benefits is this year we had our wonderful DesignOps lead join. So a lot of, I think, what the DesignOps function can also do is have a really good pulse check of these topics of how is day-to-day work going? How are the people's daily work topics? Are they being addressed? Are they getting the support they need? Do they have the processes they need? So Stephanos, our amazing DesignOps lead is doing a lot of retros with teams. So this is my current source of feedback. So I get a lot of feedback from teams directly, but also through these observations through DesignOps. But that wasn't there last year and I highly recommend it if you don't have it. Cool. I think we never really spoke about design operations in the podcast yet and I think it's a super interesting topic. Could you elaborate a little bit more on what DesignOps is and how how DesignOps works like with the rest of the organization? And what is the DesignOps mission? I think, so to be totally fair and honest, it's something that's in the making. I would say we are all figuring out what DesignOps is exactly. And there's probably, I know that there are many more mature organizations that have had DesignOps functions for much longer that could speak much more confidently about it. I would say I have been exploring and learning together with Stephanos what the role is. And how I would define it right now is all these different ops functions, whether it's research ops, design ops, or product ops, it's really about focusing on enabling people to do their best work. Making sure you can remove whatever the roadblock is so that people can do what they're there to do. So whether that's making sure they have the right tools, just simply tooling can often be a challenge and improving tooling can help you to collaborate better or document better and make sure that you're having informed decision making. Do things like culture and environment, work environment. What is the emotional state of the team? Making sure that you're keeping track of those aspects as well. Collaboration styles, supporting different work styles. I think another thing that we're really looking at growing within DesignOps is also clarity on process and roles and responsibilities. So helping give a clearer picture to everyone involved, what they're expected to do, what's the process we want them to follow, what skill levels do we expect them to have? And those are typically things that sound like they are HR topics, but I think they belong very much also in a DesignOps environment because of the specificity of the design process. A lot of these points that you just mentioned are usually also the job of the head of design. And I think especially when the team is still smaller, that's what you do. You think of the processes, you think about how can I develop the people, you think of how can I positively affect the culture. So bringing in this new role, how did it affect your work and your responsibilities? I think it's like having an amazing partner to work with together with you on it. And someone whose whole mind is dedicated to that rather than part, because as the head of design or someone leading multiple designers and researchers, you have multiple topics you are focused on. And it's great to have somebody whose focus is making this organization run smoother. Also, they have a neutral stance in the organization, in the role that they play. So I do think it's easier for them to elicit more honest feedback, more direct feedback. They can be an anonymous channel for you to get feedback that maybe someone's anxious to share directly with you, more people are comfortable to be critical. Not that you shouldn't encourage honest feedback in every circle, but giving people the opportunities that they need. And really working. So I have weekly check-ins with our design ops function, because really, it's like pairing and setting priorities for the whole team and how we're going to grow. So having that really close collaboration means that there's multiple people for pushing these top line topics for the team. This brings us already back to this communication style and collaboration style that is so important if you want to succeed. And I also remember Alex, when we at SumUp were working on a design system, we paired so many times and prioritized together to make sure that we stay on top. And Alex back then was a good sparing partner. I'm not sure if he will say the same about me. But... I'm not so sure about that. Let's talk... That's why I laughed. No, it's not true. Christian was always a great partner. And I think we achieved a lot. We don't need to praise ourselves. The question I was thinking of, especially when it comes to the prioritization that you mentioned, how much prioritization or feedback was coming from the team? So was it the top-down approach that you were doing back then, or how much impact was driven by the teams themselves in the operations? So prioritization of operations topics? I think it's... I don't see the tension actually, like the bottom-up, the top-down. It's an interesting thing. So if you have a massive headache, I can't tell you to go for a run and get healthy. So I need to solve your massive headache right now so that you can feel well enough. So you go for a run and get healthier as a human being. So as a team, if you have aches and pains that you don't solve from an ops perspective, that is just not going to help you be in the right frame of mind for larger topics or larger process improvements that you want to create. But that doesn't mean that you only work on the aches and pains. So the job, I think, of the ops function and the design leader is to make sure that you are pushing all agendas on the right level of priority. It's never yes or no. It's always, okay, this is 50%, this is 30%, this is 20% of our effort and energy. And balancing off often the things that need like band-aids or solutions right away with the things that will long-term improve our status or our situation. And design systems is actually a great example of that because it takes a lot of effort to get it up and running and going and finding the buy-in and creating the impact and getting it to a point where it is robust enough to function. But if you don't keep pushing that in the background or investing some amount of your capacity in that, you will always be playing catch up. I think this is the trade-off with the balancing act that has to be created. Still on the ops topic, I think I have two questions that I would be interested in. Asset is a fairly new function in most of the companies. Who do you hire for? How does the profile look like and how do you also align this with the company? Because I think there is obviously also a big challenge of you're trying to get someone in into a function that has never been there. That is not very common in a lot of the companies, especially if you look at startups where the team is also still at a small enough size that, for example, the head of design can solve it. But I think you cannot just look for a head of design who has done this because they probably are looking for other job titles or roles. So who is a good design ops person? That's a super good question and a really hard one to answer. I think we're coming now to the point where we're defining internal job description. So we are supported by the fact that this movement towards recognizing the need for ops functions is not just within design, right? We are seeing product ops, we're seeing tech ops, we're seeing research ops. So all of these different functions are somehow being born and people are recognizing the need for it. So that's from the point of view of helping organizations understand the need and recognize that this function has value. I still think it's pretty hard sell. There's definitely a moment when you dip over into needing it and you recognize it. If you have a leader who understands your discipline, that can really help. I think, for example, within the research ops context, we could just demonstrate the hours saved if we brought in a research ops person. So it was a much more mathematical argument to make that if a researcher spends 50% of their time right now doing administrative tasks, we enable so much more value if we bring in someone to take those on. From a design ops perspective, I can see that's actually a little bit harder because it's not like I can put a number on it and say, this person is going to open up 25% of a designer's time. In design systems, yes, I can say that, but not specifically the whole ops function. So I think it's definitely a challenging space and you need a little bit of trust from your leadership. And I think when the person comes in, making sure that they're working on impactful things that then you can hold up and show that this is the impact that this role creates. Looking for that person and finding the right role, this is still super challenging. And what I would say right now is hiring for mindset. So hiring for a person who brings that approach of wanting to be in a facilitative and an enabling position, having a good understanding of the discipline. So you need someone who's worked in design, worked in research, worked in a product organization, seen the different sides of the problem, and can show empathy and understanding for all the different roles. So it's not just the designers, actually. You want someone who gets what the product managers are going through, who understands what the engineering team's needs are as well, and can really be this kind of hub for connecting between different disciplines. Those people are not so easy to find, for sure. And it's quite a challenging role to play because you have to act through other people rather than directly on problems. So you need someone with patience and persistence, but they are out there. And there are people who are very engaged by this challenge. It's a very organizational challenge to solve. I think potentially people like agile coaches are also people who can transition into these types of these roles that are a lot about process and enabling people to do better work. Do you think there is a lot of people out there who fall under these criteria and know about this specific job? Because I think that there might be people in different roles and they might not have design background or and they would be a good fit, but they would never go on to a job description that says design ops. Totally fair. And I think that's the process of like evolution of the discipline as well. I would say the exact same thing has happened with user research 10, 15 years ago, where nobody had heard of a role called a user researcher. There were researchers in academic context, in different environments, and then they started to see an opportunity to, oh, I can do those things, or I do that in a different context. And they started to recognize themselves in the roles and the descriptions they were hearing. So now we have a diverse group of people who would approach something like a user research career and it's taken its time to become understood. And I think the similar thing might happen with design ops. But if I look at the job description and the mindset you are looking for, I'm asking myself this whole thinking of ops positions, is this really solving a problem or is it rather born out of a symptom? Because if you have 50% of administrative tasks that you need to do, where is this coming from? Is this an underlying process or organizational process issue that you have, or is this something because people, nothing against your designers, but is there a problem within the working style that forced people to maybe not focus enough on the main things or where is this coming from? I think this is again the question of the headache versus the getting healthy. So of course there's headaches and those come from maybe there's some operational inefficiencies or maybe you have a process that's like not working perfectly within your organization or things that you can fix. But the overall question of being a healthy team that can run fast still remains. So even if, you know, the role isn't just about solving those aches and pains. It's about zooming out and looking at how we work and making sure that we're all working in concert and doing the best possible job. And the fact is the world changes fast and around us, and especially in a growing team, the context changes repeatedly. So that perspective is almost continuously required. It's never done. The show must go on, right? And obviously one big part that comes also into play is the fact that the more you work with cross-functional teams, the more you have like all these in-between communications that need to happen. And if you have a person that can facilitate this also, it definitely is a problem that will remain and that you need to somehow like cure and have a solution for it. Because people should also be able, and you maybe correct me if I'm wrong, but people need to be able to focus on their specific daily tasks and the problems they have to solve as designers in this case. And we should also not underestimate that we're talking about hyper growth here, where you maybe sometimes need to introduce in quotes manpower to move faster instead of just trying to solve continuously processes, et cetera. You also mentioned research, and I know that's a topic that you're also very passionate about and you've had like, you were in the lead like for research also for a long time. And I think it's the conversation also of how the role developed and grew is something very interesting. And we had this conversation of how do you hire also the right researchers because it's very similar to the design and ops role. And I remember like we last talked about integrated research and I think this is probably an interesting topic also to elaborate a little bit more on how do you see research in a company? Because I know there's also many different approaches, like you could have a research team and in like consulting agency style or have it like really close to the product teams. What's your take? Within product organizations, I think there's many different models that we see of how research is structured. My current belief is actually that you have to keep evolving how that function fits within an organization as the organization grows and as the needs grow and as the majority grows. So I think pretty early on when you are a fairly small team and a fairly small group of designers as well, what you're really looking for is what the problems are you're solving. You're pretty aligned on what your problems are. So really it's in the how, like how are we going to solve this that's unique to us and successful for customers. So that's where your focus is a lot when it comes to receiving customer feedback. And that's a role that's deep embedded within the design process. So really you need ideally a researcher in the team, but also can be designers who have that skill set of knowing how to go out and speak to customers and bring the feedback into the process. And it's super intuitive. As you start growing and start decentralizing your problem definition process, it becomes more and more important to have the researchers to be able to run ahead of teams and start to scope out what are the problems we could solve? Why should we be solving those? Why would people come to us for this problem and starting to almost create briefs or problem spaces for the teams to bring into the more cross-functional processes of defining then how we solve them. And you always need people to be measuring and tracking how you're doing. So whether that's designers, researchers, data analysts, product managers, someone needs to always be looping back to if we solved it this way, how did we do it? One of the things that I strongly believe in is that research and design are not phases. They're not like you do research and then you hand it over a wall, there's the report, everybody go read it. And then you go do some design and maybe you run some usability tests or something like that. I really believe in kind of an overlapped interlinked process where in a perfect world for me, there would be a designer-researcher pairing where they really work together and understand each other's crafts. Because even if you look at the classic process of finding some needs and making a design out of it, there's so much translation. And the more we can talk to each other and communicate through each other's languages, the better the outcomes become. But I also realized that's a huge ask and not everybody comes from that background. But we try to create environments where people can actually do that and create moments where, whether that's after a research session, having a collaborative ideation session or a concepting session or a sketch session that helps us bring those disciplines closer together. I really love that you create this environment, this collaborative environment and not just throwing stuff over the fence, how Alex from Riot recently said in our episode. I'm curious, how is the collaboration and prioritization working together with the product managers, for example? Can you tell us how you feel about looping them in or are they looping in you? How do you like to see that in a perfect working environment? Yeah, if so, I talked about designers and researchers, but honestly, that's not the scope of the circle of collaboration. The circle of collaboration is much bigger. There's product managers, there's the analyst, hopefully, that you have on your team looking at the behavioral data you have. There's the engineering team, the tech lead. There's hopefully product marketing or some representation of marketing. There's maybe your market research inputs that you have. So that circle is much bigger. And in my perfect world, everybody's sitting together and having these conversations. Because at the end of the day, what we're trying to do is, what are the questions we need to understand better? What are the hypotheses we need to explore and confirm? And who is best placed to solve them? So some of those questions might actually be technology questions that we need to go and do a technical prototype to see if we can even solve the problem in a reasonable timeframe. Or it might be a market fit question that actually we need to check at large scale market data. Not everything is to be validated just through a user research process. The business case, the product manager is responsible for if we're going to solve it this way. Is it going to be a successful outcome for us? So I would, in my perfect world, these teams sit together, these people sit together and talk about what are the answers we seek and who is best placed to answer them. Then we come back together with our answers and cook the dish together. Who do you see in the driving seat in all of these roles? I think that's an interesting and controversial question. I guess it's whoever's head is on the line. But I think that's... Is it yours at the moment? And for the design, I'm happy to stick my head out and be responsible. I think absolutely. The user experience at the end of the day rests with the design discipline or the user experience discipline, but all of us make it. So it's really a collaborative decision. I think who leads this is really representative of your organization. So who is in the tree up at the C-level is often defining who's leading the conversation. At N26, we say we're a product-led organization. A lot of the decisions are held... The product management is held accountable for a lot of our decision making. But we don't see that as saying that we abdicate responsibility. ability and the product manager told me to do this, that's not an acceptable answer ever. It is a collaboration. One discussion that I would love to have also in this round is not entirely around who is in the driving seat, but also like how you like really then execute, especially for example on, you mentioned researchers need to have also the space to, to go run and then come back with a few themes and opportunities that we could then solve in the product teams. And if I purely look like also at the role description between designers, researchers, PMs, I can see this to some extent in a lot of these roles. And I know a lot of like product managers that especially like also in the past with smaller teams and less developed like design organizations would do their research and they would talk to the customers and so on and so forth. But I'm curious on how to best balance who then, or how to connect like also these insights, because I'm totally in favor that PM also goes out, talks to the customers and creates his own insights. But at one point you need to bring it in and have a collection of all these insights. And then again, bring everyone on the table and prioritize these topics and make sure And ideally, like all the insights that you generate and all the, let's say different data points, and those can be interviews, this can be like, yeah, from tracking or whatsoever, that they all have the same quality standard. Because I think like there is, and we talked about this, I think with Nikki as well, where we were saying it's important that you do research. Many companies now know that you have to research and you don't need to have an experienced researcher to do it. But at the same time, there is also this danger, you might have someone who's not experienced enough to avoid biases and whatsoever. And then he comes back and is like, oh, I have this perfect insight, but it might lead you in the wrong direction. Absolutely. Yeah. Leaving it here. I don't even know if it's a question, but I think it's something that I ask myself also a lot. It can be definitely very dangerous. Yes. Intention is always a tool. And it's always a tool that can be wielded for good or evil, however you want to call it. At the end of the day, if we are all aligned on our intention, and everybody's coming to it with the best intentions, then you cannot fault them for the decisions that they make. So if we are in agreement of what our goals are, and the rationale with which we believe we're achieving those goals, so that we can then check and assess whether those rationales were accurate. So we believe we were going to have outcome A, because we learned X thing. And the way that we're manipulating or changing the situation or making the design to achieve that is Z. Then you have a construct within which to check back and evaluate the decisions you've made. I think the risk is when you are not having ways to check and balance whether the decisions and the assumptions you've made are accurate. There's always a risk of poor quality work, whether that's research or design or technology. That's not limited to research. I think what is important is for us to all recognize when we need to know enough about each other's disciplines to recognize when there's an expert in the room, right? Like I can problem solve your technology problem, but when an engineer works in the room, they're way more qualified to solve that problem. And I would wholeheartedly ask them to solve it rather than trying to still band-aid stick on it. So when you are in a team where you have the privilege of having a researcher, why not let them do the work and bring the best outcomes? When you don't have that privilege, you do your best and we all align on our intention and find ways to check back that we have the best information. As you say, the alignment part is the most important and this always sounds very nice on paper, but I would be interested how you drive this kind of collaboration from a process point of view, because it's super easy said that everyone should sit in one room and we need to align on this and we are enjoying privileges and having experts here. But it happens many times that the experts are spread across the teams or are even within the company. But how do you pick them up and make sure that they talk to each other? That's exactly defining the process and the expectations of what you expect should be done before a decision is made or a call is taken. And this is where this is the funky clash with everybody saying, oh, I got so many meetings. But actually, your meetings are where you're doing your work, which is often a counterpoint for designers and other makers, technologists, even for researchers, because they feel like they should be out speaking to people more. But if we're not communicating and connecting and actually sharing what we know, then we're not doing the work. So that's a funky balance to be struck between how much time you spend communicating what you've done versus doing more. But I think it's a part of our work to spend that time hearing other people's points of view and sharing our points of view as well. Learning is super hard. And that's where all the people skills that we learn and all the collaboration skills that we learn come together. A big part of that is recognizing and respecting every other discipline and what they bring and understanding constraints and understanding that you don't want the perfect to be the barrier to getting a good outcome out in the world. Perfect being the enemy of done is, I think, the expression often. But how can we, one, find the best possible compromise and, two, line ourselves up for improving on that compromise continuously? So it's not about launch and then, oops, it was whatever it is. This is how we're going to learn if the decisions we made were the right ones. This is how we're going to iterate on the decisions that we've made. And that's where having the research, having the insights, the hypotheses is such a big part of that. An additional thought on this is also if you have a researcher in the organization and maybe you don't have enough researchers to really have them being fully integrated and you still have like other functions doing their own research. It's also a good way to simply leverage this one expert that you have in terms of educating people and thinking more of maybe can a researcher have really sessions with product managers on how to conduct research, how to phrase questions, how to avoid biases and so on. So something that you have seen also happening in the organization? Yeah, absolutely. Very actively, very intentionally, actually. Utilizing research is one of our core intentions within the research team, especially in 2020, but we reached a certain scale. And that's really about scaling your impact without necessarily scaling the people. This is just not feasible to constantly just grow the size of a team. It's not essentially effective. So doing the work to train more people to set up tools that allow them to do more of their research themselves, setting some guardrails so they don't go into it, so they have some guidance for quality. That's all part of a good sort of maturing research function. And essentially, it's great for researchers as well, because that means they can spend more of their time working on the tougher questions, the ones that are a little bit more complex to solve, and they can focus on higher value work essentially. So wholeheartedly support that. But there's also so many great tools coming out these days that I think this is a space that's really going to bloom and flourish in the coming years. Especially on the topic of scaling and not being able to endlessly scale. And I think by now we've spoken about design ops, research ops, researchers, designers, product managers. What would you say is a good ratio from ops people to, for example, designers or researchers? And how many researchers would you, for example, also place on cross-functional teams? Maybe just to also make it a little bit more practical for our listeners in understanding where do I place people? How could such an organization look like or has to look like? Yeah, this is a really tough question. That's why we're doing this. You're putting me on the spot. There's so many factors to consider, really, that I'll just rather talk about the factors. One is obviously what is the larger organization that you're in, right? What is the scale of that? How fast is it growing? How many cross-functional teams are there overall? How well connected are they? If you're smaller and your product is pretty centralized, though, you might be able to work with a smaller group of people. But the bigger and more distributed the problems get, the more people you obviously need. The other factor is the seniority and experience level. Of course, a more experienced person can handle more stakeholders, can handle more topics, more teams. But there is a breaking point to that because, obviously, if they're code switching all day and if they're topic switching, then they are not going to be very effective after a certain point. What ratios we are currently working on within our design team is trying to get to a point where we can have one strong representative of design and research within every cross-functional team. So, on the level of PM, engineers, designer, or researcher, and other stakeholders. And having a researcher to every two to three cross-functional teams. But again, it depends on how wide the topic is. Each topic area, each thematic area, needs at least two to three researchers to really have the space to both guide and support the teams in the research that they're doing, in the spirit of democratized research, as well as drive the bigger topics that are going to lay out the roadmap for that team. You're saying a researcher, in your case, or in your practical example, can work on three cross-functional teams, but that also means a researcher has the domain responsible for these three teams, when you say every team should have this one person that is responsible and in charge. And I would also like to know how big a cross-functional team is. The way to think about it is not that they are responsible for every cross-functional team, but more that they work on the themes that these teams work on. So you got to zoom out a little bit to frame the problems on a level where they are relevant for a number of teams. So not working on the deep dive topics of every team and participating in the rituals of every team, because that's obviously, if you're supporting three teams, you're noting no time left in your week. So really zooming out and working on the topics that will feed multiple teams, and that means you need to frame them at the right level. But that they do still support the ongoing, the iterative design, deeply design-connected research, which then needs to be done through tools, through coaching, through more of this process support and guidance than doing it directly every day themselves. Cool. All right, then just looking also at the time, trying to wrap it up a little bit. One thing that I'm curious about is looking back also to your career and scaling teams and working with teams of different sizes and also different organizations, because maybe looping back to the very beginning and to the intro, you've not only worked for companies directly, but you also worked with IDEO, so more in the consulting kind of space. What are the biggest learnings or what are the things that you would say you wish you would have known already at the beginning? I think when you start your design career, you're so focused on craft, and it's a really important part of being a designer, of course, whatever kind of designer you are. But I think what I've learned over time, and I wish someone had told me back then, is it's as much about the softer skills and the collaboration skills and the mindset that you bring to the work, the role that you see yourself in, rather than just, can you design an amazing screen? I think a lot of younger designers beat themselves up about not feeling perfect in their craft, and as they grow, they'll see that actually that's just one part of the puzzle that makes you successful. That's definitely something that's become very real as I've grown in my role. I think a second thing would be that you can't do everything, and you don't have to be good at everything, but you need to understand and respect all the different aspects. There's this idea of the full-stack designer, the unicorn, and I've definitely met a few of those, but there's a reason there's a few of those people I've met in my life, and they stand out, they're a jewel, you're so lucky to have them. But most of us, we're just, we are great at some things and not so great at other things. And then our responsibility becomes to understand what we don't know, understand the limits of our skills, and appreciate what an expert can bring or do. And in the product company context, that expands to even understanding other disciplines like marketing. How does marketing make us successful? How does data bring success to us? Or what is the craft of being a great engineer? So really respecting and understanding other disciplines. And I think the third thing I've learned is probably that a lot of my work will be about translation and learning to speak other people's languages and trying to sort of bridge the gap. Because when you're in design school, you spend so much time learning the language of design and being able to speak it well. But then in your working life, you realize, oh, that just keeps me within a much smaller circle. Actually, I need to learn everybody else's language as well. But that's the great thing about the design process that actually it is this process for collaboration, for bringing other people and other points of view and other sort of mindsets in. And that's what's great about it. That's why it's a successful process. Spending that time to learn and respect other languages and learning to speak them, I wish that was something I'd learned. Great. Thanks a lot. One last question. If people want to follow you, where can they find you on the internet? I think the best thing is to find me on LinkedIn. I will respond if you reach out to me there. That's a really good place to find me. Great. We will make sure to link your LinkedIn profile. And with that, thank you very much for being here. Alex and I will now jump into the debrief and wishing you all the best. Thank you. Thank you so much for having me. Bye-bye. What a deja vu talking about scaling and organizing design teams with Schruti. Christian, as usual for our debrief, I would be super curious on your view on today's discussion and the main things that you're taking out from today's conversation. One thing that still stuck with me was this whole conversation about design ops or ops in general. And I do have to say I'm very critical when it comes to operational positions in companies. I do agree that especially in design teams, there is so much overload of work where ops people can help. For example, on a product management level, I do believe that it's rather solving symptoms than problems where I have to say, if you come to a point where you need an ops person in your team, there must have happened a lot of things. There must a couple of things gone wrong before because to me it's more a process issue than a workload issue. Yeah, I would slightly disagree because the reason why you need to ops is that you are in this place in the first place. And if you really want to have someone focusing on these processes and making them better, you need to bring someone in. And I think especially in a bigger organization, you know, and even in small organizations, you don't have the time to fully and solely focus on these topics. And that's where ops play a big role. And I think like having someone who can spend the time on thinking it and constantly also tracking and keeping an eye on the processes and optimizing them, I think it's a super important role. And I think it's something that will actually contribute to having a very successful organization. I do have to say, when you have a team that is growing, the process part should be as important as working on the product as well. So yes, in hyper growth, it's definitely not easy to find the balance. Nevertheless, the reason why many companies get there is because they are not spending in first place enough time on defining good processes. Bringing someone from the outside in is definitely helpful, but many teams are not spending enough time in the beginning already to set the clear boundaries and the clear processes up front. And I think it's not only like the processes that they set up front and the processes that they apply as, for example, product manager or as designer or as researcher. It's more around connecting the different teams. And I think it's useless to say that nowadays pretty much every product organization tries to move into an agile way with cross-functional and independent teams. And especially with independent teams, there comes this problem of misalignments. And you need to make sure that you focus on making sure that those teams are aligned and to make sure that there is communication between these teams. And that's something that without ops will be very hard because you would have to ask, for example, a PM or a PD from a team who has to look at his process specifically and the way his team needs to work and the way he needs to work on a daily basis and ask him to also keep an eye on everything else. And if you have someone who can have this big picture, this zoomed out view, I think it's really nice way. If cross-functional teams or cross-functional autonomous teams are not aligned, then I want to ask the question in first place, how is that happening? Because this goes against the basic idea of having cross-functional and autonomous teams. Because in that moment, you would need to bring in ops people for literally every department. I'm not saying that I'm against it, but I'm rather a little bit careful in hiring such positions and challenging myself as a company or as a team leader. lead to ask, OK, is this something that I really need now and am I fixing a problem or am I empowering steady and faster growth or do we have a basic issue here in terms of processes that we need to revisit and fix in order to make sure that we can continuous run scale better? Yeah, but then still, even the simplest aspect of something like tooling, who should look at it and how do you align between it if you're working cross-functional teams? And I think maybe to illustrate it even better, my question back is I think DevOps teams nowadays, it's impossible to think them away. I'm not sure. I cannot think of an organization without DevOps people, especially because of all the infrastructure and everything that you need to have in place. So why is it solving a problem for developers and not just like curing symptoms and not for other functions? The question is, are we talking about a DevOps department or the DevOps role itself? Both. I do have to say, when it comes to the whole aspect of having a DevOps teams in engineering, yes, that makes absolutely sense, especially in faster growing companies. But when it comes to tooling and all these kind of things in product and design, I see this also in the responsibility of the drivers of those teams, for example, the leads, to make sure that you empower the team to find answers to those questions instead of bringing people from the outside. Again, these people can for sure help and make your life easier. But I'm saying I would be careful in jumping too fast into hiring someone instead of challenging yourself and saying, hey, what do we need to improve now to avoid a bottleneck in the future? Yeah, and I think definitely don't hire for the sake of hiring and because it's a trend and because there is a lot of articles now popping up. And it's not now, it's pretty much like also the last two years probably where I see this conversation getting some traction. Nevertheless, and the way Shruti put it, I think it's a really good way to have like a partner that can help you focus on these things because you, and I agree, it's the leader's responsibility to look at these things. But at one point, it's unfeasible to keep an eye at all these things while driving a strategy, while making sure that you're also aligned on a C level and so on and so forth. And there such a partner makes sense. Absolutely. Yeah, so we agree on that. We agree on that. Be careful when you want to stock up your team. But other than that, it was really interesting to me to see how the whole processes and collaboration works in such an organization, especially with this design sub-teams that Shruti was mentioning at the beginning. Yeah, I think simply making sure that you have this alignment and making sure that you have the teams small enough that they're still productive and that you can collaborate and that you have these functions in place to also keep an eye on the bigger picture. I think that give people the focus that they need on their work and to simply also allow you to work on a faster pace without getting slowed down by too many people in the room. And I think probably there comes the pizza rule. The two pizza rule. Yeah. Of also productive product teams, I would say probably you can use this as a guideline for all sorts of teams or functional teams, but just keeping them all small enough that they are productive. Good point. Alex, one thing I would like to mention at the end of our debrief is based on our discussion with Laura previously. In case you think this podcast episode was helpful for you, feel free to share it with your network, share it with your friends, share it with your colleagues. And other than that, you can follow us on social media, LinkedIn and Instagram. Just look up for Product Bakery or contact us alternatively at hello at product-bakery.com. And with that said, we will talk again next week with new interviews and episodes and wish you all a beautiful day. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye. Bye.