#224 - Move Fast, Break Silos: Leadership for Interdisciplinary Teams - Klaus Breyer

Scrum in my opinion is a pure business practice. Head Child kind of became a micromanagement tool product. Thinks its own way. Technology thinks the other way. Sometimes they balance each other, sometimes they fight each other. When the project was a failure, it was most of the time not the tech that was failing, but that

we built the wrong thing. You really need to differentiate between problems and solutions because a lot of teams are skipping this step and coming up as a solution too early. If you want to have an empowered team and you only have introverted engineers who only want to work on their tickets, then that's the the strong team. We as an industry, we are working still like on the conveyor belt.

And the conveyor belt is a useful metaphor for industry and for manufacturing, but it's not a very good metaphor for producing software. In a lot of traditional settings, they see writing code as the manufacturing line, but the fundamental misunderstanding is that building software is the design process. We are not implementing A solved problem, we are solving the problems, so we are making creative decisions every hour of the day. The rise of AI is a very good argument for engineers.

I asked them what are they worth in 10 years that you can write JavaScript? I don't think they're not worth much in 10 years. So the main topic of our discussion is move fast and break silos. What are some of the key practices? Everything is centered around how we slice the work and how we are aligning the teams around this work. What I mean was how the work is sliced. It's for me about how. Hello everyone, welcome back to another new episode of the Techni General Podcast.

Today I have with me Klaus Breyer. So he's kind of like experienced CPTO, right? I haven't heard about the term CPTO before. I guess it's something that maybe we can also talk about. So Klaus, welcome to the show. I'm really looking forward to discuss the topics that we plan to talk about because it's something about, you know, highly functional and performing teams, engineering teams, right? So welcome to the show. Yes, it's a pleasure. It's an honor to be here.

Klaus, maybe in the beginning, I want you to share a little bit more about yourself, right? If you can share career turning points that you think we can learn from you, I think that will be great. Yes, sure. So I studied software engineering and directly afterwards I Co founded my first company. It was a digital agency and I was the CTO. This was already 15 years ago, so when the year 2010 now.

And from the beginning I was puzzled or fascinated with the challenge of how engineers and designers could work together. At the beginning I thought it was a tool problem then not using the right tools for better handovers and so on. But yeah, because this was not something that was teach at university because we were all just engineers.

So I need to figure it out during my first company and luckily, and this is a good thing, starting out with an agency in the career you have a lot of projects or you every time you have the possibility to start over. So it's a good start into the career. In general. I think I would recommend it because with every new project you can improve what you have already learned. After I exited this agency, I

founded my next startup. It was AB2B Marketplace SARS, where brands can do campaigns with influencers. And this time I was not only CTO but only CPO Chief Product Officer as well. Because in my first company I learned when the project was a failure, it was most of the time not the tech that was failing, but that we built the wrong thing. So in my second company, I was very motivated to also step into this product role and learn more skills and learn how to lead product manager.

So I moved up the value chain, so to say a little bit and learning more of the product skills. And as you said, CPTO, it's not common nowadays, but I feel it gets more and more popular, especially in the software as a service world where product intake is very closely related. And I think having a separate CTO and CPO could make sense in some other cases where you need a lot of industry knowledge, for

example. But most of the B2B says, in my opinion, it really makes sense to combine those skills. And yeah, I, I did the startup also for a couple of years and we exited the startup. And at the moment for the last couple of years, I'm doing a mix of interim management, some consulting and interim management. Since I'm basically infusing my startup spirit into corporate at the moment, like building startups inside of corporate and see a whole set of different challenges again.

Because now it's also talking about other stakeholders from a bigger business about the tech. And ultimately it's also owning the strategy for the whole business unit and not just being one of the Co founders. So I moved up the value chain once more, starting from tech, ending ours responsible for whole business units. Thank you for sharing such a

unique story, right? So I'm a little bit intrigued by this CPTO role because it's not common yet, right? So I think in your experience, having to play multiple roles, CTOCPO and CPTO, right? And even move even higher up, right, What do you think are the key critical skills required if you really want to become one person handling both product and technology? Because in many places it is like a duality, right? Product thinks it's own way,

technology thinks the other way. Sometimes they balance each other, sometimes they fight each other. But if you're one person, what are the some of the critical key skills do you think? When interestingly, if you look back 1020 years ago, a lot of what is now product was part of technology and part of the responsibility of the CTO. But then I think of the last 10-15 years we had this, I call it product movement, where the product became the special

discipline. So maybe even somebody at the moment having the title CTO could also have the responsibility for products. So it's at the end just it's just a title game. But skills wise, what's important is I think you need to really understand how you need to understand the principles of product management so that you are trying to find out the problem before you build a solution. You also need to know how to handle those people who are better in those skills than you

are. Because if you have a good product manager in your team, even the head of product and a couple of product managers, then they are, they know the interview techniques better than you are. But at the end, you are responsible of bringing everybody together so that everybody can work with the other departments in the correct way. And at the end, sometimes it's just a sanity check on being a sparrings partner for those kind of people in the team.

If it really makes sense to go in this direction because the interview techniques and the product management techniques, they should know them. But if it really makes sense in the context you as a CPTO, you are the the ultimate sparrings partner. Yeah.

