[
  {
    "start": 0.0,
    "text": "Tobi: Hello, friends. This is the Alphalist podcast. I am your host, Tobi. The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company. We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.",
    "end": 18.0
  },
  {
    "start": 18.0,
    "text": "Tobi: If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast. Plus, if you're an experienced CTO, you will laugh the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events. Just go to alphalist.com to apply.",
    "end": 51.0
  },
  {
    "start": 51.0,
    "text": "Tobi: Welcome to the Alphalist podcast. I am your host Tobi, and today with me is a guy called Klaus Breyer. And Klaus Breyer can talk a lot about silos and moving fast and and breaking silos. So the idea for today's episode is to talk about why agile often turns into mini waterfalls and how we can fix that. And Klaus often does talks about it, um, while, uh, in his professional life, um, acting as a head of product and technology at Edding. I think like everyone in Germany obviously knows Edding.\n01:30] Klaus: It's a, yes.\n[01:33] Tobi: As I learned yesterday, publicly listed company, mostly known for its pens.\n[01:39] Klaus: Exactly, yeah.\n[01:40] Tobi: Not not so much for digital things, but you can tell us a bit more and, um, Klaus, um, built an empowered product and engineering team around a B2B driver license check, which Edding produces or built internally, uh, incubated, right?\n[01:57] Klaus: Exactly, yeah. Um, it was built internally when I joined, um, one and a half year ago, there was already the core technology in place and people selling it quite successfully, but it was never a real product team on this product. And so I did some internal education, like, what does it mean to build a digital product inside of a not yet so digital company. I mean, they're continuously improving also their internal digitalization things. But yeah, I did a lot of explanation and then we hired a product manager and a designer for the first time in the history of this product that at this point already created five digits revenue. Um, I must admit. So it already had product market fit. Um, but I made it to one empowered product team. And the, the product itself, it's uh, it it comes with a quite interesting technology.\n[03:00] Klaus: It's a tool for driver license verification. And the, the use case is that fleet managers in corporate context in at least in Germany, um, two times a year, they need to check if the employee is still have a valid driver license, if they drive a company owned car. And, um, therefore Edding has developed a very unique technique. Um, and this is basically a label and it's an invisible label that you can put on your driver license, and, um, this label, you can, I tried to show it. You see some of the, some of the lines here. It's comp\n[03:42] Tobi: compressed away.\n[03:43] Klaus: Yeah, let's see if it's on the in the podcast, but, um, the name is easy check, easy check by adding, you can also look it up on the homepage. Um, basically the idea is the driver licenses, they got an invisible label on it, so that you can so that you still see everything on the driver license. But on this label, there is an individual code with a conductive ink. And so, if you put the driver license on your smartphone and you swipe across, then this code that is in this label with the invisible ink is transferred into the, um, touchscreen as as touch inputs.\n[04:25] Klaus: And then we can make with machine learning in the background, a matching, um, if this is the right, um, code for the right employee who's doing this test in the moment. And, um, yeah, but what the code exactly is, this is not obvious to the, to the user. Um, it's only, um, it's only by the matching that we do in the background that we to make it to make it sure that it's the right driver license.\n[04:53] Tobi: Cool. Um, yeah, magic ink.\n[04:55] Klaus: Yeah. Exactly.\n[04:56] Tobi: Interesting. It's an interesting software service, especially for Edding because they are, um, it's a software service, but it's also a product that has to do with ink. So, it's a really, really interesting technology.\n[05:11] Tobi: We're more interested in how you build empowered software teams and um, why why you think that um software is a design process and not so much an assembly line, which it became in many companies, right? Like in continuously running monster that uh, where, where people just chase sprint after sprint being depressed because they never finish or never achieve something. So, you're also one of the one of the biggest preachers of of Ryan Singers shape up which uh was developed at base camp. So super, super, super interesting. Um but before we start with that, like maybe a few words about like your personal the nerd and you, like why, why did you, why, why did you get there? Like why why are you fascinated by computers? What what initially sparked your attention and why why are you doing what you're doing?\n[06:05] Klaus: Yeah, so basically, I have a computer since I can write. So I got one from my father, I think in the first or second class of elementary school. And then I was typing all the listings from the, um, from the magazines, uh that I have some games there because yeah, you yeah, buying games was very expensive for me and so I just typed all the listings and for for days and and weeks until I until I had my games and then I played games on my Schneider computer back then.\n[06:41] Klaus: And yeah, basically I'm, I'm, I'm living and breathing computers since I can remember and then in my teenage years I got my first Pentium 3 with windows. And um, yeah, and basically I'm on every school I went, I redid the school homepage. I was very early in touch with the web technologies, um, built up communities from scratch. Um, I had a, I had a brief moment where I was not programming that much. This was during my, let's say late adolescence when I was playing World of Warcraft a lot, but even even World of Warcraft gave me something and basically this was the management of remote teams, because in World of Warcraft you need to coordinate 40 people at this time and everybody needs to be online at the same time and everybody needs to be prepared. So, um, this gave me a lot for the management of remote teams actually, the team at Edding is remote and my last team was also remote.\n[07:48] Klaus: And yeah, and then, then afterwards I, I studied software engineering and directly after software engineering, I founded my first company. This was in 2010. Then it was a social media agency. We were basically the first company in Germany that was building Facebook apps back then, 2010, 2011, Facebook apps were all the hype and we grew very fast, um, just out of the cash flow because everybody wanted Facebook apps wanted to have raffles, sweep stakes, but also bigger games we developed back then with Flash. And, um, yeah, this, this was my first company and then I was, um, self, I was CTO since my first company. In my second company, I was CTO and CPO.\n[08:40] Klaus: Back then, we did not say C P T O, but basically this was my role, um, because in my first company, I learned, yeah, the project they never failed because of the tech, they failed because we were doing the wrong thing. So I was very motivated in my second company to also take over this product part and I was also very motivated that it's not agency, uh work for clients that you could really have a saying in the product strategy. And yeah, this this company, it was a B2B marketplace where brands can collaborate with social media influencers, book them for, um, campaigns and and those kind of things. Yeah.\n[09:21] Tobi: Okay, cool. And and and when did you switch from anecdote from yesterday's prep call, give me a ticket to let me build the team that solves the problem?\n[09:29] Klaus: Yeah, it was basically in the stint after this, but I'm I'm I'm fascinated with the problem how engineers and designers collaborate, um, back then, the agency world, there was no product manager, um, but how they are collaborate and I I thought back then it's a matter of tools and we tried out a lot of tools, tools that let designers directly produce HTMLs for easier handover to the developers and so on. But then at at one point, um, it was while I was building up an I O T business unit for the industrial company for it, um, when I when I realized um, after, basically after reading shape up, it's really um, a process and a communication and a collaboration topic and not just a pure tool topic. And yeah, and then then I tried out shape up in this in this setting and we first tried it out with half of the team and then half the other half of the team and Shape up is a method where you work for six weeks uninterrupted on one topic.\n[10:35] Klaus: And if the whole team had this experience, working six weeks, um, interdisciplinary on one goal, um, together in two to three people, then it's a very easy sell to to change the whole process, um because everybody likes working like this. And so I got even more fascinated by this by this whole topic of how does, how, how are silos created and how to get get rid of them. And and basically it became one of my my main topics um until today because, um, almost all teams out there have silos.\n[11:15] Klaus: You can have silos in the smallest teams. You can have silos with with three or four people. Um, if they are thinking about the work in the wrong way. Yeah.\n[11:26] Tobi: And, um, is there the do you have like a a, a trick of how to make people wake up? Is there like a a a cheat somewhere that you often use?\n[11:39] Klaus: Um, I mean, at the end, it's for me, I try that they come up with the that they come up with some ideas on their own. Um, I mean, in in general, I'm, I'm, I'm I try to be very vulnerable publicly when I lead a team because I give some framework, some boundaries to a team, but often they are not completely perfect and when, for example, the role of the designer is one of the hardest in in when you get rid of silos because designers love to do 30 40 Figma screens and hand everything over so that everything makes sense.\n[12:24] Klaus: And process wise, they need to do this to a certain degree because they can't make some decisions before they don't know what else is there. Um, but but for example, especially with designers when they say, ah, it does not work for me and this is shit or then I, then I and when they come up with a better idea, then I'm, I'm very public and try to be very publicly vulnerable that this was not a perfect process, but it was a starting point for for continuous improvement and and and I thank them that they corrected me and I I try to be very open on on this topic.\n[13:03] Tobi: And um, was from your perspective, the the earliest tell you're in assembly line mode, um like language meetings, Java smells, anything that like if you look into a team, you you you that makes you realize uh I'm in the wrong movie here?\n[13:22] Klaus: Yeah, I mean it one of the biggest signs is, um, when you need to do tradeoffs because the time is running out. Um and then if you do tradeoffs because the time is running out, most of the times the tradeoffs are then done or led by the engineers because we don't have time to complete this feature. And those when when those tradeoffs at the end are made, then, um, then it means the team has not made tradeoffs early enough on a on a strategic level and this means they are not collaborating together on a strategic level enough.\n[14:00] Tobi: Okay. Okay. So that means that they are in the like, uh, they are just working on their ticket basically and and not not so much thinking about the big picture. Yeah, I also remember a few moments when I heard give me a ticket.\n[14:16] Klaus: Yeah, I mean which is even if everybody would work like this and like in IT support, everybody is just working on on on tickets when we're developing product, you could, I imagine this world very, you you're working away very blissfully, eight hours a day, ticket after ticket and you go home very happy. But the reality is different because today you cannot implement a single ticket in product development without disturbing five other people via Slack and interrupt them while they are doing their work or you got interrupted from others because they need some API documentation or some requirements are not clear. So even tickets alone are, they they don't help us. Um and and then if you're out of time and you just worked on tickets and not on not really together on a on a higher level how to make the right tradeoffs at the right time, then the engineers make the tradeoffs at the end and you end not up with uh and those traders are um are then not the the right ones in the most cases.\n[15:25] Tobi: So what then makes you happy is if you see like a table as big as this one, um with I don't know, four people around it who work for four weeks or six weeks on on on one, uh, problem that they try to solve together?\n[15:40] Klaus: Yeah, basically, I I'm I'm always happy if I don't see more than four people working at the same thing at the same time because it only gets more complicated. And I think the real key is to decide who are the right set of two to three people um to work on what topic at the same time, because I mean, you have more strategic topics where you want to have the more senior people together making those decisions. Um but then you have the more the implementation part and where you can give a team more freedom if your strategic boundaries are defined correctly. Um and and they always try to optimize for this set of the right two to three people to make to make decisions.\n[16:28] Tobi: But isn't it also a bit about the people that you deal with? Like, I mean, I I know many people that want to have impact urgently and others that um maybe care more about the infrastructure they they they they are are operating. Um isn't it like at first the people question and secondly only like a, a a an a question of management style and and org setup?\n[16:51] Klaus: It's a skill question, um, first of all, because if you if if I try to bring together on one table, um, the the senior, uh the senior designer, the senior product, uh manager and the and the senior engineer, then I need an engineer who really knows the code base, not somebody who is um, a general techy and and a good engineer. It could even be a good engineers, but if he has not knowledge of the concrete code base, then it uh then it does not help. For example, if you shape projects like like in shape up, then you really want to have the most senior people there and but it's also a a character thing. Not everybody wants to collaborate on this level, but I feel most people who want to have an impact and who are good engineers, they want to have a saying in what they are building at at the end of the day. And some others maybe need some more time until they get to this point. Um maybe some of them get never to this point, but I must also say during the implementation phase, for example, in shape up, if you work together for six weeks, two to three people, then it also helps sometimes more shy people to get out of their comfort zone because if they are not escalating something, then they're on their own.\n[18:17] Klaus: And so I have seen cases where also shy engineers are helping, um, for example, directly with a customer, um, getting access to this beta feature and and those kind of things. Stuff that they would have not done otherwise if they are in a in a bigger setting. So if you, if you reduce the the team size, then everybody can has has less room to specialize and need to do also other things. And I think we are seeing a general trend towards specialization, um nowadays in setups where fewer and fewer engineers can do more and more things.\n[18:55] Tobi: Yeah, that's a slight trend towards also smaller teams, right? Um also with AI being around. But isn't then um the initial idea of agile for many companies that's either Kanban or scrum a misconception because or like not in line with how software should be built because it's it's it's basically borrowed from automotive industry and production lines?\n[19:23] Klaus: I mean, the original manifesto for agile software development, they had the right things in mind, the individuals and interactions working software, collaboration, responding to change. Those were the right things, but the people who created this manifesto, those were developers, um and and at one point, business took over and business tried to make it yeah, make it work for the for the business and so they come up with Scrum. Basically, Scrum is a set of business practices. This Scrum is not a set of development practices like um all this planning game, small releases and and so on. Basically those are are business practices and not developer practices.\n[20:10] Tobi: How does then like your ideal idea um derive from that? Um what's what's what's what what do you do early then um if you if you enter a company, if you if you consult a team, if you build up a new team, what what's your first what's the first thing for you to do and um how do you make sure that people work on the right objectives ultimately?\n[20:35] Klaus: Yeah, I mean, figuring out the right objectives is the first thing that you normally need to do. Um but I in in general, I try to bring in a mindset of differentiating between different things. I need, I I want people, everybody, the whole senior management, but also the people inside of the product team to be very clear, are we talking now about what objectives we want to achieve? Um and then and for me there's only one objective at the same time and not not a list or on so it's really one objective at the same time. It's a very easy rule, but it's uh the the hardest rule to follow in a lot of companies, but really talking really bring in a I I I try to force rank the objectives so that I force the people to if it's for example, if it's coming from senior management, rest of the senior management, I really try to to make them a prioritized list.\n[21:32] Klaus: Are we now focusing on engagement or on growth? Are we now trying to prove um if our product works for customer or are we trying to prove that we can make an impact with our product or that we can sell it? I mean, those all different objectives and I really try to focus the whole team on one objective at a time. And and when you focus on one objective at a time, then you can think about how are you slicing the problems this teams is working on and here I try to differentiate talking about problems differently from talking about solutions because um it's two different things. If your problem is clearly defined, you can come up with a whole set of solutions, but if you start with a solution, you're you're very limited and you cannot you you don't have the freedom in your in your mind and then your discussion culture that you first focusing on the problem.\n[22:28] Klaus: So you have the objective, I try to focus on the problem and this is very strongly inspired from shape up um where you need to have a framing before you go into the shaping into the shaping phase. So the framing is what is the problem? Um and this is just two paragraphs. Basically what is the current context and what is the desired outcome we want to achieve. And I try to narrow down everybody on on on this before we are talking about solutions. And this is also also if you think on classical strategy work, like good strategy, bad strategy template, it's the same like you want to have your current context very clearly, so the customer is in this situation, the product is in this situation, the business is in that situation. And then you want to have an basically a desired outcome like without talking about the solution and this is the challenge here and and shape up does a very good job in Ryan Singer especially in explaining this, um talking about the desired outcome like what what what is the what is the outcome and not the output, what does the customer wants to achieve in this phase.\n[23:37] Klaus: And and if you're talking about problems, um also inspired by shape up, you you you should talk about how much you want to invest in this problem. Like what is your appetite? Because if you say, if you, if you have the problem separate from the solution, then you can have a discussion, we are, we are about, we are interested in investing one week or investing six weeks in solving this problem. What is it worth to us? This is a, this is a very important discussion to have and and establishing this culture of separating the problems and talking about what it is worth to solving this problem or proving this hypothesis, um this this is the most important thing um on the top level.\n[24:23] Tobi: So, double revenue next week.\n[24:26] Klaus: Yeah, I mean we need to come up with a set of problems that is hindering us um with that and then we can basically make uh I mean, at the end, doubling the revenue is not purely an engineering problem but uh but we can um from the engineering side, we can come up with problems in in in this space and then we can discuss how much is it worth to us and then it's also pretty easy to talk about business wise, is it worth to us investing this time or this resources in it, because you can um some companies are very keen into ROI calculation before they do um product initiatives and if you have differentiated the problem from the um from the amount of resources you're investing, you you can have an easier calculation if it's the, if it's worth to you.\n[25:20] Tobi: Right, and also easier for the people that are supposed to solve the problem to um understand the the the room of possibilities basically, right? Or the zone of of possible solutions because like if you can invest one euro uh to double the revenue, it might not work out, right?\n[25:40] Klaus: Um exactly, yeah. Yeah. And then when you're talking about solutions and the the team knows how much the team can invest, then you have a different set of solutions. Maybe you have a rough buying decision or you have a more expensive building decision or you're just say yeah, we first prototype something first and so on. And yeah, and and then when we are in the in the solution space, um I try to teach the teams an an approach that they can always stop the project after the time box is over. This is very important um that you try to identify the unknowns first and but only the unknowns that are really necessary to solve. And yeah, when when we approach a approach a project, then we are always doing a scope map. So it means all the scopes of the project, this could be five, six, seven scopes. And then I play the I play the devil's advocate and I say, can we cut the project after this time? Can we cut the project then? Can we cut the project then? To really identify in our scopes map are we starting with the right scopes in the implementation phase? Because if you cannot cut something that's at the end, then it needs to be at the beginning. Um and yeah, and the idea is to just start with the most important thing and not end up with a scope map that is for example, like a bad example would be prepare all of the API, prepare all of the design, next step, bring everything together.\n[27:17] Klaus: This is not a good scope map. A good scope, a single scope is something that could be developed and and shipped individually, maybe not released, maybe it's behind a feature flag, but um the whole team can work on the same thing at the same time, basically also a shape up principle. And I I just try to bring the team in this in this mindset by always asking, can we cut here and here and here? And in reality, halfway through the project, we may be identified other scopes and we re or we may re prioritize or we change the scopes. This this can still happen. This is still part of the flexibility. It's not about making a a fixed plan here, but just establishing this mindset of constant reprioritization. Also finishing one scope and not saying not gold plating things, but really saying, are we, we don't really need to do this now because we have all the rest of the project is also very important mindset that such a team needs to go into. And the mindset is harder if you work with tickets, um because then you have all the tickets and you see all the work.\n[28:30] Klaus: I have, I have setups where we work for feature development completely without tickets, as unimaginable, maybe for some people. But if especially if you have more senior people, everybody is um you can trust everybody that he or she organizes um him him or herself, then everybody after their daily goes back to their work setting with their own to do because they know what to do until they meet for the next time. This is also possible. You can you can also work with tickets but in a way that tickets emerge organically, like, um, while the team is working on it, they create a ticket. It's not like a product manager is creating all the tickets and then they work on the tickets. I mean, with a basic Kanban three column setup, you you can also work in this way if the people are less organized. Um but then you really need to be very, you you always need to ask the question, are we working on the most important thing? Because at the point that you have tickets, people just want to make make the tickets reality, make the check mark done, done, done.\n[29:41] Tobi: Yeah, right. Move stuff from A to B, right?\n[29:43] Klaus: That's like kind of it's rewarding, it's it's it's um it's giving all the dopamine in the brain and and things, but it's more important to really ask the question, are we working on the most important thing? And it gets yeah, it gets sometimes I'm tired about asking this question all the time, but you need to repeat this question all the time, um, at least for the first half of a year, um, when a team starts working in this more free way of of working. So you ask it in every daily?\n[30:16] Klaus: Um, basically, yeah, I'm I'm I'm nowadays I'm not in every daily, but I try to be there once or twice a week basically just to ask this question. Okay. Okay, okay. Um cool. And then um like um having like break points after every iteration, um then means like potentially discontinuing or being able to discontinue after six weeks.\n[30:41] Tobi: So do you always hold, hold to those six weeks or um how how does that um typically look like or do you often also just cancel because you think like, hey, what we're doing here is rubbish.\n[30:55] Klaus: No, cancellation does happen very rarely in in my experience. At the beginning when a team starts and they're not that good in holding on to the time box, we extend the time box by a week, by three days or or whatever. Um but then at at one point, maybe after half a year after a couple of such cycles, you can be more more strict and the team because if the team had experienced one or two times that they cannot ship everything they have planned on scopes, then they are, they really understand that we need to re prioritize the scopes all the all the time.\n[31:35] Klaus: So at the beginning, I tend to be a little bit loose just to that everybody understands the workflow. But and then and then later you can be more, you can be more strict when the team had their first failures, um, basically. But isn't then, aren't you always in those six weeks under mostly then like an engineer, a designer and a product person in a room?\n[31:58] Tobi: Like, is there like enough of the objective, the initial objective flowing in again? Like, um, or how do you make sure that like this is all connected that like objectives are connected to problems to solutions and delivery? Um\n[32:17] Klaus: I mean, the the problem needs to be connected to the objective. This is one of those critical points of the product manager. The product manager is responsible for the customer value and for the business viability risk. So is the problem we are defining is this something that that uh that where we provide customers value and does it work for the business? And so the product manager is responsible for making this connection. Are we paying is there something that's that's that's that's working for the objective? And then if the problem definition is good, then the product manager is also responsible that this the problem definition is is um resolved by the by the solution at the end. So the product manager is the the bridging the bridging function here. So the product manager then talks to like the business owner and makes sure that this like it's actually happening or it depends always on the size of the organizations and how are you doing this?\n[33:25] Klaus: I I I tried to think of, I mean the the objectives needs to be decided and on and needs to be um agreed on on the highest level. And then you have this next level of implementation where you talk about the problems. This is then the next level also on a in a hierarchy. And then you talk about the solutions and you can basically imagine it like a like a company hierarchy with different people involved. And in the in the best case, there's always the same three factor. You have a designer on the top level, you have a product manager on the top product person on the top level and you have an engineer on the top level, like the CTO, CPO, design in reality, of often there's not a chief design officer in the most companies that I worked with. So, um then somebody needs to also take over this role. For example, in the CPTO setting, then the this is also taken over by the CPTO. Um if there's CPO and the CTO, then most of the time the design and as I have seen it is then taken over by the product officer, but you need to have those functions on a different level then I I tried to think in roles and one role can be held by multiple roles can be held by one person, but it's just important that you do not forget those those roles. Yeah.\n[34:49] Tobi: How important is Conway's law in this in this equation? Like, um how do you typically, how are hierarchies typically uh designed here?\n[35:00] Klaus: Um, yeah, I mean, Conway's law um to repeat it maybe for the for the listeners says that organizations that design systems produce designs that mirror their communication structures. So if you, um if you always work together in teams of of two to three people um for either for defining the problems, how you are slicing the problems or when you implement the problems, then it's then it's very important that the people who are doing the slicing of the problems keep this principle in mind because in an in an ideal way and if you in in synergy with your architecture, you are able to work on couple of things in parallel without the actual solution has a dependency on each other because if the implementing teams that are implementing the solution have a dependency on each other, then they are not autonomous anymore and then they they're losing a lot of the advantage of working in in a small team.\n[36:08] Klaus: So it's it's very important that the the the architecture but also the slicing of the problems um keeps this in mind, this this principle. And then if if you have a basically an empowered product team that that can work in this way, it's uh pretty easy steering this team because you you just give up, you align this team, the seniors of this team on your on your objectives and then the best way they do the discovery and what problems to solve and how to solve them with what solutions. And yeah, with Conway's law and designing teams is also important that you really optimize those teams for value streams like team topologies basics from from Matthew Skelton that you don't have a lot of handovers between teams but that you really took all the capabilities that the team needs to work on a certain product or on a certain domain in one, in one team and then and then it's a question of who's working on what solution within this team, but you really want to avoid um for example, to to solve one problem that you need to go to three or four different teams. This is this is very important if you're thinking about the organization design.\n[37:32] Tobi: Um and and regarding organization design, like I I saw many setups that were like not really functioning because um there were like, for example, people from two different orgs involved, uh matrix structures, etc. Like, um does that like immediately bring an alarm bell if you see something like that, if you want want to connect like two different teams uh to work on the same thing or to solve to work towards one one direction, um do you, do you then like encourage directly to change the whole um the whole reporting structure?\n[38:10] Klaus: No, I would never change the whole reporting structure at once. I would if I would face such a situation, I think I would try to form one temporary team that is then um but that that one temporary team that is stream aligned that had basically everybody who's needed to do this will be in one team. Maybe if it's just for temporary amount of time, maybe this is a a starting point for a restructuring if this happens more often. Um but yeah, this is then probably a little bit more this this probably needs to be aligned very goodly on the product side, um and then bringing the right people together.\n[38:51] Klaus: But I would, I would, I would put them in a in a separate team if the if the scope is reasonably big, like if you have just one dependency once then maybe it does not make sense. But always bring together the people and let them own own this topic together. I think this is the the important thing.\n[39:15] Tobi: What what would be like for for many, I mean many of my listeners they they I think they are in traditional agile setups, uh meaning waterfall setups, mini waterfall setups. Um what what would be your recommendation for for my listeners uh of of of how to, I mean, you described how to realize that like, hey, give me a ticket, but also how to how to change it or how to try out something different, um besides booking you as a consultant. Um what what would be what would be your recommendation of the the first things to do and first steps to to walk walk alone maybe?\n[39:58] Klaus: I would always try to do experiments because if you do an experiment, nobody is saying something against it. I would never say we know we change everything. I would say now we we limit us to just thinking about the next six weeks and we don't think about what is further down the line. Um and um if you want to change something on the process, I can just recommend like I did trying it out with half of the team, like in this setting, we kept our Scrum as a baseline, as a um as a sign to every stakeholder nothing is changing here, we're just doing a experiment with a part of the team.\n[40:41] Klaus: And then this team works in shape up for example, and then the other team works in shape up and and as I said, if then the whole team has experienced working on one thing at one time for six weeks, then it's an easy sell for the team and then it was more a question of how we are doing it. Um but you, I mean, this is when you want to change the process, you but you can always try to implement this thinking of now are we very clear about objectives we are solving or problems we are solving or or solutions. Like, yeah, I think probably the, the talking about the problem first before you talk about the solution is probably a good power move for every manager, um because then you can really find out are they understanding the problem, you can talk about with them, are we talk, are we solving the right problem. Um and then let really decoupling those kind of things is something that it it it cannot harm and it's really an important thing to to cultivate in the mindset.\n[41:54] Klaus: Are we talking about the solution or the problem now?\n[41:56] Tobi: Okay, thank you. Yeah, I I think that's like uh just realizing, hey, you're in solution space too quickly.\n[42:05] Klaus: Often exactly, yeah. Is is is something that really helps engineers, right? It's okay to admit admit this, it's always okay to say yeah, this is solution space, but now let's find out what problem are we actually solving and then really checking is this the problem we want to solve? And it things are things are coming from both directions. Things are coming from the customer value side, things can also come from the engineering side, but then you need to invest this additional step in really um in really finding yeah, defining what problem it is that we want to solve before we implement this feature or new system or whatever.\n[42:47] Tobi: The right format to do this. Um I'm curious what what you think is the right format because um if you go into like modern orgs and let's say you have a remote first organization, then there is Jira, then there is potentially notion or confluence and um then there are maybe Google Meet and I don't know, miro if you if you if you if you will. Um and I think many companies fall into this this the trap of like just following their systems, right? And you initially said like, hey, it's not about tools, but often like the tools really also design the workflow in a way, right? Or um dictate the workflow maybe more, more. Um how do you how do you escape from that? And um\n[43:39] Klaus: I mean, if I'm joining a new organization, then I always start if the objectives are clear, then I with the and then for the implementation with the team, I start with the problem definition and then I give my my template for a problem definition, which is roughly the uh a framing template from shape up, like what is our current context, what is our desired outcome? This then I give the product manager and say, let's start here. Let's first define what, what is our starting point, what should change afterwards. And this is the first thing and normally I'm doing this in confluence or in in written form, could also be if it's a Google doc heavy company could also be Google Doc.\n[44:26] Klaus: Like, but it's a it's it's a written thing for me. It's a it's a text document where people can collaborate on it. Uh with such a framing, I can go to the CEO or to other senior management um stakeholders, maybe sales or whatever and they quickly understand this is what we're trying to achieve and I also put an an appetite there from shape up, like this is the amount we want to invest and then they have a good and and this is not more than one page of of of paper. It's really high level, really condensed thing. And and yeah, I I start in the in the written tools with this and and the other tools designing the solutions, um is often in miro um because you need to collaborate more. I think it's very important if you are designing a solution that everybody is starting on a blank slate. This is really a habit of product manager. It's hard to get rid of, but don't prepare anything if you go into the into a shaping session or discussing about the solution because for me it's important that all three um parts, design, product and engineering are really starting on a blank sheet of paper because only then the whole team owns this solution.\n[45:46] Klaus: If the product manager produces too much, um then it's often people just stop thinking and me included when I was just implementing things. If somebody brings something to me, then I nod, yes, this works, this works, maybe not, but I'm not really owning it. I'm, I'm just implementing it at the end of the day. So another thing people can just try out is let their team start on a blank slate and let them collaborate on a on a high level. Um because miro everybody can use miro, can add a sticky, can draw an arrow. Um you don't need to Figma um to discuss product requirements. Um you don't need a whole product requirement doc. You just need a framing and then you let people collaborate and always with this time frame in mind and then at one point, you try to let them come up with a with a plan, with a scope map, how they want to tackle it and then you can you can challenge it if if it makes sense and you have a rough understanding, um will this what we are implementing here really solve our problem and can also challenge this.\n[47:00] Tobi: How how long does that typically take until you really start after like uh having having uh the the the shaping session initially? Um until you really start like delivering. Um\n[47:13] Klaus: So, it it depends. Um at the beginning the shaping sessions are always longer because everybody because normally at the beginning, also the team is new, yeah, it depends also a little bit if the team is new. In the edding context, the team um was growing and we introduced the method, so the shape up sessions were the shaping sessions were very long. Um talking about uh four to two to three hours, maybe five sessions, um distributed over two or three weeks. But then at the end, um you you be faster. then the shaping sessions are one or two hours, two or three sessions and you can do it within a week. Um so, yeah, it it it it depends at the beginning. I um I try to be, I try to give some flexibility there before we start, but I really try to enforce the time box when when we end because this is also important for the expectation management with the rest of the company.\n[48:19] Klaus: So at one point, um they should know in six weeks we have something that is roughly this. So sales and marketing can already prepare on and and align and as closer as we get, maybe even if we need to delay it for one or one or two weeks then we we even know at least we know more concrete what it is that we are delivering to them.\n[48:41] Tobi: When you did your AB tests and your experiments, um or experimental changes of the of the structure, how did you measure success ultimately or how would you recommend to measure success of such an initiative ultimately? Is it an increase in outcome or impact or is it just happier people?\n[49:02] Klaus: Happier people is um one of the things definitely. Um I do a regular, um I do a regular surveys um with the team if they're happy, if they are feeling their their opinion counts and and and some other things. Um but it's also for me, a successful initiative is when the team re prioritizes basically, this is what I'm measuring my personal success if the team is not just implementing what they were provided by even by one of the by one person, but if they're really re prioritizing and and and knowing how to yeah, yeah, if if they're re prioritizing, that's that's my my most important goal if they are doing it then I'm happy and then I feel I've I've changed something and just closing the loop to working agile, this is basically what agile is is about.\n[49:58] Klaus: Agile, does, for me, it it means always delivering the the most value and and this framework, like working in time boxes and constantly re prioritizing on what we are working, this is basically uh yeah, you you I mean, you could argue the time boxes, you don't need the time boxes to work agile but it just helps to implement it. It gives a it gives a cadence to the whole company. Sales knows when something is ready. If you have a couple of teams in parallel, they you you you can you can just your planning process just makes sense because every team is owning at the same time and then the resources are free um for the next for the next cycle.\n[50:44] Tobi: That all makes absolute sense. Um and uh a lot of like beefy content for for my listeners. Um and slowly, we we slowly have to have to come to the to the to to the end here. And um I typically ask my little surprise question here, where I thought like where, where can I, where can I send you um into your your your past?\n[51:08] Klaus: I'm curious.\n[51:09] Tobi: Well, I thought about um your your very short step at IBM because um you were, you were acting as developer back in the days and I think um you you you had that moment when you um might have uh realized that you better start optimizing for for outcome and impact. I don't know if it was at that time, I guess not.\n[51:33] Klaus: But was in the internship back then, basically.\n[51:36] Tobi: Yeah, yeah, so much earlier, I guess. So if we would now have that crazy machine that would won't would send us back to the year 2009 where you worked as full stack engineer at IBM Deutschland. Um and you now had the chance to whisper something into your young intern ears. What, what would you, what would you say? How would you wake up yourself?\n[52:03] Klaus: Um, first of all, um, I would not change anything because I think you need to do all those errors and and mistakes and have all the experiences that you end up with the same end result. Um but, um, I think if if if we if I use this as a chance to summarize everything, um, on a on a human level for somebody who's just starting out with those things, then I would say, um, don't stress yourself about having all of all of the answers, like focus really on on on facilitation of shared learning for the whole team because yeah, sometimes you, especially as a, as a leader then, need to take a step back and and let the team gather their own experiences and rather think about how could, how can you facilitate learning for your team and not um doing everything for yourself.\n[53:02] Tobi: Let others learn. Don't micromanage. Exactly, yeah. Sometimes it's less fun than doing the things um by yourself and it does not feel that efficient and it does not give you the dopamine hits, but then it's just a sign that you maybe need to find other projects where you can do it um on on yourself. But this is not the job for a for a senior leader in my opinion.\n[53:29] Tobi: Where do you get your dopamine from?\n[53:30] Klaus: I get my dopamine from various side projects, trying out uh AI ML models for all kind of new um projects I'm I'm doing at the side in my private life or also in the in a project context. Home automation stuff, etc.\n[53:48] Klaus: It's more about at the moment it's more about um automated PDF generation, um creating um photo books from vacations or from the family and um having having nice layouts where all the pictures fit perfectly without using one of the builders where you need to move every picture somewhere that's this is where I try to to optimize at the moment.\n[54:15] Tobi: Okay, okay. Okay, PDF, PDF is the new flesh for you then.\n[54:20] Klaus: PDF is sadly the the standard if you want to print something.\n[54:25] Tobi: Unfortunately, yes. Uh so Klaus, thanks a lot for your time. Uh was really pleasure talking to you and um have a great day and see you soon.\n[54:34] Klaus: Thank you. You too.\n[54:35] Tobi: Bye bye. Bye bye. Thank you for listening to the Alist podcast. If you like this episode, share it with friends. I'm sure they will love it too. Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available. Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick. Alist is all about helping CTOs getting access to the insights they need to make the best decisions for their company. Please send us suggestions to cto@alist.com. Send me a message on LinkedIn or Twitter. After all, the more knowledge we bring to CTOs, the more growth we see in tech or as we say on Alist, accumulated knowledge to accelerate growth. See you in the next episode.\n[55:25] Announcer: Dieser Podcast wird produziert von Podstars bei OMR.",
    "end": 3333.408
  }
]