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

[00:01:27] Introduction

Henry Suryawirawan: Hello, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me, Klaus Breyer. So he’s kind of like an experienced CPTO, right? I haven’t heard about the term CPTO before, I guess, is 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.

Klaus Breyer: Yes. It’s a pleasure. It’s an honor to be here.

[00:02:10] Career Turning Points

Henry Suryawirawan: Klaus, maybe, in the beginning, uh, I want you to share a little bit more about yourself, right? If you can share any career turning points that you think we can learn from you, I think that will be great.

Klaus Breyer: 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 in 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. They’re not using the right tools for better handovers and so on. But yeah, because this was not something that was taught 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 every time you have the possibility to start over. So it’s a good start into the career, in general, like 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 a B2B marketplace SaaS 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 managers.

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 and tech 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 SaaS apps, it’s in my opinion, it really makes sense to combine those skills.

And yeah, 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. In interim management stints, I’m basically infusing my startup spirit into corporates at the moment. Like building startups inside of a 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, I was, uh, responsible for whole business units.

[00:05:26] Critical Key Skills as a CPTO

Henry Suryawirawan: 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, CTO, CPO, 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 its own way. Technology thinks the other way. Sometimes they balance each other, sometimes they fight each other. But if you are one person, what are the some of the critical key skills do you think?

Klaus Breyer: I mean, interestingly, if you look back 10, 20 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 a special discipline. So maybe even somebody at the moment having the title CTO could also have the responsibility for product.

So it’s again, 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 and your team, or 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 sparing 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 sparing partner.

[00:07:40] Juggling Between Being Optimistic vs Pessimistic

Henry Suryawirawan: Yeah, so sometimes also in my view, right, so looking at all the CPO, CTO 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, uh, good vision, you know, uh, very far ahead. And sometimes the technology is the pessimistic one. 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?

Klaus Breyer: 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 ideal customer profile? What 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 debt because this is the biggest issue. Because we cannot scale with the tech that we are having. So for me, it’s like a pendulum. I need to decide where I’m focusing at every, um, moment or how I it down to a joint strategy at the end that it makes sense for both worlds. The challenges that the company’s facing.

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

[00:09:15] Move Fast and Break Silos

Henry Suryawirawan: 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, uh, 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?

Klaus Breyer: So as I said, I’m always, since always, fascinated with the challenge of how people are working together, because I’m basically responsible to how people are working together since the early days of my career. And so I learned, 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 one 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 specialize better on a single task. And then Henry Ford could produce eight cars in 12 hours instead of one 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 startup. 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 the 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 kickstarted 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 and what context and how we are aligning those things.

[00:13:08] The Difference Between Manufacturing and Software Development

Henry Suryawirawan: 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 a 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, uh, I think in many, many literature and maybe Agile practices and all that, it seems that this kind of process actually is not optimal, simply because, you know, there are a lot of waste, 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 any manufacturing process. So maybe what do you think is the biggest difference?

Klaus Breyer: Yeah, the biggest difference is that the software engineers, they need to find out how they are solving the problem. Cause if you are producing a woodshed or a 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. On 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 designed as well.

Henry Suryawirawan: Yeah. So I think what you said is, uh, 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?

Klaus Breyer: 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 a 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 we try to how to dissect the problem and so on. And writing code, we probably will do less and less in the future with AI. So it’s more and more important that engineers are really used, leveraged in a way to solve problems.

Henry Suryawirawan: 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 a, I would say a misperception in many of the stakeholders mind.

Klaus Breyer: And most the time, these 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, about internals as well, I think nobody is really happy with their process and how they’re 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 stuff is not working in the right way.

[00:16:51] The Problems with the Status Quo of Software Development Practices

Henry Suryawirawan: 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.

Klaus Breyer: Yeah. I mean, if you start at the Agile movement, at the beginning, the coders, they had the 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 tests, 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 Agile 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 now they have an urgent request that is also planned. And if you have other planned work in the backlog, then your original work gets prioritized 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 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 that could’ve been better trade-offs if they would’ve 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 earlier 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 we need to be efficient and then silos are created. Jira or ticket systems, in general, are not the, uh, 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 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 find those requirements.

In theory, a silo is a nice place to be, because, um, you could work blissful and long, eight 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 UX QA, you have a somebody else need to greenlight 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 whatever you need to do. And then you put it back. And it’s not just a ticket workflow, it’s also you are interrupted all the time. Because we live in a world where your coworkers 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 products 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 in 5% of the cases, the correct one, or in 40% of the cases. So you need to bring even more parties together. And this is why, I think, one needs to fundamentally look at how teams are making decisions in such continuously evolving systems. And I’m here to share my mental model about how to achieve this.

Henry Suryawirawan: 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 somewhat, uh, you know, in some shape or the others, right? Typically Scrum, right? And Scrumban 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 standups 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 the purpose.