So sometimes also in my view, right, So looking at all the CPOCTO that I have seen in my career, right, I can see that product tends to be very optimistic, you know? Yeah, we can do this. You know, there's so many things, good vision, you know, very far ahead and sometimes the technology is the pessimistic 1. So being a little bit more cautious thinking about how to scale this, secure this and

things like that. Now if you are into one person, so to speak, right, how do you see this so-called extremes? Are you sometimes juggling between being optimistic versus pessimistic, or some tips and tricks that you have done so far in your role? I feel it's like a pendulum that swings back and forth because sometimes you are stagnating on the product side and you are working with the product people more to really find out the what is the right, what is the ADL

customer profile or problems? Do they have like to really find out those kind of things? And then on the other, then there are other phases where you're tackling tech depth because this is the biggest issue because we cannot scale with the tech that we're having. So for me, it's it's like a pendulum. I need to decide where I focusing at every moment or how I bring it down to a joint strategy at the end that it makes sense for both worlds, the challenges that the company's facing.

Right. So I think the art is the playing the pendulum part, right? So where you can actually juggle between two different heads and make sure you keep sanity of yourself, I guess.

So the main topic of our discussion is this thing or term you coin, you know, move fast and break silos. It's very similar to, you know, the Facebook motto, move fast and break things, except that, yeah, except that you put break silos. So maybe tell us a little bit of the background. How do you come up with this

motto? So as I said, I'm always since always fascinated with the challenge of how people are work together because I'm basically responsible to how people are working together since the early days of my career. And so I saw a lot of tools, learned a lot of techniques and tried out a lot of techniques. And I just realized that we as an industry are at an interesting point at the moment because if you look back like to let's look back over 100 years and let's look back to Henry Ford.

He was a successful car manufacturer, but he was not like a multinational corporation. And if you look at the manufacturing process from Ford back then, the cars were standing at once at one place and the workers were moving around the cars. They were building 1 car on one place and it took 12 hours to

build a single car. And as we all knew then Henry Ford leveraged the conveyor belts for the manufacturing process and then the cars came to the workers and this caused that the workers can specialized better on a single task. And then Henry Ford could produce 8 cars in 12 hours instead of 1 car. And Ford, he was a very smart guy because he had not more capital. The conveyor belt was already invented by other industries, but it just brought it together and leveraged it for mass

production. And I think this is the situation where we are right now with product development. There are a lot of tools out there already, but you need to know the tools, you need to know that they are existing. You need to maybe have a little bit of experience with them to apply them to your situation. And this was kind of my motivation to work on this topic because I really see a lot of

tools out there. I really see a lot of misaligned teams in my direct work as an interim manager or if I'm advising a start up. I think we as an industry, we are working still like on the conveyor belt.

And the conveyor belt is a useful metaphor for industry and for manufacturing, but it's not a very good metaphor for producing software because with a conveyor belt software development process, you end up in waterfall because you have one step after the other and you have silos on all parts. And I think part of the problem is that in a lot of traditional settings, they see writing code as the manufacturing line.

It's just making it happen. Somebody other already had the idea upfront, some stakeholder, some product owner, somebody had already idea. But I think the fundamental misunderstanding is here that building software is the design process. Because as a software engineers we are not implementing A solved problem. We are solving the problems. So we are making creative

decisions every hour of the day. So I think we need revolution like the industrial revolution that was kick started by Henry Ford, but I think it's going into the different direction because it's going into the directions to how we are making decisions and who is making the decisions in what context and and how we are aligning those things.

Yeah. So I think you brought up a very interesting point, right, Because I can see even in the industry, right, in the software development industry, so to speak, so many people still treat software development as like manufacturing process or assembly line process, right, where they think producing program is like producing widgets, so to speak, right. Or maybe car parts in your.

Analogy. Right. But I think in many, many literature and maybe HR practices and all that, it seems that this kind of process actually is not optimal simply because, you know, there are a lot of ways, a lot of inefficiencies in the process. So maybe if you can tell us why the difference of software if you compare to the manufacturing process, because many people think it's an engineering thing, right? So it should work similar to manufacturing process.

So maybe what do you think is the biggest difference? Yeah, the biggest difference is that the software engineers, they need to find out how they are solving the problem. Because if you are producing a WeChat or car part, somebody else has already made the design and already the machines are in place and the machines are configured and you just press a button and then you you do something. With software engineering, it's different.

You need to make decisions the whole day and you are part of the design process and I think we should embrace this. We should understand that the developers are part of the design process and this means, like I will explain later, that they are starting much earlier in the process, having a say in what problems we are tackling, having a say in how the solutions are are designed as well. Yeah. So I think what you said is very important, right, for all software engineers and also the

managers, right. So software engineering is mostly making decisions and design almost all the time, right? Because when we start the software is simple, right? But as we grow in terms of maybe business requirements and all that, you make a lot of changes that you didn't foresee before in the very beginning, right? And that's why you keep tweaking, refactoring, maybe even migrating some parts of your software into something

new. So I think this is probably the biggest difference against the manufacturing, right? And if you, if you want to compare it with manufacturing, then maybe the manufacturing part is the pure act of pressing a key on the keyboard, like just writing the code. And as we all know, just writing the code is the smallest part of we as engineer what we are doing. Most of the work is happening inside of the head while you try to how to dissect the problem and so on.

