Establishing a product & engineering mindset in a hypergrowth startup - with Urbi @Trade Republic

Welcome to another episode of the Product Bakery podcast. Today I have the pleasure to be here with my co-host Alex as well as a special guest from Trade Republic, engineering manager Andreas Urban, who will be further called Urbi. Public Static World main people. So serious. Urbi is it's a really special episode today. It's I mean, we had some all over the internet recorded remotely. And today we're sitting together and we're at Christian's place. Christian opened some bottles of wine. What are we drinking today? It's called Bacchus, a special white wine version that Urbi likes a lot. Awesome. So white wine from Germany and a guest from Germany. Urbi started studying business administration before he then decided to move to computer science. And now you are engineering manager at Trade Republic. So maybe from business administration to engineering manager, what's happened in between? Yeah, one of my most important mantras is that you learn the most out of failures. So I started my career with a big failure when I decided to study business administration. Luckily, it took me only around three years to figure out that this is not gonna work. At some point, I went back to the things that I really understand and decided to start studying computer science. And from that point, what goes through your mind before you decide to start studying computational science is that you think, okay, you will be only surrounded by nerds, and by really strange people. In the end, when you start studying, this prejudice is completely fulfilled. But when you then start go into companies, you realize, okay, a company consists of a lot of different people, different mindsets, different characters. Also, the people in technology and engineering, are coming actually from all the corners, and lots of them didn't even study. So you have a really interesting variety and range of different mindsets, different characteristics, different individuals that come with different motivations that have different ideas of how it's going to work. And that makes us all really interesting to work together. And that is actually the basement to get a lot of different ideas from different corners from different angles that you can then use to actually develop the best way find out the best way experiment and find the best ways really make something work, getting more efficient, getting more productive. That's the thing that actually then kept me there. As someone who started computer science, would you see yourself as more someone from the nerdy corner or not? Partly. Sometimes I really like to dig into those complex problems, and try to solve it, try to nerd around the different solutions and the reasons why something is behaving like that. But also at some point that I've just think, ah, come on, there are so many more smart people than me that can solve this problem. So I should maybe take care of something else, go drink some Bacchus. Run some podcasts, series. Exactly. So actually, that might be really an interesting question when you transform from an engineer to an engineering manager. There's also a reason for that. The reason is just I'm really interested into the technology parts. But I know there are a lot of more coders around me in whatever company I am. So the people that are actually writing the code, that are providing the infrastructure, that are talking about the architectural design, they are much smarter than me. But probably I can handle a bit better with people. Was it something you always knew that you want to become an engineering manager at one point? Or at which point did you like for you understand, okay, I better go down the route of managing instead of being an individual contributor? Because I totally agree. And I see the same with myself. I think there's also a mindset thing between being an individual contributor or managing the team, which is like more around, I am good at steering different people, connect the dots, working cross-functionally, like getting everyone together and getting the best out of people instead of sitting down, heads down, fully focusing on, for example, building the perfect prototype or writing tons of different interview guides and so on. So when did you understand that you actually want to become a manager? That was actually someone else who understood it for me. That was my former boss, who was actually probably the best boss I would ever have had. And I learned a lot from him. So big shout out to Uli from here, who decided for me that it might be a good idea if I transition into a management role. So he asked me just at some point when we grew a lot, if I would take over back then the QA department. And if you get actually an offer like that, and if you have someone who thinks, okay, you might be the right person for that. So we would rather prefer to go with you instead of hiring someone from the outside. And you think, okay, if he thinks that I'm the right guy here, he might, he might be right. He's always right. Exactly. Of course, then you have also to accept this offer. Otherwise, you would just think, yeah, half a year later, why didn't I at least try it out? So I thought, yeah, at this point, I have to try it out and see where it goes. You transitioned from engineering role to lead role. And now you are leading the engineering team at Trade Republic. What is your mission? That's a really good question. I would I would say, depends when you ask me, my answer might differ every other day. Today, my mission as engineering manager is to enable the transition of the engineering department to fully scaled engineering department. Not only engineering department to a fully scaled product engineering department. That is also an important point here that we really come closer together with all the affected departments. Actually, so you need to come together with your neighbor department to really work closer together. And at some point, when you are close together, you might have a new neighbor with that you have to come together and also build a relationship again. But yeah, I would say transitioning the current structure to a scaling product engineering organization. Would you see the product and engineering department as rather two separate ones or rather or in the future as one department? That's a suggestive question, I would say. I mean, we're sitting here like talking about products. I guess. I mean, the suggestion is definitely there. But yeah, totally curious to hear your view, especially from engineering perspective. I learned it actually one year ago. That was a moment last year, maybe one year some months ago, where I had this switch where I understood it, that product and engineering are not two different departments, that they're actually one department. They really need to work closely together. Otherwise, you can't go really in iterations. I mean, the reason why we're talking today is obviously that product and engineering in companies sometimes struggle to collaborate. And for us, it's interesting to see from your engineering manager perspective, what, for example, an engineering department needs from a product department to be enabled and to build the right things in the right way. In your current position, or with your general experience, what are the pitfalls that you see? And also, what are the challenges or improvements you're working on to get there with your current teams? Mm-hmm. What engineering needs from product might also be the same that product needs from engineering. The first thing is to understand each other. So that means, of course, a lot of communication and collaboration and willingness. Willingness to come together and then to have this conversation of what does the other one need. And for that, you also need to understand, of course, where you would like to go. Why do I need to understand engineers as product manager? Why do I need to understand product managers when I'm an engineer? That's the requirement to come together. Because if you just think, okay, I'm responsible for designing cool products, or I'm responsible for writing cool microservices, then you won't have this mindset actually to come together. So you need to understand that both are really important to build the product from end to end. So that means it begins with the idea, develop, find out the problem, evaluate the problem and develop the solution together. And also collaborating, continue the collaboration, getting the feedback early, then adjusting according to the feedback that you get in best of the cases directly from the customer until you really have a fully fledged product life and see it running, see it being used by the end user. How are you currently structured within the product? and engineering organization currently we are perfectly structured because we already of course applied all the lean principles and are already it's a cool company it makes it possible no in the moment we are in the middle of this transition where we can you can you maybe give like a couple of concrete examples on things that are going on right now or ways you you try to to get there or moving to this transition I don't know exactly what I can say without getting slapped later on when this episode is public but I can definitely talk about some of the usual pitfalls and some of the failures that you can make that you might also at some point need to make to learn it to learn out of it and to adjust and to find a better solution but I can definitely say is where we also coming from so we are coming from a point where we have only really a few engineers that developed the whole system all together with really only a few kept a few capacity on engineering manpower and they did really an awesome job what was possible back then because if just for people working on whole platform on a whole backend cloud system then you don't have that much interaction necessary or needed and you can also work closely together with so probably back then one product guy to develop it really in that way and create a cool really nice product the challenge comes then if you decide to scale and to boil it up to maybe 50 people engineering department because then this communication doesn't work anymore the first mistake that you can make is things that you can just add people and maybe then just put people into different teams and assume okay I can continue like I did it before when I created this awesome product that was so successful at the market that also caused another big funding round but you need to understand that you that this transition is necessary and also you're bringing a lot of new people in that don't have the knowledge that you that these people have and actually developed as a core product and to that point and usually most of the stuff is also not documented because in the early phase of course you focus on really the plane development and bringing a product life satisfy the customer and make it a first big success something that I've seen also a lot is that this is a little bit also related to how some people or sometimes management understands a job which is like you don't need documentation or you anyway have those autonomous team so you can add people and they will just go and everyone builds their own kind of stuff and at the end you have this this amazing product but I totally get you you need to have this alignment documentation consistency like in all sort of teams and departments especially when when you start growing I think it's also even written in the HR manifesto is that HR is easy to understand but hard to implement actually I see that most of the people don't understand it like this documentation thing what is meant with that is that you don't sit months and months and months and analyze and write a comprehensive design document before you start implementing but of course you need to you need a decision log so you need to understand why you had why the team made what decision you still definitely needs a technical documentation because otherwise it's really really hard for new employees for new engineers to understand the software and of course you need also the documentation anyway that is needed for other people to be used like API documentation I like also feature documentation you have probably a back office system that also need to be understood you need to understand the app of course and then you have of course also the front-end components that talk with the back-end components and they have also an interface and this needs to be documented and here you also need to understand from the back-end perspective how the front-end is working what the app is using what the app needs and of course from the front-end perspective you need to understand what you can get from the back-end system and also how to communicate how to find the best interfaces all together that are fast to implement and also still provide the according speed so also to not introduce new latencies and slow down the requests. I think you Christian told me this also like the last time when when we talked about documentation and Agile and so on and I think it's totally fair point also to say it's definitely also related to when the Agile Manifesto was written back then companies were massive and documentations had a completely different role but it's also true that now we are on a different state so it's not like about like I think we went in writing less and less and less documentation which is a good development based to old-school massive operations but as small startups start growing more and more again you need to have this this level of documentation so what I took from you is focusing especially on having decision logs having like some let's say documentation that's needed at least to get new people in I would also add this aspect of making sure that you have all the knowledge documented so that you're not so strictly related to this one person that has all the knowledge owns all the knowledge and whenever they decide to leave the company or not you lose everything right? Exactly, that's also one of the most important points for documentation that's also by the way something that we are currently doing with the new engineers that we onboard so of course we have this little pool of people the small pool of people that developed the core product and what is totally understandable is that most of the knowledge is in their heads so what we are doing with new engineers is let's them work closely together and let them explain from the experts how the system most of the cases a subsystem that is owned by a team is working and the new engineers are responsible for documenting it so then you have also this review process and you know first of all that the new engineers understood it then you have to review process and you produce even something that was really nicely documented with at least four eyes and what you get out of it is a really nicely onboarded engineer and documentation that makes it even easier for the next engineer. That's really cool a question on that point when it comes to the whole documentation part as we all I think agree is that you reach very fast the point where you have to start documenting things in order to be able to continue scaling. Another remark here on the documentation why it is also important to document the decisions is the alignment because an alignment does not only mean that you talk about something and then come to a decision to a consensus sometimes if a lot of people are in a room and nodding and everyone said its opinion it doesn't mean that they are really aligned. That's the reason that you write it down and then everybody should review it again so they can see okay but what we have written down here is really the thing that we aligned on so and otherwise you can fastly go into this risk that people develop different things because they actually understood their alignment differently. I fully agree with that. It would be interesting for us to understand how this whole part of the feature documentation works especially in combination with the product managers. For that question I would probably go back to the question that Alex asked some time ago about what do engineers need from product managers because it it pays nicely in into that question and also at this point we could also talk about what product management needs from engineers but first of all what we need from product managers is of course to understand the business problem to understand the business problem early so what we would like to have is early involvement for a new feature getting looped in early then the idea is kind of at the point I would say when the idea is evaluated when we know okay this is something that we definitely want to do because we have also some data or objectives that we know okay this gets us 20% more customers or this gets us 20% more trades or more revenue or whatever or we save a lot of money that we currently pay for something so if this is evaluated then the stakeholders of probably not even only product and engineering probably also compliance marketing and whatever departments who should be involved should come together do a kickoff where you talk about the business problem and not about the solutions that maybe someone has in mind you really talk about the business problem and then you kind of probably one way is to break it down from the customer perspective how the new thing should look like or should solve the customer problem and then you can already brainstorm about the first solution that would be possible if you do it separately or if you do it before you talk to engineering you maybe come up with an idea that is really hard to implement and not even solving the customer problem perfectly but if you talk to engineers early then you also can get some insights on what is actually easy to implement what is not easy to implement and then you find maybe even a way that is cooler that actually provides a better user experience and is even easier to implement or is maybe not easier to implement but has less dependencies but in the end makes it easier to I think that's also what Alex and I talking a lot when it comes to clarification about the problems. And I personally would say, even in the evaluation phase, it's sometimes a good thing to involve engineering. So customer interviews, I'm always a big fan of doing it together as a small group with an engineer and the product designer to sit down and really try to understand what's going on because this helps also the engineers to go back to the team and share the problem they have observed. Because, you know, people, I mean, it sounds a little bit weird, but you get used to a product manager telling you all the time what the priorities are at some point. But it's sometimes really cool and nice when the engineers really see what's going on and can share it from their own perspective within the team. Yeah. And I mean, I have to say, this is also where sometimes the beauty of things like a design sprint come in. And I'm really not the design sprint advocate because I think there are good and bad places when to use them. And especially when you follow too strictly the whole framework, it's also very dangerous with every other framework. But I think there is just like this huge benefit of if you involve all three parties, engineering, product and design, and you have the business side, the technical side and the more customer centric side. I mean, an engineer can provide you with so many useful ideas also for solutions simply because they know all the technical limitations and they think more about that specific part. And the same goes for the product. And I think it almost sounds like engineering has a similar problem than what I hear often also from product designers in different organizations, which is this, we only joined the party way too late. There is already a solution out there and we are like making a solution look nice or something. And this is exactly like what I'm hearing from you and from you, Christian, right? In theory, you get everyone on the table, you try to combine all the three parts to then start thinking about the solution. When you have a problem, when you have the limitations first, when you understand what the business needs, what the customer needs and what we can achieve. And then you kind of pull those things together and you come up with a solution and you build it and ideally test it. One of the biggest mistakes I've made in my career was not to not early enough involve people. I think one of the biggest mistakes I've made as a product manager back then was believing that I'm smarter than the rest of my team in terms of sitting down with maybe one product designer, sketching out a solution or sometimes even by myself, I'm even embarrassed to mention it. But it really happened. Especially at the beginning of my career and I've seen this many times with junior people thinking about something and then just pushing it into the team instead of having the discussion and the conversation and the brainstorming that you mentioned, Urbi. That's to me a big pitfall for product people. So I think 10 heads or five heads are always smarter than one. Definitely smarter than yours. What I just want to add is a lot of people hesitate for this early involvement for the reason that they think, okay, I don't want to distract engineers because they are focusing here currently on this feature and want to develop it. And also then they come up with a lot of ideas by themselves and then they start actually kind of the technical discovery and then the idea or the solution is pitched and we break it down into stories. But it's then actually really cumbersome but in most of the time takes more time than having the early involvement and also causes a lot of misunderstandings and also frustrations in engineering because there is already a solution that doesn't make sense to them. Having this early involvement saves first of all time and it's also actually not an anti-pattern to involve them early and then not start working on it. Because of what you usually do, then you have probably also to clarify a lot of compliance things, sign contracts, do some other specifications. So actually then you go back to your department and do your work until you then go into the delivery phase or the phase where you actually break it down into smaller increments. And at this point, the engineering teams go also back and continue with the current work that is in delivery. But because it's also nicely documented, most likely after the kickoff also visually documented, you don't have a really hard job in coming back into this topic at some point when you go back. I love that you brought up the fact of the distraction because I totally think it's something especially and this is definitely related to some of the kind of the picture that you have from developers heads down in the tunnel and so on, working on some stuff. And I do ask myself the same thing, can I distract them? Can I pull them out of their zone and get them involved? But what I'm curious to make it more practical, if we think of traditional sprints kind of rhythm and you have an upcoming release and so on and so forth, what is the cadence or when and how often and how much time can I actually get an engineer on this kind of discovery track? Or how would you suggest setting the teams up so that they can successfully balance the delivery and the discovery phase? So some scientific studies say two hours and 17 minutes per week. Did you make those studies? Just a minute ago. I think that's the headline of this podcast. You need to spend two hours, 17 minutes a week on discovery, quote Warby. I would indeed come up with a rule of thumb that you say you have maybe one of those comprehensive sessions a week. So that's totally fine to get developer out of the current focus because there's also a planned meeting where he's prepared. Of course, you also plan this meeting in a way that it's before or after lunch. So that there is only one distraction and not two. But in general, this is at least out of experience, a good rule of thumb. Otherwise, it's of course also a bit of common sense because if you do it much more often, then you can actually work on features and you should really try to focus in your sprints on, in best case, of course, only on one feature. Maybe you can also run in parallel and try to implement two features at the same time. If you have more than that, then you actually slow down your delivery speed enormously. So you should really take care to focus. And if you have seven features as a pipeline or 20 or 100, it's of course too much. I mean, you need to do it in a way that it fits into the company vision and strategy because some of the features that are needed to be done from regulatory point of view and some features that might be really beneficial for the company success at all. And those should be with high priority, of course, and also be taken into consideration. Also, you need to take care that you don't have it too less because if you end up with an empty backlog and the team has nothing to do, that's of course also not much motivating. And if you have something like that, so that you also, that's actually a nice picture of all this HR onboarding sessions where you have the backlog, where you have the small items on top and where you have the middle items in the middle and the big buckets down the road that are really just roughly discussed that are probably in the kickoff phase or something like that. So it should look a bit like that. So then you have maybe two of these big topics in the bucket on the bottom. You mentioned that you do such meetings after lunch for less distraction, but you also mentioned that your team should focus, which I think is really important. But if you look at the real world going on, you have like many people having questions. There are a lot of communication going on between teams. Sometimes you have different stakeholders from different departments who directly are reaching out to not only the product manager, but maybe to the engineer. How do you deal with that? How do you make sure that your team stays focused? Communication is also a tough challenge sometimes, because that's also something that you observe in a lot of companies that experts are usually being approached directly from every direction. And you need to somehow take care that those distractions are getting reduced with rules that you set between the organizations, between the departments. And we also need to introduce those asynchronous synchronizations where you have probably some respective Slack channels where everyone can put the question, don't approach people directly, but just the team. And at some point, one of the team will answer. As soon as he has time and is looking into Slack. At this point, you also know, okay, he's currently not just in the tunnel and focusing on something, so he can resolve those questions. You could also use other platforms that are given to you. Like if you are part of stand-ups, you can also use the end of the stand-up to ask such a question, because I think most of those questions are easy to answer. And if you have a more complicated issue, then of course, it's also fine to schedule another session where you take the experts together and discuss this issue. Usually you can also discuss in the stand-up, oh, okay, that's a bigger thing. Okay, then let's meet together or let's just take it offline and do it directly after the stand-up. Those are just... So if you apply a culture where you respect each other's time, it should actually at some point be a no-brainer to implement those communication channels. Is this what you would like to have or is it what is really happening right now? This is what we are trying to introduce. Sometimes with more success, sometimes with less. When you're scaling, you don't have the culture ready yet for start-ups. You need to implement the culture. It's nothing that happens in four months. That is something that takes really a long time and you can already be happy if you make step-by-step process and really make process to the better. And if you are in this phase and actually you are actually already doing a good job as a company. I see you're mentioning it as part of the culture. I mean, it's an, I think like what's, what I'm interested in understanding is where the difference lays between process or something that you could also top down, tell people, okay, you need to use the channel. And what is the culture or how do you change the culture? Because for example, exactly what you mentioned around experts, um, the thing of there is also people who are with the company for a longer time, they have more knowledge and so on, and it becomes natural that you approach them. Maybe it's also even harder for newcomers to position themselves as experts simply because of this natural kind of way, how questions transition to the older and, or maybe even more extroverted guys. So, so I really think, yeah, but I really think like this culture is exactly like the right thing to start. And I'm wondering like, what's the best to change a culture. Here I can tell a story where I just had a chat recently, yesterday evening while drinking some wine. You have a friend who has a child and is always wandering in the discounters when people, when they are at the, in the front to pay, where you have all this shelves with the little sweets and stuff. And of course the children would like to have the sweets and if they don't get it, they are starting to cry and to shout and to slap the parents and are really making trouble. And Sounds like an engineer. No, I was about to say it's not, it's not only kids. It's also me when I'm in the supermarket with my girlfriend. Actually, it's, it sounds like you're on the company at lunchtime or someone puts a cake somewhere. You are on publicity, not saying your boss, right? Yeah, we don't cut something, right? No, it all stays there. Like, I think it's important that it stays the way it is. So you, the supermarket? Yep. She has a child and she also wants to have five kinds of the sweets. And she says, no, you only get one. And then she said, but I want to have five. And then she says, okay, come on, child. I don't know how extra parents doing it. I only have management experience. Yeah. But she, she said, actually, she's just having a eye to eye conversation and is explaining the reasoning and is explaining it, why she can't have five, why there's only one and that the next time she can have another one and just explaining it and coming to a consensus or at least consent. And this is exactly the golden rule that you have to use or that you should use. When you also try to embrace a culture, you need to explain it. People need to go to people and explain it. And if you're not a complete idiot, then you should also be able to explain the reasoning quite good. And then usually your peers can't invalidate it and see also it makes sense. Then you start to have this relationship and you start to get this understanding. So most, most of the issues are just coming from understanding each other. Speaking of your relationships, how is your relationship with the product leads and the product manager? How do you collaborate on a daily basis? Definitely a lot. This varies also a lot depending on how is it currently set up and what are the current topics that we have. So is it something that is technical feature related or is it something for the general process improvements? When I look already a bit into the bright future where we have the respective setup, then of course I definitely talk to my product manager, to my product lead daily and more times daily, like also in the bright future when I deploy several times in an hour, I will speak to my product lead more than once an hour, this is really important. So in the current phase of finding the right structure for the product engineering department, it's actually hard to say yet because we don't know exactly how it will look like. It really depends what will be the exact solution, but in the end, you will somehow have this triumvirate, triumvirate of process lead, tech lead and product lead and those three will really collaborate on a daily basis definitely, and we collaborate a lot and yeah, make a lot of decisions together and make a lot of coordination together. Here would my question be also now to circle it back, what does the product lead or what does the product manager, what does the product designer need from the engineers? Speaking about the designers, I would say it also ties a little bit back to what we discussed earlier as a designer, there needs to be like this open conversations and open participation. I think both the designers need to create this openness of trying to understand more and more also where engineering is coming from and I think engineers need to somehow have like also the patience to explain certain things. So that you come to this point where you collaborate on solutions, problems whatsoever early in the process and throughout the process. And so that there is also the mutual respect. I think often like the roles are so different that designers are the way sometimes engineers are seen as like the nerds, which they are not. Designers are sometimes seen as like these creative artists that nobody really understands. And I think building this mutual respect and collaborating and working together and understanding that you are working on the same goal and trying to get the different perspectives in and combining them, that's probably the most important to me and because the designer can only design after understanding what's feasible and how it's feasible and how it works and really come up with the solutions only with that basis in mind. Here I have a question out of your experience, how the designers usually feel if they are getting feedback from engineers to change the design or to adapt the design to different aspects that they provide, how do they receive this feedback usually? This really depends a bit on the designer and the culture. And I think it's, it really differs. There are definitely those kinds of personalities in the design world who are very much in love with their ideas, but I think then that's the wrong person to have on a team. And then you really need to also as a design manager, sit down with the designers and try to get them to a point where they better understand also where engineers are coming from and again, where this mutual respect comes from. And I think the good designers or the best designers that I've known in my career have developed exactly this understanding of, okay, if an engineering tells me something or if an engineering tells me this doesn't work and he explains it to me and doesn't bring it to me from a point of like, I'm the engineering, you anyway don't understand what we're building and we can't do this. Again, it's like this mutuality. And if the designer can come out of the conversation and be like, okay, I, I understand that we can't do this because of X limitations. And because from a business perspective and here is where product also comes in place, we need to kind of look at a certain timeline and cannot rewrite a whole backend because a feature is designed in a way where it needs it. So yeah, I think like if feedback is not well received, you need to work first of all, on the designer's mentality and maybe also on the engineer's mentality of how to communicate it. And I think it all comes from this mutual layer of, do we respect each other? Do we have a culture in place where we understand that everyone is the expert in their field and that we all have the same goal. At which point the engineers asked to, to change design. Are you talking about the preparation phase or are we talking about while stuff is kind of already in the sprint or has been started to develop? Because my question would be what, what went wrong before that it happened that something needs to be changed because ideally the better you plan, the less you have to change, which doesn't mean that you never changed the plan. That's a very fair point. Yeah. Actually in my, the things that I currently try to apply. So where are we really create this product engineering organization or where we actually, here I have to quote my colleague Philip, that we are doing the same that engineers are doing. We are engineering the product engineering organization. So we really apply also engineering techniques to do it. And so there is already the water flowing together in my mouth when I think about this product engineering organization, really working closely together on a day to day basis and really develop. And bringing those small batches live and improving a lot over iterations to develop the final feature at some point. And what I just wanted to prepare with this little story around is my question. How do you see the creation of designs in the future? Do you also see that there might be a trend to also develop the design together in such a group to also maybe extend it from having the kickoff where you develop the flow, the ideas, the solutions, where you can actively work together with engineers, probably also with other people to develop the design. Before answering that, I just want to go back on one of the things that you just said, and I'm trying to think what it was. It sounded so amazing. I mean, it's the wine. Yeah, it's probably the wine. I think you can go just back here because we recalled it, by the way. Yeah, no, because we don't cut it. It's all, all natural. No, but I already forget that. Oh yeah, now, now, now I got it. Now I can remember. It was just like a comment on, you mentioned how to apply engineering principles or processes to designing the engineering organization. And I think this is another kind of place also where I would really love in the future seeing the three roles working closely together and applying even further. Like I think, for example, design thinking is getting more and more also into the world of business and vice versa. Even when designing those processes, principles, and the culture, you try and get the different strengths of frameworks and ways to use the designer. This, this has like a great opportunity. So getting back to your question, I think we touched on this a little bit when we also discussed design systems in the past. And I think like there is definitely also trends on how the development processes are evolving and you're going much more into direction of working with preexisting components, trying to really focus on constantly improving and involving a specific components and iterating on that one. So I think that we're anyway, moving more towards a more integrated process where the line between code and design should almost be non-existing and it should pretty much be the same. And you can also already see it, like with some great companies like Airbnb, for example, going into example where they start their designs by converting the react files into design and using that pretty much as their framework. So I think boundaries get much more blurry and get much closer together. And they're like, it should definitely be integrated. And I think designers need to work cross-functionally. They need to be in the team. There should never be like this handoff. There needs to be a lot of small iterations on the design, starting with very low fidelity of really just trying to think of flows, trying to think of like the individual screens and interactions, and you should constantly get the feedback of the developer. So also as Christian mentioned earlier, it should almost not be the question of how are designers receiving feedback, but when do you receive the feedback? And what is it? Obviously, like if you're at the end of like, I don't know, a month of designing a feature and validating it and testing it with users, and someone realizes that you can't build it, that's obviously like, the level of frustration is just like so high. I think there are also usually at some companies you have anywhere a designer directly being part of the team. Yeah, exactly. Like dedicated designers per, let's say, I mean, if we follow Spotify model per squat, it's like the best. And I mean, of course, depending on the needs, you can have like a designer overseeing two streams, or you can have like two designers on one stream. And so on. You obviously also need to have good collaboration between those teams, but having a dedicated designer and having a designer and a product owner and the engineers working as one team all the time, building the strong relationship, building this mutual trust, that's to me the key for a successful product and engineering organization. That's actually very nice to summarize. And this is what you're obviously aiming for right now at Tragedy Public. Did you, by the way, already mention that Spotify is not using the Spotify model anymore? I wrote about it on my blog, by the way. We didn't mention it. We should actually have a session about it. Now the audience knows. Now the audience knows. But talking about establishing this mindset and this culture of mutual collaboration, what actually motivated you back then to start this challenge at Tragedy Public? What were the indicators once you applied or once you got in touch with the company that were telling you, hey, I'm able to drive this big project here and I'm getting empowered to establish this kind of culture and collaboration and supporting teams to build great product? First of all, during the interview process, I learned that they have already a lot of those ideas that go into this direction. So I knew that they have this really state-of-the-art mindset and want to go there because whether if it's exactly that way or if it's that way or if we apply this structure, but they knew, okay, we need to have this transformational change, this transformation to a scaling organization to succeed further. So it was clear, okay, they see the value and they see the need to actually apply it. At some point I was even thinking, okay, they know actually already very well what to do. They don't need me. But then the CEO called me and said, yeah, actually currently, but it's not working that well. So we definitely need some cultural change. Then I also saw a need to be there. That was really honest. That was really nice. And I saw, okay, the basic mindset is there. I'm sure I can gain the trust by management to also fulfill this role and apply those principles, try to enable the transformation in the end. And that is also, to be honest, what is currently happening. So you were almost hired with that mission in mind. It wasn't. Sometimes it also depends on where the pressure comes from. Sometimes the role of an engineering manager is seen like, aren't you the guy who's responsible that the team develops a feature on time? No, of course it's not. At some point we enable that for the future, but really it's to enable this transition of what means that it also creates this culture, helping to embrace this culture that is necessary to make this transition a success. Awesome. Orbi, I really loved the conversation. There are some super good points and I think it was super helpful also to talk to an engineer and to have an engineer sitting with us. From my side, I would say the best of luck to have a successful transformation and building a successful product organization. And thanks a lot for taking the time to sip some wine with us and discuss all this. I mean, the wine's not empty yet. We have some bottles left so we can continue the conversation, but. I can just say, likewise, I really enjoyed the conversation. I really enjoyed the wine. I'm looking forward for the other bottles. I really love to also share what we've learned, where we failed so far. I'm also sure that we are talking again, so I can tell you more about the success that we will have and probably also for the mistakes, the failures we did and we learned of and made it even better. I wish you also a really good luck with your next podcast episodes. I'm really excited to listen to the other ones because I know what was the content of this one. And I wish you a lot of success and for the audience, bleib stabil, because the struggle is real. Thanks for this last nice half German quote. So as always, Alex and I will now quickly dive into the debrief and thanks again, Urbi, for being here and looking forward to talk to you again. Awesome. Bye Urbi. There he is. So Urbi is still watching us. He's having, can we say cigarettes on a podcast? Is he having a cigarette? Yeah, he's, um, no, uh, no, no advertisement hashtag, but yeah, I mean, Christian, I think some really nice takeaways was an amazing match to get an engineering manager who is currently working on restructuring or building a strong product engineering organization in, in a scaling company. So, I mean, yeah, what, what are your, your key takeaways? Well, um, first of all, I really agree with you. It's always very good, especially from our products point of view to get the engineering side and the engineering, um, point of view. So one of the key takeaways for me was first of all, the honesty about things that are working well and also things that he's working on. I was actually really impressed about how important culture is and also education. I like the example of the child with the result of really explaining to people why things are, as they are. As painful as this might be sometimes it's absolutely needed. If you want to build up a healthy organization and also an organization that is able to scale. On top of that, I also really like the fact that, you know, I'm not really liked the way he tries to protect on one point the team, but on the other hand really asks for early involvement from product management and enforces the collaboration between both sides. And the most successful projects I've done were really based on this key values to have a strong communication between each other, like having a daily conversation with the engineering managers or even delivery leads if you have this. So my key takeaways is it's first of all super important to be honest and to educate and on the other hand to really make the proactive step into the direction of the, in quotes, other side. How about you? Definitely like the cultural aspect. Besides the cultural aspect, I also love the conversation we had around documentation because I think that's something that often gets kind of left aside and it plays such a key role, especially when you're scaling. And I would totally consider applying the method of using new starters to write documentation because they have this fresh mindset and it just like hits all the needed points. So I think like, yeah, that was probably one of the things I liked the most. And one thing to further dig a little bit deeper also in the future is exactly how you mentioned the importance of like explaining people. And I'm curious, thinking of like organizations that are even bigger and probably like sum up was already like at a similar size and everything above there. You reach a size where even the communication or explaining it one on one to people gets harder because you have too many people. What I would look closer at are all the movements around program managers, design operations, these kinds of things where you really have like people focused on exactly that role of working on the processes, explaining them, working on the culture, advocating mainly for the culture without like doing the heads down work on either engineering product or design. So there's a lot of opportunities also looking at those specific roles and how they're implemented in bigger organizations. Yeah. We should definitely do in a separate episode talking about the kind of communication aspect. We talked a lot about that it's important, but we didn't talk how you do it in detail. I think it's worth looking at the as crazy as it sounds, the psychological point of view. So how do you transport a message in the right way? These kind of conversations, especially with the upper management, with top management usually end up in kind of negotiations. I think these are things we can dive deeper into to help product managers or generally to our audience to know how to approach certain things because the bigger the pressure is, the more communication is usually needed and doing it in the right way. That's actually the art. Nice. Okay. That's that. I think if you guys have any ideas or any suggestions or any feedback, especially as we're still in an early phase of our podcast, feel free to drop us a line. And I think it's hello at product-bakery.com. You will find us there. You can reach us there for all the other social media channels. They will be linked and we're looking forward to have you in our next session.