Klaus Breyer: Exactly, yeah. 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 remove the collaboration and everything.

[00:23:50] Key Practice 1: Slicing Work

Henry Suryawirawan: Yeah. And especially if the problem itself is not well defined, right? The design is not well defined, I think is the communication and, you know, the back and forth, probably, opinion sharing, right, to come up with a 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 wanna advocate today?

Klaus Breyer: 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 you really need to be clear is are we 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.

Henry Suryawirawan: Yeah. So maybe let’s go one by one. Maybe objective and then problem and all that.

[00:25:51] Slicing Objectives

Henry Suryawirawan: 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 they 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 here some practices.

Klaus Breyer: 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 roadmap to develop, what to achieve our company goals. If we 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 so on? Yeah.

Henry Suryawirawan: Yeah. Thanks for clarifying that because I think it’s very important, right, if you wanna be practical in, you know, slicing these objectives. So the ratio is something that every team, every company has to define, right? I think, uh, 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…

Klaus Breyer: I would maybe quickly, I quickly 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 as part of the team. You need to have some part of the team responsible for the reactive work. But all the other things that I have now, that will now come, they are mostly related to strategic feature development.

[00:28:30] Slicing Problems

Henry Suryawirawan: 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 in some, 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, yeah, I dunno, practically how would you do that?

Klaus Breyer: 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 a half thought through a solution and say, now, 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’s needs to be like this. But in 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. So this is one 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, um, 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 problem definition. This is something I am, I’ve taken from the Shape Up methodology. Shape Up is the, uh, 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 it’s also a good abstraction level 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.

Appetite is also concept from Shape Up. And this appetite is also 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 an 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 solution, then the team will end up with different solutions than if you 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.

Henry Suryawirawan: 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 roadmap broken down into quarterly roadmap and the team just deliver 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.

Klaus Breyer: 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 an agreement between senior leadership and the engineering organization. You are now investing six weeks, four weeks, one week in giving your best in solving this problem. And within this time box, you are flexible how you are solving the problem.

[00:33:25] Slicing Solutions

Henry Suryawirawan: 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?

Klaus Breyer: 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 other. 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 are building a graph of scopes. Like we have a handful or 10 scopes, and we draw dependencies on how we want to tackle them. And then a line, a cutoff line, we move it then 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 slice a solution in a way that you can always stop.

Henry Suryawirawan: Yeah. So I think that is also kind of like novel, right? For some people, because typically when you are given a requirement, you’ll come up with a 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.

Klaus Breyer: And 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 definition of done for a scope. Because if you just implement a 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 six 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 eight 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. ‘Cause that’s also an important part. A lot of the times, the teams are comparing what they could have done within a scope, and then they use too much time on a scope. And then your plan that you have at the beginning, it gets delayed and delayed and delayed. So you need to have a really sharp prioritization to finish a scope and also what scopes we need to ship for the whole initiative. So sometimes, it also means you need to adjust the scopes.

For example, I remember an initiative we have planned to roughly build three features within this initiative. And we thought, yeah, we make three very shallow features because we want to see how customer are responding to it. And then in a later initiative make one or two of them better. But then during this six weeks initiative and this time, we had our product manager did a call with the customer showing what we already had. And then we realized, 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.

Henry Suryawirawan: 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 kinda like be agile 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 gonna help a lot of teams. The other aspect is actually aligning teams against this kind of like work, right? So…

[00:38:03] Slicing Delivery

Klaus Breyer: We have missed one aspect and this is the slicing of delivery. But it’s a short one, I think. Because if you are, you have sliced the solution that is 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 frontend is preparing something, backend is preparing something, and then at one point, they’re bringing it together. No! It means everybody is working on the same thing, like the designer, the frontend engineer, the backend 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 frontends something from backend 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 do it really strict, this could be mitigated if you have a good component library already. And if you have a ripe, major, broad 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, uh, 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, it’s the same. Sometimes you need to think about the architecture a few steps further than what are at the moment are doing. But we really try, and there’s a rule of thumb, and the teams that I have led that is like 70 to 80% of the time is really spent together. So the delivery is really sliced in a way that everybody’s working on the same thing at the same time.

Henry Suryawirawan: Yeah. I think the key also when we want to work that way, right, is not to build the silos within the team where you have specialization either like, you know.

Klaus Breyer: Exactly, and you don’t want to end up with a lot of mini waterfalls, yeah.

Henry Suryawirawan: So I think yeah, try to avoid from that kind of practice where you have specializations and silo within the team itself. And may be worse, if you assign tickets to different stages while you’re building the teams, yeah.

[00:41:09] Key Practice 2: Aligning Teams

Henry Suryawirawan: So slicing is one 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.