And writing code, we probably will do less and less in the future with say hi. So it's more and more important that engineers are really used, leveraged in a way to solve problems. How do you think you can convince or maybe influence stakeholders management about this thing where software engineering is mostly a decision process rather than a production process, right? So because this is something like AI would say a misperception in many of the stakeholders mind.

And most of the time the stakeholders or senior management of companies, they will have a feeling that something is not working well with the development process because they don't get what they were promised or they get it later than it was promised to them. So if you talk to externals or about internals as well, I think nobody is really happy with their process and how they are doing. And if you look at the externals, they will see a lot of symptoms of what is going

wrong. And if you look at a lot of, if you talk to the internals, they will come with a lot of reasons to you why why staff is not working in the right way.

Yeah. So I think in many software teams, definitely this is the thing that is happening, right? And you also have a few things that you think are the problems in the current status quo of software development practices, right? Maybe if you can outline some of the biggest ones that you think would be good to discuss today. Yeah. I mean, if you started the agile movement at the beginning, the coders, they had a vision when they created this manifesto for Agile software development.

Individuals and interactions, working software, customer collaboration, responding to change, those are all the right values. But business historically struggled with understanding engineers. And so Scrum came up and Scrum, in my opinion, is a pure business practice, like doing acceptance test, making small releases, planning games and and so on.

Those are business practices. Those are not software engineering practices per SE, but it was a tool for business to make the engineers manageable in a way for them. Then the result was that a child kind of became a micromanagement tool because it was used for everything. Product owners, they are receiving a lot of requests every day. Some of the requests are urgent,

some of them are not urgent. But the urgent requests, at one point they get into the backlog and then in the backlog, suddenly they know they have an urgent request that is also planned. And if you have other planned work in the backlog, then your original work gets prioritised down. And so you are never in a position as a team where you can really commit to something because all the urgent requests they are intermingled with what you have already planned. So it's so it's really hard.

And the result is that the team is doing the trade-offs at the very end because the time is running out and then you need to do the trade-offs. But those trade-offs are maybe not the best trade-offs. Such trade-offs, there could have been better trade-offs if they would have done earlier on a higher abstraction level and not just when time is running

out. This is part of my point here that it's important to make the trade-offs early on with the engineers and in the organization that is always striving for efficiency. This causes a lot of people working on their own and then you end up with a different development and product organization because product and engineering, they are optimizing for themselves to cope with the pressure to cope with the efficiency.

But the problem often is the efficiency is only there because it was not completely aligned at the beginning. And then the time is running out and you need to be efficient and then silos are created. China or ticket systems in general are not the ultimate tool to help in such a high pressure solution because developers are out of time. They say, hey, stop, just create a ticket for me and then we

manage it via the backlog. So and then discuss a situation where somebody is creating the ticket and somebody else is just implementing the ticket. And this is for me the the definition of a silo because you have a wall in between there. You have not a process where there is a time and place for new requirements and how you'll find those requirements. In theory, a silo is a nice place to be because you could work blissful a long 8 hours a day.

You're just working on tickets and you went into the next ticket. But in reality, it's not like that. You have a Kanban board with 10 columns, you have a QA, you have a UXQA, you have somebody else need to green light something and so on. And if something is falling through the cracks, the ticket is going back to the developers. You need to context switch as a developer and then you need to increase the font size or or whatever you need to do. And then you put it back.

And it's not just the ticket workflow, it's also you are interrupted all the time because we live in a world where your Co workers cannot work on something without asking you constantly for something. And I mean, even in theory, if we assume that silos would be nice, it's not like that. And AI will also not help us with this solution, not from the communication side, not from the implementation side. It makes product development even more complicated in my

opinion. Because now you need also to bring AI to the table like machine learning engineers, maybe in a separate department, data scientists and and also UX user experience. You need to bring AI expertise and user experience expertise together to make really great product where the AI is really leveraged by the user

experience. Because if you do it traditionally user experience, they don't know how to work with AI tools where you have not a guaranteed response, where you only have response and 5% of the case is the correct one or in 40% of the cases. So you need to bring even more parties together. And This is why I think 1 needs to fundamentally look at how teams are making decisions and such continuously evolving systems. And I'm here to share my mental model about how to achieve this.

Yeah, I think what you just mentioned, right, it happens in many teams, right, When we say people practice Agile, which I think I would say most teams would believe that they practice Agile in some what in some shape or the others, right, Typically Scrum, right, and Scrum Bun as well. So I think the interesting part that you mentioned, it becomes like a micromanagement tool because when it started, the agile movement seems to be moving away from that

micromanagement, right? But these days, I think it happens in many different teams, right? Even the stand ups is more like a status updates where the manager or the leaders keep asking about status and all that. And I can. See the micromanagement danger part there. And ticketing is kind of like the practice in most software

engineering team. You create a ticket for your product requirements, you hand it over to software development, maybe tester, maybe a few other process right in the stages before it gets deployed. So ticketing is like the main collaboration or main communication channel, which I think sometimes there could be a problem, so to speak, right? And people don't talk to each other and they talk just through tickets, right? So I think that also defeats.

Exactly. And I mean, there's a place for ticket systems and in my opinion it's for support work or for reactive work like we are calling it. But feature development with ticket system at its core is not a good idea, because you really removed the collaboration. And there is. Yeah, and especially if the

problem itself is not well defined, right, The design is not well defined. I think it's the communication and you know, the back and forth, probably opinion sharing, right, to come up with the perfect kind of like not perfect, maybe a better design or better solution, right from cross functional roles. So I think knowing about this problem, right, the status quo, so many different things that are not optimal. So tell us a little bit more about your approach right in this move.

Things break silos. What are some of the key practices that you want to advocate today? Yeah, everything is centered around how we slice the work and how we are aligning the teams around this work. What I mean with how the work is sliced, it's for me about how our objectives are defined, how we are slicing problems, how we are slicing solutions and how are we slicing delivery. So the first important thing is to understand that all four

things are different. Things like you have objectives on the highest level, and then you really need to differentiate between problems and solutions because a lot of teams are skipping this step and coming up with a solution too early. And then you also need to really think about how you are slicing delivery. So slicing objectives, that's the easiest rule in my opinion, because you can just have one objective for a team. Like it's either an engagement, it's growth, or it's monetization.

Like on the highest level, A-Team should only have one engagement. Or like a unit where you have a couple of teams, they should all work on the same objective. And we really need to be clear, I'll be focusing this year or this half year on engagement or on growth because this then defines on what problems A-Team should be working on. Yeah. So maybe let's go 1 by 1, maybe objective and then development on that.

So maybe, you know, hearing what you say about slicing objective, I think fundamentally this is one of the biggest problems in many, you know, software engineering team or product team, right is because there are so many objectives given maybe sometimes from the top, sometimes it's from regulations that come, you know, in the middle of the whatever quarterly planning or annual planning, right.

So I think slicing it to work on just one objective probably is kind of like impossible for many of the teams. Or is there anything that you think maybe a change of mindset, a change of perspective and change of priorities that could actually allow team to actually focus on just one objective at a particular time? So maybe from your experience,

share some practices. So when I talk about slicing objectives, I mean I'm focusing on the strategic feature development like what we have as we as a company have on the road map to develop what to achieve our company goals. If you have regulatory requirements and those kind of things, I would try to manage this as what I call reactive

work. Like in a bigger setup, you can always have a part of the bigger part of the team on strategic feature development and then you have a smaller part of the team working on reactive work. And it's just important that the part of the team that is allocated to the strategic feature development that they are really working on on strategic features. And this ratio is something you need to define in an engineering strategy.

At what point you are, do you have a lot of technical debt and and so on. Yeah. Yeah, thanks for clarifying that because I think it's very important, right, If you want to be practical in you know, slicing these objectives. So the ratio is something that every team, every company has to define, right. I think it's something that depends on the stage of the

company as well. Sometimes if you are still product doing product development, right, you could have more ratio of that versus the other reactive thing, right? And sometimes it could change depending on the situation. So let's move to the next slicing that you outline, right, Which is slicing the problem which you know some people use. You meant. I would maybe quickly, I goodly would like to add that most of what I'm addressing here is really towards feature development.

As I said, you need to have keeping the light on the part of the team. You need to have some part of the team responsible for directive work. But all the other things that I have now that will now come, they are mostly related to strategic feature development.

Yeah. Thanks for the addition of that. So let's move on to the next slicing which you mentioned slicing problem, right? And you mentioned. Some problems. Yeah, in some teams they could even skip this or they merge it into solutions straight away, right? So why is it important to slice the problems? Because I, I don't know practically how would you do that? The why for slicing the problems is you need a time and place where you align with the senior leadership.

What problems are you tackling? And then interdisciplinary team where an interdisciplinary for me means product design, engineering, maybe machine learning, maybe some other expertise. It's all in one team and they should work as an empowered team on fulfilling this problem.

This is why it's very important to make this distinguished to make this distinction because if you are starting with a solution too early and you give the team 1/2 thoughts through a solution and say no, now you do. Then the team has no way of really they don't have a saying in what they are building and so they are not responsible for it and they cannot really commit to it. So they will then extend the deadline because they have not really a saying in it and they

assume that it's given that it needs to be like this. But in the most of the cases, on the one hand, it's not completely thought through what really the problem is that we are solving before you're giving something to the team that this is 1 aspect. And as I said, the other aspect is that the team needs to be part of the solution. And really engineering as a first class citizen if you want, is also part of defining the solution.

That's very important. And when we are slicing problems, we are just focusing on what is the current context of the user of the customer and what is our desired outcome. Like this is really the core of the problem definition. This is something I am I've taken from the Shape Up methodology. Shape Up is the product development process from Basecamp. They open sourced it a couple of years ago and they are using such a framing technique as well.

And this really helps for alignment with senior leadership. And there's also a good abstraction level of, of defining what are we doing in the next couple of weeks? Because such a sliced problem should also come with a certain appetite of how much you want to invest. The appetite is also a concept from Shape Up and this appetite is also a concept from shape up and appetite basically is you have a fixed time box, but you have a variable scope in the time box.

And if you bring those two things together, you have a problem. You know what problem you want to solve and you have a idea of how much time you want to spend with this problem. It helps and it guides how the implementing interdisciplinary team is then thinking about solution. Because if you have a certain problem and you say I want to invest six weeks for a solution, then the team will end up with different solutions, then you should say I want to invest one week with a solution.