Klaus Breyer: Yep. So I really like the blueprint of empowered product teams here. It’s from Marty Cagan, 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 skillset, 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 organize themselves and the level of objectives is the right way of steering such a team.

[00:43:21] The Effective Teams Alignment Practices

Henry Suryawirawan: 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, and 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, okay, 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.

Klaus Breyer: Yeah. If you look at the problem, you, 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 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 is, 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 a 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 as 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 first, 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, this is a good starting point.

And yeah, the, the other solution is where… the other situation is where the stakeholders are, where there’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 it’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 ask them what are they worth in 10 years, that you can write JavaScript. 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.

Henry Suryawirawan: 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, uh…

Klaus Breyer: Exactly, yeah. So we have a review process also for problem 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.

Henry Suryawirawan: 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.

[00:48:10] Working in Small Teams at a Time

Henry Suryawirawan: Also as part of the alignment of the teams, you mentioned that you prefer a small team, and small here is like two, three people team. I think this is really small, but tell us the argument behind this.

Klaus Breyer: What I mean is I prefer two to three people collaborating at every point in time. This means two to three people implementing one 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, 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 collaborating in 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 in the implementation phase where you’re pairing a junior with a senior, and maybe it’s the same designer, 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 uh, let’s say, a CEO, 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, five people in a team, everybody is talking to four other people. If you imagine it as a graph of people who need to talk to each other, 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, uh, enabled. They need to have the allowance to make this decision. This is important from a process wise.

Henry Suryawirawan: Right. Thanks for the clarification. So it’s more like a dynamic, kind of like teaming, uh, of a 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.

[00:51:07] Alignment with the Value Streams

Henry Suryawirawan: 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, uh, what is the thing here, yeah?

Klaus Breyer: So this is an idea from the Team Topologies book from Matthew Skelton. And the idea is 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, a bad practice would be to have a dedicated design team, a dedicated frontend engineering team, dedicated backend engineering team. Cause then you have a lot of handovers between the teams. What you really want is to have one team with a designer, a frontend engineer, and a backend 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 fulfillment. So you also have a lot of handovers if you want to change, if you want to implement a change of how you are 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 in 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, uh, 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.

[00:53:15] Mapping the Sliced Work to the Organization

Henry Suryawirawan: 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?

Klaus Breyer: 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 in the delivery team, you have two to three people working, delivering, yeah. And then you have a level above, you have the slicing of the solutions there. Normally you would have a trifecta 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 a place where you slice the problems, because you need to align to the objectives that you’re slicing. You need to align on the objectives on the top most layer on the CEO, CTO, CPTO, CPO, 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 then are slicing the solutions.

Henry Suryawirawan: 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?

Klaus Breyer: 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 the OKR is 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 waterfall.

Henry Suryawirawan: Right. So we have discussed so many things, right? Just now, about your thing, right? Move things and break silos. 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 wanna chip in more here?

[00:56:41] The Importance of Reporting Structure in the Large Organization

Klaus Breyer: Just maybe one thing, for large organization, this is that, like big organizations 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 then 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’re 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, oh, 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 for me as a leader. And this is what I meant with granularity when then I see, then 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 where time is progressing linearly and you manually need to set a needle of how far you are into the process. But maybe we 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 Miro board and your Confluence or however you like to do it.

[00:58:52] 3 Tech Lead Wisdom

Henry Suryawirawan: Right. So definitely will put all of them in the show notes for people who want to study further, right, about those techniques from Basecamp. So Klaus, it’s 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 three technical leadership wisdom. If you can think of them just like advice, maybe if you can share your version today, that will be great.

Klaus Breyer: 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 in a lot of small things. First, this and this, and then.

And the second one would be, uh, 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 moldable 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.

Henry Suryawirawan: Yeah, I really love them, right? Staying calm, right? So nobody actually practice anything perfectly, I would say, right? And it’s also highly contextual. Uh, I would slightly tweak the third one to listen to the podcast. So if you wanna 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 Klaus, if people love this conversation, they wanna follow up with you, ask you more questions, is there a place where they can find you online?

Klaus Breyer: Yeah, sure. So I have a blog. The domain is v01.io. And I’m also active on LinkedIn. So 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, um, I’d like to invite everybody who’s 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, uh, one thing leads to another and I can help actually.

Henry Suryawirawan: Yeah. Out of curiosity, what is behind this name? V01 .io, right?. It is quite unique, I find.

Klaus Breyer: Yeah, it’s just this mindset of starting with the version 0.1, 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 third or fourth iteration of the blog, but the 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.

Henry Suryawirawan: Love that. So yeah, thanks for sharing. Thank you so much for today’s discussion, Klaus. Uh, I hope people would learn a thing or two again about move things, break silos, right, not break things, right? So move things, break silos.

– End –