And so you can use this problem definition together with the appetite as a very good communication technique because business stakeholders can say how much it's worth to them and the team can say what they could then actually deliver for this. Yeah, I like this, you know, breaking down into fixed timeline and variable scope because in many different teams it's always like top down, you know, we have, I don't know like annual road map broken down into quarterly road map and the team

just delivered that, right. But actually if we come up with a well defined problem that is sliced properly according to the time that we are willing to spend maybe as a company or a team, right, then we can come up with different solutions. So I think that's a really novel thing, maybe for some people, but I do really like how it is being done, yeah. I mean, even if you're doing estimates, you end up with variable time anyway because estimates are never correct.

So it's better to embrace this fact and work with a variable scope instead because if your scope is flexible, you can always guarantee quality. You can guarantee the cost and the time that it takes. And so as software engineering is in its nature, because it's a design process, as I said, unpredictable, it's basically just the agreement between senior leadership and the engineering organization. You are now investing 6 weeks, 4 weeks, one week and giving your

best and solving this problem. And within this time box you are flexible how you are solving the problem.

Right. So let's move on to the solutions and delivery, right? So let's say given the team has been given a fixed timeline and a well defined problem, so to speak, right? So how would you slice, you know, the solutioning and the delivery aspects? It's important that you start with the most important thing first, because if you want to end after your time box is over, you need to be able to drop the pen and it needs to be

shippable. So you want to work on one scope of the solution after the another and you want to start with the most important scopes first so that you can always like when we are doing a planning of how we are approaching a feature development initiative, then we're building a graph of scopes. Like we have a handful or 10 scopes and we draw dependencies and how we want to tackle them. And then a line, a cut off line, we move it in from the back to the beginning.

And we always ask ourselves, can we cut the project at this point and does it still make sense or is there something we have moved further down that is really, really important? And if you slice a solution in this way, you always make sure that you need to slide the solution in a way that you can

always stop. Yeah. So I think that is also kind of like novel, right for some people because typically when you are given a requirement, you will come up with the design such that you will just meet whatever that is expected of you, right. But I think this mental model that keep on moving the cutting line, so to speak, right, So that you can deliver value in, you know, the smallest shape as possible, I think that's also

important. While it's important that after every scope that you delivered that it's tested and that it's deployed, it could still be after a feature flag and everything, but it's really important your your definition of done for a scope. Because if you just implement the scope and implement the scope and you move all the testing to the end, then you can also not end after your time box is over. So it's always thinking those

increments. And I really like the granularity of problems, thinking in terms of weeks and resources like 6 weeks, three people working on it because it's a good level of granularity to align with the senior leadership and the rest of the company. And the level of scopes where you, let's say in six weeks you have 8 scopes or something like this. This is also a good granularity to work on one thing for a couple of days and then finish it.

And after every scope, the team really needs to be in this mindset of we need to finish the scope. We need to implement everything that we have in mind, like finish, we need to get it done to work on the next scope. This is also an important part. A lot of the times the teams are comparing what they could have done within the scope and then they use too much time on the scope and it your plan that you have at the beginning, it cuts delayed and delayed and delayed.

So you need to have a really sharp prioritization to finish the scope and also what scopes we need to ship for the whole initiative. So sometimes it also means you need to trust the scopes. For example, I remember an initiative we have planned to roughly build 3 features within this initiative. And we thought, yeah, we make 3 very shallow features because we want to see how customer are responding to it and then in later initiative make one or two

of them better. But then during this six weeks initiative, in this time we had the product manager did a call with the customer showing what we already had. And then we realised, oh, it really does not make sense what we have. And so we changed the scopes of the whole initiative and decided we do two things well and not three things pretty pretty shallow.

So if you work like this, you are really agile in a way that you can adjust what you are doing and you can have real customer feedback guiding you there. Yeah. So I also like what you mentioned earlier about, you know, slicing the work in terms of weeks and resources, right. So weeks is kind of like small enough that you can kind of like BHR rather than some teams actually do it in quarterly planning, right.

So which is kind of like long. So slicing the work is one part that you think is going to help a lot of teams. The other aspect is actually aligning teams against this kind of like work, right? So.

We have missed 1 aspect and this is the slicing of delivery. But it's a short one I think because if you are, you have sliced a solution that you start with the most important scopes and so on and then you actually start working on it and working on it means everybody is working on the same thing at the same time. So it does not mean front end is preparing something, back end is preparing something and then at one point they are bringing it together.

No, it means everybody is working on the same thing. Like the designer, the front end engineer, the back end engineer. Let's say they first start with the overview table of a feature and they all do the same thing at the same time. And then they finish this table and then they start with the edit functionality, and then they do the delete functionality. And everybody's really working on the same thing at the same time.

And this needs some adjustments to work like this to not only chase efficiency, like I said at the beginning, but there's much more chances for pairing up in this kind of setting, working on the same thing. It's a lot of chances that front ends learn something from back end and vice versa. It's pretty hard for designers sometimes to work like this because designers, they need to have a bigger picture, they need to define the styles that they are using and so on.

So this is something that's sometimes a challenge if you switch to this way of working and if you it's really strict, this could be mitigated if you have a good component library already and if you have a ripe major product. If you don't have this, this situation, then you, I tend to be a little bit loose here. So I allow the designers to design a little bit more. And yeah, basically it's not me

allowing them. It's designers come up with the idea that they need to design other parts of the product as well of the initiative as well. To make the decisions now, but we really try to say this is the personal workflow of the designer. We don't need the whole team to give feedback on everything. So because you don't want to end up with 30 or 40 Figma screens and then all the developers are implementing them at one point. I think for engineering is the

same. Sometimes you need to think about the architecture a few steps further than what you're at the moment are doing. But we really try and as a rule of thumb and the teams that I have led that it's like 70 to 80% of the time is really spent together. So the delivery is really sliced in a way that everybody is working on the same thing at the same time.

Yeah. I think the key also when we want to work that way, right, it's not to build the silos within the team where you have specialization either like. Exactly. You don't want to end up with a lot of mini waterfalls, Yeah. Yeah. So I think, yeah, try to avoid from that kind of practice where you have specializations and silo within the team itself. And it may be worse if you assign tickets to different stages while you building the team. Exactly. So slicing is 1 aspect that you

think can help, right? The other aspect is actually aligning the team with this work, right? So tell us a little bit more the importance of this alignment. Yep. So I, I really like the blueprint of empowered product teams here. It's from Marty Kagan from the Silicon Valley Product Group. And the idea is that you have one product team and the product team has everything the team needs.

You have a product manager. Product manager is responsible that the team is delivering value to the customer, but also for the business viability, addressing the business viability risk. This means the connection to go to market like does it make sense what we're building to what we are to the customers that we are acquiring. And this is different from a product owner in a scrum setting. A product owner is only somebody who is writing tickets into a backlog.

Like a product manager comes with a certain skill set. He or she needs to know interview techniques and you really need to own this. This person is owning if the team is really creating value. And then you have designers, they are responsible for the usability risk and for the

experience. And then you have engineers, and it should be insourced engineers, because you need to have insourced engineers to really create this innovation and really use them also for shaping the solution that is built after the problem is defined. So engineers are responsible for feasibility risk and for delivery. And so you're basically building the team with all the capabilities.

So you need to hire engineers that can address this feasibility risk and you need to find the product manager that can own the customer value and the business viability risk. And then you give problems to the team or objectives to the team basically. And then such a team is doing the discovery of the problems and of the solutions that can help achieving this objective and also the delivery.

So they should organise themselves and the level of objectives is the right way of steering such a team.

Yeah, I find that this is the ideal thing that many teams want to practice. But for whatever reasons, right, in practice, many things are not running this way, right? So for example, when we mentioned about empowered product teams, right, I think still many teams are given mandates from the stakeholders and management and maybe they're just given, OK, this is the problem, here's what the solutions that we think would work, just go ahead and deliver

it, right? And product managers become more like a proxy rather than, you know, an empowered one, right, that can come up with the solutions, maybe even thinking about doing interviews, coming up with the well defined problems and all that. So tell us, what do you think we should do in order to kind of like align these teams practices such that it becomes more empowered because it's, I think it's still pretty rare in many software engineering teams.

Yeah. If you look at the problem, you're on the one side, you have the skills of the individuals, that the individuals need to have the skills. And the other part is that you as a technical leader create the organization for it. And so it's really two parts. And the part with the, the part that you as a, as a tech leader can do yourself is like aligning the organization around it.

Here I always like to start with defining the problems, because if you start with the problem definition, you can do it on your own or you can, let's say the product, you have a product manager and he's, he knows what it means to be an empowered product team, but you're struggling with the rest of the organization. They give requirements and so on. Then I feel it's the responsibility for the technical leader to create the process that the team can work as an empowered team.

And this means if stakeholders are coming with concrete requirements like with solutions, you take them and you rephrase them has problems. And then you go back to your stakeholders and you say, are those the problems that you want to address? Just making sure like it's just ensuring and it's not even you can really do this without being offensive. Like you just say we have a new product, we have a new product process. We want to focus on the problems 1st.

And then if you are doing the work for them, but then afterwards you discuss it with them, then sometimes they really they want to make sure that the problems are correct. So they will give you feedback and help you with the product definitions. And then you slowly can educate them that this is your process, but you need to define the process. And but this is a good starting

point. And Yep, the the other solution is where the other situation is, where the stakeholders are, whether it's not an issue with the stakeholders, but the team is not willing to work in this way or not capable. And I mean, here you need to invest in the skills of the people or maybe you need to switch people. Because if you have, if you want to have an empowered team and you only have introverted engineers who only want to work on their tickets, then that's the wrong team.

Maybe you can educate some of them. And for me, the rise of AI is a very good argument for engineers because their skills of writing JavaScript or Go or whatever. I asked them what are they worth in 10 years that you can write JavaScript. I I don't think they're, they're not worth much in 10 years, maybe not even in five years, maybe even not next year, I don't know. But at one point your skills of writing code are not relevant

anymore. I think that is safe to say at the moment and this is my main motivation for the engineers to bring them further at the beginning of the process and really shaping the solutions, be also part of shaping the solutions. Yeah. And this comes back to the earlier, right, when we mentioned about slicing the objectives and slicing the problems, right? Because engineers definitely we can come up with the solutions, right. But understanding the objectives, that's the first

thing, right. And then the problems defining the problems, getting involved in defining the problems, I think that kind of like. Exactly. So we have a review process also for problems, so that engineers read all the problem definitions and can give their feedback also on this stage. So this is the most important step. Be really clear about the

problem you want to solve. Yeah, I really like that because many, many times I've heard the emphasis on the objectives, right, Well defined objectives with clear metrics and all that. And then the problems is something that probably we can practice right in order to involve the engineers to come up with more innovative solutions and they really understand what exactly the problems that we need to tackle to achieve that objectives. Also as part of the alignment of

the teams, you mentioned that you prefer a small team and small here is the 2-3 people team. I think this is really small, but tell us the argument behind this. What I mean is I prefer two to three people collaborating at every point in time. This means two to three people implementing 1 initiative, like implementing one solution to a problem, but it also means two to three people collaborating on shaping the solution. It means two to three people discussing what problems should

be solved. Like I would always aim for small groups that have all the capabilities that they are needing. So this means, for example, let's say we are shaping a problem that we want to solve. So we are shaping the solution. And then you need to have a technical, a senior technical person there. You need to have a product manager, you need to have a designer who knows about interactions. And so they are collaborate and shaping a solution.

But it does not mean that those are the same people need to implement this because sometimes you maybe want to have a different pairing and implementation phase where you are pairing a junior with a senior and maybe it's the same designer and maybe the product managers not that involved during the delivery, just from time to time. So you have then another team of two to three people and would also aim for two to three people making those decisions.

With the senior leadership, it's basically a, let's say ACEO, it's a technical leader, CTO, and it's a product manager or whoever is in responsibility of the process. Because if you have more people, you have more communication because communication scales exponentially. If you have three people, everyone needs to talk to two others, so you end up with three lines of communication. But if you have, let's say 5 people in a team, everybody is

talking to four other peoples. If you imagine it as a graph of people who need to talk to each other, that the picture is much more more complex. Bring together who can make the decision like from a authority point of view but also from a skill point of view and then you can make decisions pretty fast. And they need to be a enabled, they need to have the allowance to make this decision. This is important from a process wise. Right.

Thanks for the clarification. So it's more like a dynamic, kind of like teaming. Of. Group of people working on certain particular thing, right at the time and you mentioned about the communication challenges if let's say you grow into more people, right? Definitely, you know, there are more lines, right, To communicate with each other and not to mention the misunderstanding that could happen as well when you have so many people. One of the aspects is about the

alignment with the value streams, right? This is also partly what you emphasize, right? Alignment with value streams. So tell us what is the thing here? Yeah. So this is an idea from the Team Topologies book from Matthew Skelton and the ideas that you have all the capabilities in the team that you need to deliver value to the customer from the idea of what value we want to deliver to the customer to the delivery. So it does.

For example, bad practice would be to have a dedicated design team, a dedicated front end engineering team, dedicated back end engineering team, because then you have a lot of handovers between the teams. What you really want is to have one team with a designer, a front end engineer and a back end engineer. But the same goes also for other handovers. Let's say you divide your teams

along the customer journey. So for example, if you're an e-commerce and then you have one team for search, one team for the catalog, one team for checkout, one team for payment, one team for fulfilment. So you also have a lot of handovers if you want to change, if you want to implement the change of how you delivering value to the customer, let's say you're implementing A discounting mechanism or

something like this. So also here you want to have teams that are capable to work on all parts of the platform. I think it's too much to dive deeper into the ideas of team topologies because there are really ideas and how you can maintain a coherent architecture and coherent user experience around those kind of teams. But I just want to touch it here because it's also very important if you build such an empowered product team that it really has all the capabilities that's

needed. And this goes a little bit back to the of of the slicing of problems because we need to slice the problems also in a way that they are fitting your teams. But this is something that we will touch in one of the next parts when we talk about how we are mapping the sliced work to the different levels of the organization. Yeah, I think Team Topologies

definitely highly recommend everyone to follow if you haven't heard about it. So I think what you mentioned just now is the concept of stream aligned team, right? So it's one of the team structure that is advocated within the Team Topologies. So let's go to the mapping of the work itself to the organization. So how can people do that? Now I'm basically bringing together the idea of the two to three people always working together with how we are slicing the work.

If you start at the bottom and the delivery team, you have two to three people walking, delivering. Yeah. And then you have a level above, you have the slicing of the solutions there. Normally you would have a three factor of an engineering lead of a product person and the designer design lead. And they, as I said, the more senior people, they should slice how the solutions are looking for this team. And then they have a couple of three or four teams below them.

For them, they are slicing the solution because they have the most insight into the system and then they need to check with them during delivery. And one level above, maybe you have a middle management layer, director of engineering, director, product director design. This is the place where you slice the problems because you need to align to the objective that you're slicing.

You need to align on the objectives on the topmost layer on the CEOCTOCPTOCPO like technical product leadership and also design leadership. So the idea is that you have always two to three people, that you always have the required skills and that they are able to make the decisions like objectives on the top, what problems to address on the director level, if it's a bigger organization, if it's a small organization, it's probably the same people that are slicing the

solutions. Yeah. So I find this kind of alignment is very, very crucial, right, Especially when your organization grows really large, because sometimes people couldn't really identify the work that they're doing, how it actually aligns with the business, right? Be it, you know, efficiency, engagement, revenue, whatever that is, right? So sometimes people just don't understand what problems they're solving, what objectives they're aligning to.

And I think it's a small simple exercise of aligning all these like objectives, problems, solution delivery can really help people to give the clearance like the clearer picture of, you know, what things they achieve together as a company, right? And it's also important to note that this is not top down. It's really a two way exchange like one of the principle of Tokyo asked that stuff is bubbling up from the bottom again.

Like if you have a problem with delivery, you cannot deliver something, then you go one step up to the people who sliced the solution with you. And if you then find out, oh, we need to solve a different problem, then you go one step up again. And so it goes up and down and it really needs to be a dynamic process. This is not because if it would only top down, then we have waterfall again, but for interdisciplinary waterfalls.

Right. So we have discussed so many things right just now about your thing, right move things and breaks our laws. Are there any things that you think we should also cover because the time is approaching almost to the end now. So are there any things that you want to chip in more here? Just maybe one thing for a large

organization, this is that like big organisations and just one empowered product team, I think it's important to think of the reporting structures of the company as a technical leader. With the reporting structure you can steer to a certain degree how the teams are working. If I want the teams to work on a scope by scope, then I let report them scopes. So then they are forced to think in scopes and yeah, they can make it more complicated and work different anyway.

But I probably will find it out because then the results are not in check with what they are reported. This is just important. And there are a couple of tools also from Basecamp, a tool like the hill chart. The idea of the hill chart is that work is more like a hill than a straight line. So you have always an uphill phase when you are figuring things out and then you have a downhill phase of making things happen and then you could align

the scopes on the uphill phase. Then I as a leader understand all the team is with this scope in this phase. They are trying to find out what it's about or I know how they just need to implement it. So this is a different view from you as a leader. And this is what I meant with granularity. When then I see and I can compare the scopes from a couple of teams and I can see are they making good progress or are they having unknowns because they are

flagging the unknowns. I want them to flag unknowns on the hill chart as well. Then I quickly can see if they understand what I want from them, how to work as well. And there are other tools from Basecamp like moving the needle where you have a scale, time is progressing linearly and you manually need to set a needle of how far you are into the

process. But maybe we'll leave a link and people can look it up. It's a tool from Basecamp and it's always inspiring to see what they are doing because they think about product development in such a different way. And then you are still free to implement it in your own tools, in your mirror board and your confluence. However I like to know it. Right.

So definitely, we'll put all of them in the show notes for people who want to study further right about those techniques from Basecamp. So Claus has been a great conversation. I think we all learn a lot about a thing or two, how to optimize our product development or software development, right? So as we reach the end of our conversation, I have only one last question, which I always ask to all my guests. I call this the tree technical

leadership wisdom. If you can think of them just like advice, maybe if you can share your version today that will be great. Yeah, sure. So first would be don't give your team a backlog of stuff. Give give your team a clear goal and a deadline and then let them

figure it out. That is would be my first thing because it also helps you as a leader to really think about what we want to achieve and not get distracted and a lot of small things first, this and this and then and the second one would be stay calm because nobody is doing agile in the right way or not. I have not seen two companies doing the same process. So I think it's important to stop asking yourself if you implement a certain methodology like Scrum or Safe or whatever correctly.

I think it's more important to really observe what is going on in your organization and then adjust accordingly. But. That said, it's a segue to my third advice. You really need to understand what others are doing and what trends are there in the industry. Like we have a lot of interesting trends like multiple development, also a good podcast

episode with you. And there are trends like shape up and you need to talk to other leaders how they are doing it and being exchanged with them to really understand what they are doing. And I think it's more important to understand, as I said, what are the problems of your own team and what others are doing, and then come up with good solutions for them. Yeah, I really love them, Right? Staying calm, right? So nobody actually practiced anything perfectly, I would say, right?

And it's also highly contextual. I will slightly tweak the third one to listen to the podcast. So if you want to learn, you know, about new techniques of other things that people are doing, thought leaders in the industry. So thanks for pointing that out as well. So Claus, if people love this conversation, they want to follow up with you, ask you more questions. Is there a place where they can find you online? Yeah, sure. So I have a blog.

The domain is VO1 dot IO and I'm also active on LinkedIn. So on on LinkedIn I post more shorter things and on the blog I sometimes post longer things. And yeah, I share my thoughts and I test some resonance because I'm also thinking of maybe writing a book about this topic on one day. So if you're interested in interdisciplinary topics and how teams should or can work together, and feel free to

follow me there. And yeah, beyond that, I'd like to invite everybody with listening to this podcast to just connect with me. Also, on a personal level, I'm very curious to hear how others are approaching their team set up, how they are slicing their work, how they are creating

strategic alignment. Yeah, either if they have a concrete challenge or just want to exchange ideas or just share if they're maybe proud of their own approach, because such conversations also help me to develop this topic further. And yeah, in some rare cases, if I have time, I maybe can also help hands on as an advisor or as an interim lead, but I don't want to promise too much. But sometimes it's one thing leads to another and I can help actually.

Yeah, out of curiosity, what is behind this name? VO1 dot IO? It is quite unique I find. Yeah, it's just this mindset of starting with the version 01, like with the the first iteration of my blog basically. And I have kept this mindset since my early days and at the moment I think it's probably my 3rd or 4th iteration of the block. But her name still sticks because it's this mindset. Always create a version 0.1 and then see how the resonance is and then continue from there.

Love that. So yeah, thanks for sharing. Thank you so much for today's discussion, Klaus. I hope people would learn a thing or two again about move things break silos, right? Not break things, right? Yes, move things, break silos.