#98 - Professional Agile Leadership With Empiricism, Catalytic Leadership, and Self-Management for Agility - Kurt Bittner

[00:02:02] Episode Introduction

Henry Suryawirawan: Hello, my friend! Welcome back to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. And this is the episode number 98. If this is your first time listening to Tech Lead Journal, make sure to subscribe and follow the show on your podcast app and social media. And for those of you who want to contribute to the creation of this podcast, support me by subscribing at techleadjournal.dev/patron.

My guest for today’s episode is Kurt Bittner. Kurt is the author and editor of many books on agile product development, including co-authoring the recent “Professional Agile Leader” book. In this episode, we started our conversation discussing the common misconception of Agile in the modern day. And in the discussion, Kurt emphasized that empiricism should be at the heart of agility, especially for solving complex problems. Kurt then explained the importance of aligning company’s direction and goals, using outcomes instead of using activities or outputs. In the second half of the episode, Kurt and I discussed the concept of a self-managing team, what characteristics and attributes we can observe from a self-managing team, and the important role of catalytic leadership in building such teams. Kurt also explained how to measure the self management spectrum of a team by measuring decision latency and also shared some great advice on how to reduce decision-making dependencies in organizations.

I really enjoyed my conversation with Kurt, getting a number of insights from this conversation that includes the importance of empiricism in agility and how to build and improve a self-managing team by measuring its decision latency. If you also find this episode useful, I would appreciate if you share it with your friends and colleagues who can also benefit from listening to this episode. It is my ultimate mission to spread this podcast to more people, and I need your help to support me towards fulfilling my mission. Before we continue the conversation, let’s hear some words from our sponsor.

[00:05:30] Introduction

Henry Suryawirawan: Welcome everyone to another new episode of the Tech Lead Journal podcast. Today with me, I have a guest named Kurt Bittner. He has been working to deliver a lot of products in his very long journey in his career. So nearly 40 years. And he’s also a very well-known author and editor of many books on Agile product development. Some of the books are like “Nexus Framework for Scaling Scrum” and the recent one is going to be published soon, which is titled “Professional Agile Leadership”. We have been trying to schedule this conversation from a long time ago. So I’m really actually very pleased to have the chance to talk to you today, Kurt. So looking forward for this conversation.

Kurt Bittner: Yes, me too.

[00:06:08] Career Journey

Henry Suryawirawan: So Kurt, I always like to ask my guests to introduce themselves, maybe telling us more about your career highlights or any turning points.

Kurt Bittner: As you mentioned, actually this will be my 40th year since graduating from university. So, I’ll try not to use up all of our time in the podcast talking about what I’ve done. I think the things that are really interesting are that partly because I ended up working in a very small group within a large organization. It was actually in the end user community. We had full license to really develop however we wanted. And so, on my own, intuitively, I was working in a very Agile way. We were working in, you know, a couple of week sprints, delivering things, seeing what worked, fixing it. So I’ve never actually worked in a traditional waterfall kind of way in those 40 years, which is kind of surprising to me.

But what stands out is that I’ve always had a sort of a desire to experiment and try to see what works, what doesn’t work. The only way that I found that really works out is that you have to build something. You have to build something, test it. And sometimes it’s testing the functionality and sometimes it’s testing performance characteristics, or other quality attributes. But building and testing, getting feedback, and then inspecting and adapting is really at the heart of agility. This isn’t something just goes back to the Agile Manifesto. In fact, I think the Agile Manifesto, in a way, was a culmination of a lot of people’s experience over, let’s say, the previous couple of decades. So, when I run into people today who act like Agile is a new thing, I kind of smile and try to explain that, really, all of this dates back to the scientific method where you form a hypothesis, you run an experiment, you gather data, you look at, you know, is your hypothesis proven or not. So in a sense, almost all of what we’ve experienced in terms of modern civilization, in terms of its progress, is really based on that. Agility really just sort of takes that into a software development context or now a broader business context.

In terms of sort of highlights, I spent about six years working in that large organization, but within the small group and we kind of developed our own agile techniques. And then I decided to do something different. I went to go work for a relational database vendor. You might have heard of a company called Oracle, and I spent about four years there doing consulting. And then I spent a couple years working for a startup that was doing object-oriented databases in the early nineties. Then kind of went into more software development process improvement kind of things. I worked for Ivar Jacobson for a bunch of years and then ended up in product development at Rational Software. We were working with Agile teams there, working on them, and then managing some larger groups. Then Rational was acquired by IBM. Then I did a number of different product development things at IBM. Including something that some people may have heard of called the Jazz project, which was sort of an offshoot of Eclipse. Then went back into sort of more organizational change kind of consulting for about the next five years. Spent three or four years as an industry analyst, working for Forrester research.

And then in 2016 joined Scrum.org and have been working on some of the things you talked about earlier. So, lots of different things. I found that I just had a need to challenge myself. So, oftentimes, I would get to a point where I was successful doing one thing. I’d say, I really need to mix this up and try something different. Sometimes that’s a little scary and sometimes very scary. But it’s always good. You always learn something and grow and progress.

[00:09:35] Empiricism in Agility

Henry Suryawirawan: Thanks for sharing your story. So I was really interested when you say you didn’t have a chance to work in a traditional waterfall method before. A lot of us, even including me, youngsters, we always started with the waterfall project. Maybe, yeah, due to time, Agile is becoming more popular. But I think a lot of things that you mentioned earlier, about Agile, empiricism, scientific method and things like that seems probably not so emphasized in the Agile modern days. And that’s why probably Agile is having a lot of tough times this day. Can you tell us a little bit more about this misconception of Agile in the modern days? And what’s the importance of this empiricism in Agile?

Kurt Bittner: Yeah. I find that happens a lot. What I think people misunderstand about, I’ll say an agile approach, but we could say Agile methodologies is that they come to the problem, I think, with a mindset that Agile is a process, that you can learn how to do that process, that it consists of activities and outputs, and if everybody simply does all the activities and all the outputs, then you’re Agile. They’re sort of missing the point. In fact, they’re definitely missing the point is that the events that you might perform like a daily scrum, for example, it’s important because it helps you do other things. But simply because you do a daily scrum doesn’t mean that you are being Agile. And so, the fundamental kind of foundation of agility, well, it usually starts with planning and people don’t talk about it this way. But it’s to start with some, in a sense, assertion about value. It’s to say, we think if we build this, these set of product backlog items, for example, we think that if we build that and deliver it to customers, it will result in some positive thing that we want, usually an improvement in customer experience. And that improvement in customer experience may in turn lead to other things that the business cares about, like revenue and profit and things like that. So every sprint or every iteration or whatever you wanna call it is really an experiment about value.

The problem that a lot of organizations today, I think, run into is that they think agility is about going faster. They think that, basically, it’s just a way of delivering a particular chunk of scope faster than they would’ve done with waterfall. But that’s not really the point because what we found through a lot of research, and there’s some really interesting things that a guy named Ronny Kohavi did at Microsoft – you can go to something called ExP-Platform.com to learn about this research. The interesting thing there is that at Microsoft, they were doing most of their data analysis initially on some of the web products and eventually expanded it to all products. Reason why I’m using Microsoft is that the same data shows up whether you look at Amazon or Google or any of these companies that you sort of think of as really leaders in being Agile. Anyway, what they found in this research is that when they tested ideas to see if those ideas produced the desired results that they were looking for, about a third of the ideas produced the result that they were looking for or produced a positive result, about a third of the ideas produced no result. It didn’t produce a positive or negative. It’s simply nothing. And a third of them actually produced negative results.

So when you look at that collectively, what I’ve seen personally, this is true whether you’re talking about a bank or whether you’re talking about a government agency or a startup product company, is that most of their ideas are not actually valuable. And you can see this in your own use of products. You look at the product and go, why is this stupid feature in there? I don’t want that. I don’t want that feature. It doesn’t do anything useful for me. For somebody else it might do something useful. But a lot of the stuff, even in a small mobile app, it doesn’t do anything useful. The only way you can figure out whether something is useful or not is to actually build it or build some part of it and show it to people and then get their feedback.

Well, the organizations that think Agile is just about speed miss out usually because what they do is they deliver a release, but they never measure the customer experience. They just move on to the next set of product backlog items that are in the next sprint or in the next release. So they’re completely missing the point about what agility can do and what empiricism can do for you. As a result, they’re so concerned about waste and cost. But the biggest waste and cost that you have is basically building things that nobody wants, and then maintaining that over years and years and years, because you’ve never measured whether anyone uses those things. So I think that just waking up to that single thing to realize that most of what you think is valuable is not valuable. You can only test whether it’s valuable by delivering it and measuring, and then you have to inspect and adapt your future plans based on that.

So, you sort of tear that apart and say, what was wrong with waterfall? Well, the problem with waterfall is that you take 6, 9, 12, 18 months, sometimes years, to deliver something only to find out that it wasn’t valuable at all. Or the markets moved, or you misunderstood what they wanted. We’ve seen that time and time again, big organizations would spend millions and millions of dollars building things that never got used by anybody. So the real key is to deliver in shorter increments, measure the result. That’s the important thing that a lot of people who claim to be agile aren’t doing. They’re never measuring the result. They just put it into production and “Yay. We’re done.” That’s not very effective.

So anyway. A long way of saying that empiricism really is at the heart of agility. It’s not about speed. It’s not about efficiency. It’s not about cost reduction. Although if you do it right, it is faster. And if you do it right, it is cheaper and you have less waste. But the main point is that you’re eliminating the waste related to what various authors have called overproduction. Producing things that nobody wants. At the same time, you’re getting more effective and more efficient at how you deliver those things. That’s the thing that I think is really sort of almost life changing. Once you realize what that empiricism can do for you, it really changes the way that you look at things. Because once you realize that most of the ideas that you have aren’t valuable, then you have to say, “Oh, okay, well, how do we find out if they’re valuable?” I get really excited about that topic.

Henry Suryawirawan: Yeah. So I think there are so many gist and insights when you explain that. So the research in Microsoft, I heard that in one conversation before that 33% or 30%, only 30% of those ideas that you produced actually produce value. So I think in many organizations, there are many ideas that fail. And Agile is not a way to just making things faster and producing results faster. Actually, the key points is about empiricism, right? This short feedback cycle loop that, actually, if you do it right, you will get things faster. So don’t just focus on the results, but also the process.

[00:16:17] Going in the Right Direction

Henry Suryawirawan: I also like the things that you mentioned about planning. Knowing what values that you want to deliver. Because one of the things that I read from your blog, you said that many organizations actually don’t really know if they’re going in the right direction. To me, this is a very interesting statement. Can you elaborate more? Why do you think so?

Kurt Bittner: Yeah. Well, one is because I’ve talked to a lot of organizations and asked them what their goals are. A while back, we came out with a new edition of something at Scrum.Org called evidence-based management. So you can go on Scrum.Org and find out more about that and also read some of the articles I’ve written. But one of the things that we looked at are basically what are people targeting when they’re looking at goals? We came up with three kinds of things.

So those three things are activities, outputs, and outcomes – customer outcomes. Example of a goal based on an activity would be to say something like, we want to see a hundred percent staff attendance in the next quarter. So that’s just measuring what people are doing. An example of output would be something like, we want to produce a new release of the product Y in the next four months. So you’re producing something. You’re making something. Well, outcomes are focused on things like we want to improve customer experience by X percent. Maybe even more specifically is that we want to satisfy this particular outcome that customers are looking for, that they’re not able to achieve today. We want to let them do something new that is valuable to them.

What’s interesting is that most organizations, when you look at what they measure and what their goals are, they’re based on activities and outputs. “We want a new CRM system by next year. We want to make sure this project is on time and on budget.” That, again, is sort of a combination of activity and output. When you ask them, what are you trying to achieve? And you can do this when you look at a goal, you can ask the question of why do you want to achieve that? So why do you want to have a hundred percent employee attendance? Well, because then we can get more work done. Why do you want to get more work done? Eventually, it rolls up into something that should be something related to customer outcomes. If you can ask the question, why do you want to do that? And there’s some other thing (that is the reason), why you’re doing that? Then that other thing should be the goal.

We’re kind of trying to push people in the direction to be more clear about what they want to achieve. You don’t want to install a new CRM system just because you’re doing it. You might say, well, we want to become more efficient. Why do you wanna become more efficient? Maybe it’s, you know, do better than our competitors. But ultimately, a new CRM system, you’re probably doing that because you want to have more positive interactions with your customers. So that they don’t get frustrated by saying, “Oh, you know, I already told you all that stuff the last time I called. Why are you asking me this again?” And so, you have all the information about the customer right there. I’m just using that as an example.

But the key thing is that organizations, many of them have goals based around activities and outputs. And they really need to focus on outcomes because that’s the real reason they’re in business. It’s to serve customers in some way, and in some way that the customers can’t get from anywhere else. So that’s what makes you more competitive is that you can do things for the customer and that no one else can do. Being clearer about that really helps you help everyone. So that’s what the whole goal setting ends up being important.

And that’s why I mentioned earlier that if you think about every sprint or every iteration is an experiment about value. It shouldn’t be about, you know, we have this list of 25 product backlog items that we want to deliver. Again, back to the question of, okay, those are outputs. Why do you want to deliver those things? Well, because we think that it would change the customer in this way, or maybe the answer is we don’t know.

So, here’s a little nugget on product releases is that a product release should move the needle in terms of customer experience. It should deliver at least one outcome to a particular group of customers. You could use UX modeling terms like persona there. So if the release doesn’t deliver at least a changed outcome to some group of people, why release it? No one’s going to get any value from it. You know, you should look at okay, maybe we’re not implementing the right set of product backlog items in order to achieve the outcome we want. So it helps you to frame your work if you can start talking about customer goals. What is this really going to do for people? And then you have to ask yourself, how would we know if that is true? What are we going to test to make sure that we actually know that we did improve the outcomes?

I think it helps the dialogue. Because I find so many teams, whether they’re doing Scrum, or other Agile practices, or even waterfall, they have no idea why they’re doing things. We’re doing it because the product owner said so. Okay. But the product owner has a responsibility to basically be able to explain why we’re doing this and how that connects to value. If they can’t do that, then maybe the product owner needs to reframe the way they think about things. I mean, too often, product owners are merely sort of pass-through conduits from somebody else who’s giving them a list of product backlog items. And then product owner is not really a product owner. They’re just sort of a project manager, making sure all these PBIs get done. Those are all dysfunctions, of course. I don’t recommend that’s what product owners should do. But if they really own the product, then they should be owning the value that they deliver to customers. It really helps to talk about outcomes in that conversation instead of just, we’re doing all these PDIs, and we’re achieving this velocity and all these things.

Henry Suryawirawan: Thank you for sharing this activity, output, and outcomes. I feel a lot of times in many organizations there is a loss in translation. So maybe leaders know the outcomes they want to achieve. But during maybe breaking it down to team level tasks or activities, they didn’t actually tell what is the outcome. And what you mentioned, like so many product managers becoming just a conduit, right? So I had a chat with Mary Poppendieck about this as well. She thinks that a lot of this kind of people are actually becoming just proxies. Translating message from one way and the other. So I think, yeah, all these are like anti patterns. The key thing is that the team should know about the outcome.

[00:22:18] Agile for Complex Problems

Henry Suryawirawan: I think there’s another thing also in your article, you mentioned about so many times in the product development teams, we actually don’t know what is the outcome that really translates to users, maybe increase of satisfaction or maybe increase of number of users. The value is like unknown, right? So this is where, actually, we should emphasize a lot more about Agile and empiricism versus when you really have the value. So maybe Agile is not so much more important in this case. So tell us more about this paradox that when you have a lot of uncertainty in value, then Agile is actually the way to go.

Kurt Bittner: There’s some interesting things in Dave Snowden’s Cynefin model, where he talks about the role of empiricism in solving complex problems. And that’s really where Agile practices shine is that when you have a complex problem that doesn’t have a defined answer, it’s not possible to reason out the exact set of things that you need to do to solve that problem. So, you have to use empiricism to really seek towards the answer. Because it’s complex too, is that sometimes the answer’s changing over time. Customers are constantly shifting. They get something from a competitor and all of a sudden that changes their notion of what they want. But it’s interesting, and it’s engaging to have everybody on the team, so it’s not just the product owner who’s in the sense responsible for value. It’s also the developers on the team have a responsibility to sort of really understand what that value is and come up with creative solutions.

I think one example of a really mature kind of team is that the product owner could simply say, here’s the outcome that we want to achieve. Instead of using product backlog items to basically dictate features and micro features to the team, they open up and have a discussion. That’s to say, what do you think we could do to achieve this outcome? And the developers often have really good ideas about how they might achieve that.

So there’s a really good example and hopefully, I’m getting the details right. Because I’ve heard it a long way downstream from the people who did it. But there’s this feature in Amazon where you add something to your cart and then you see this thing that says, people who bought that thing also bought this thing. So the story behind that is that the developer came up with that idea that said, Hey, that might be really interesting. Some executive basically said, “Don’t do that. I order you not to do that”. Because anything that distracts them from checking out, that executive thought that’s going to potentially delay the sale, or it’s going to reduce our close rate or conversion rate. So anyway, the developer went and had it implemented it, anyway. Obviously, it’s turned out to be a huge revenue source for the organization. Because you look at it and you go, “Wow, gee. I didn’t even know I needed that thing. But yeah, I kind of do.” You know, yeah. Sometimes it’s an annoyance. Most people just ignore it if it’s information that you don’t need. So, that’s an example and a big example of how often developers understand the customer better than those executives or better than the product owners.

I find that it would have to be a very mature team that had a lot of trust in each other for the product owner really just talk about, do planning in terms of, well, here’re the outcomes. What product backlog items do you think we need? But I’ve seen that happen, especially in areas where, basically, you’ve got developers building tools for developers. Because the developers know what developers want. So, in that case, the product owners, not quite along for the ride, more helping guide the discussions rather than dictating a set of product backlog items that they’re going to do. So I think this conversing in terms of outcomes, that actually is really important for everyone. That’s not just a product owner thing or an executive thing. Everyone on the team having clarity about what they’re trying to achieve can lead to much better ideas being developed.

Henry Suryawirawan: And this is also a point where you mentioned that most of us actually produce a lot of waste. We just don’t know about it yet. So I think when I heard about your story, about someone dictating what we should do, we just do it for the sake of just following orders. But maybe looking back, maybe after it gets deployed or released, we see that a lot of it becomes waste, and when we move on to more features, we get a lot of more features piled up and, actually, those are not producing as much value as we hope in the beginning. Thanks for sharing this Amazon story as well. I haven’t heard about it. So I didn’t know that " people also bought this thing" is actually something that comes from an outcome-based approach from the team.

[00:26:26] Self-Managing Team

Henry Suryawirawan: One thing that is also mentioned a lot about agile team, right, is this concept about self organizing team. I know there are many definitions about self organizing team or maybe some people think they do have self organizing team. But I think there’s essence that you also explained quite well. So can you describe what do you mean by self organizing team in an agile team?

Kurt Bittner: I’ll also make a distinction between self-managing and self-organizing. They’re actually related concepts. Self-organizing just refers to how you come together. Self-managing refers to on an ongoing basis, how do you make decisions? There are a couple things behind this. One is that there’s a fair amount of research that people actually perform at higher levels when they feel three things – and this comes out of, Dan Pink wrote a book called “Drive” that talks about this – autonomy, mastery and purpose. And so the self-managing piece of it is about autonomy. So in a self-managing situation, the team basically given broad goals about what they want to achieve has the freedom to decide how we’re going to work, how we’re going to make decisions, and they’re accountable for delivering the outcome. So it’s not like they can just do whatever they want. There’s even more accountability, because instead of them just saying, “Well, you know, I did what you told me to do, and if it’s wrong, well, too bad.” In the case if they’re accountable for outcomes, then they actually feel ownership for delivering that customer experience.

The first idea behind it is really that there’s this term we use called bottom up intelligence. It’s that the people who are closest to the work are best able to make decisions about it. So, you know, I think everybody would probably agree that you shouldn’t probably have the CEO of a company making decisions about the Continuous Integration environment that developers are using. I mean, we can all see that, okay, that probably doesn’t make sense. Even if that CEO used to be a developer like 10 years ago, they’re just not current with the current technology. But it extends lots of other things. It’s like, well, what about how they do tests? Well, if they’re accountable for the outcomes, they should be able to decide how they do testing. So instead of micromanaging them by having a separate QA department and then you need independent verification. Yeah. Independent verification is important when you have problems that are complicated, but not complex. In other words, you know what the answer is. So it’s important to have an independent verification. But in a lot of cases that can be built into automated testing, that’s part of the delivery pipeline.

So, anyway, back to that thing. The bottom up intelligence says that people who are closest to the work should be the ones who are deciding how to do that work. You can see examples of these differences between organizations. Let’s say you are running a warehouse. The people who actually have to go and pick the items and put them in orders and all that probably have lots of experiences about and ideas about how to make that process better. How to make it more efficient? Rather than having a bunch of experts from the outside who are supposedly experts on warehouse management. Why not let the people who do the work? As long as they’re accountable for the outcome, let them do the work.

The second thing about that is, so if your goal is to have a self-managing team, the very first step of that should be to let them choose who’s part of the team. I’ve seen, personally seen, a lot of dysfunctions in teams because some manager said that so-and so has to be part of the team. Well, that person doesn’t mesh with the other people on the team. And in a lot of cases, when I was working with organizations and they were trying to adopt Agile practices, we had cases where the product owner didn’t actually want to work in an Agile way. They were former business analysts, and they thought writing a huge requirements document was the best way to work. And now you’re asking them to be a product owner, working on a team that’s going to work in sprints. Every time they would want to know, when is this feature going to get done? And it’s like, well, that’s not what we’re working on in this sprint, keep having fights about that. And the whole problem was the person who was assigned to be the product owner for that team didn’t actually want to be part of an Agile team. So, first thing is you want to actually be part of the team. And also, the people want to work together. Sometimes you just have personality conflicts, and there’s no way to really work through that. So the team really is best, able to make decisions about who should be a member of the team, and then, they can form ways of working.

Well, the problem with self-management is that you’re not either not self-managing or self-managing. It’s a whole spectrum. So as the team is learning how, because people are used to self-managing in their personal lives, but they’re not used to self-managing in the work environment. And so, they don’t maybe have the trust. When the manager says, “Do whatever you want.” Okay. Is this a trick? Are you gonna punish me when it goes wrong? So you have to build the trust on both sides and you have to kind of work through it. So, initially, if you’re going from a traditional organization to a self-managing teams kind of organization, maybe at first the manager lets the team make small decisions in certain areas like, well you can choose your Continuous Integration environment and the way that you do automated tests provided that you achieve the outcomes at the end. And then if that goes well, maybe you expanded a little bit more. Instead of just saying you can choose individual tools, we give you a budget and you can manage to that budget. And then over time, you know, maybe we’re going to give you broad responsibility over what the product is and how it’s done. So you have to grow that, and it takes time. The manager or the leader has to nurture that kind of self-managing responsibility and has to build trust and help the team learn. And the team has to grow as they’re given more opportunity to do things. They have to prove that they can actually perform.

There’s a technique in Management 3.0. They talk about kind of a delegation poker or a delegation game. That’s one way of sort of exploring that level of autonomy that a team might have. And so, something like that might be useful, or sometimes it’s just having a dialogue between the manager and the team saying, “What do you feel comfortable taking on?” And then the team might say, “Well, we think we should do this.” And the manager said, “Well, I’m not quite comfortable with that yet. How about if we try this smaller part of that? And then if that goes well, then you’ve proven that you could move to the next step.” There’s kind of a give and take, and it’s actually both the team learning how to become self-managing. And it’s the manager or the leader, depending on how you want to call it, learning how to help that team grow. Both groups are learning through this whole process.

[00:32:40] Leadership vs Management

Henry Suryawirawan: I like that you mentioned it is a spectrum, right? Because a lot of people think it is either self-managing team or the leader says whatever they want as a manager. So it seems like the role of the leader here is really important. You provide a distinction between leadership and management. So tell us more about this difference between what is a leader and what is a manager?

Kurt Bittner: The reason why I was sort of switching between the two terms is that, generally, somebody usually starts as a manager. They’re used to managing the team. They’re used to giving people direction on what they need to do, checking in on whether they actually did those things. In our view of things, in the “Professional Agile Leadership” book, we talked about, really, the leader acting as a kind of catalyst for change. They’re really helping people to develop their full potential. That’s an aspect of traditional management, but it’s not the primary aspect. The primary aspect of traditional management is making sure things get done. And when I say things, I mean, usually activities and outputs.

So, as the leader shifts to focusing on goals and goals based around outcomes, they have to shift the way that they work with teams to be more of a, “Here’s the goal that we want to achieve. What can I do to help you to develop your capabilities so that you can achieve that goal?” And asking questions, like, “What do you think you need from me or the organization to help you achieve that goal?” They kind of shift from more of a directing to coaching kind of relationship. Although that’s somewhat oversimplified. In terms of their responsibilities, the leader is accountable for achieving outcomes and for achieving goals. But they’re also accountable for helping people to grow their capabilities to achieve those goals.

We use this term catalytic leadership. To sort of borrow the term catalytic from chemistry where you think about what a catalyst does. It lowers the amount of energy required to achieve a particular result in the chemical process. So the catalytic leader reduces frictions. They help to improve the effectiveness of teams and help to resolve problems. That’s a little bit different than maybe some people think about a Scrum Master does that. So a Scrum Master is a kind of leader in the team. But outside of that, the Scrum Master needs help from other kinds of leaders in the organization. You might think of it in a way as removing impediments, but that’s just one example of how you might help a team to develop. So ultimately, the goal of the leader is to create an organization that’s more resilient, that’s more accountable, that’s more focused on customer outcomes that can easily adapt.

[00:35:18] Decision Latency & Dependencies

Kurt Bittner: There’s a measure that I like to look at to determine how self-managing a team is. But if you look at a concept called decision latency. Decision latency is the amount of time it takes from when you need to make a decision to when that decisions actually made. So a team that’s self-managing (has a high degree of self-management), they can just make that decision themselves. They don’t need to go ask someone. They don’t need to go wait, maybe get a bunch of opinions. They’re empowered to make their decisions because they’re empowered to deliver and accountable for delivering customer outcomes. But a team that has low self-management, they’ve got to go ask their manager. Can we do this? Should we do this? What do you think? And that manager might have to ask a bunch of other people, and maybe it’s a whole political process and all that. So the longer it takes to make that decision, because you’ve got to consult with more and more people, the less autonomy that team has and really the less autonomy the organization has.

So that’s a really simple measure. And if you were a leader wanting to get better, one question that you would ask is, okay, so what’s our decision latency for the team? And what could we do to improve that? Are there things that I could give up that the team is ready to take on? It might be small decisions like, can we order up for lunch today? We’re having a meeting. Could we order for lunch? Yeah. Okay. Go. Or not. Because in some organizations, you can’t. You’ve got to go ask the manager. Is it okay to do that? I mean, that’s just a simple thing. So anyway, decision latency is an interesting measure to eventually make it concrete, not just be based on opinions.

Henry Suryawirawan: I really love this decision latency as a matrix. It makes it not abstract anymore, right? It’s like very concrete. Because people know, okay, how long do you actually take to make a decision? Versus, are you self-managing team, or can you self-manage yourself? Sometimes it’s a little bit abstract. So decision latency, I really love that. So I think I encourage all the leaders here or managers. Maybe think about the time when you make a decision. How long actually does it take? So it could actually open up a lot of thought process. Maybe there are certain things that maybe you rely on leaders.

But there are also another things. You also cover, which is this thing called dependencies. Sometimes you really cannot make decisions because you depend on other things, either external parties, partners, whatever that is. So tell us more about this managing dependencies, because if you want to make decision faster, of course, dependency must be controlled better.

Kurt Bittner: Yeah. So, the traditional organization tends to be organized in what we’ve commonly called silos because they sort of resemble farm silos, you know, vertically structured. So the idea behind the silos that you’ve got all developers reporting into one manager and all the testers into another manager and all the business analysts and another manager and everybody in purchasing and another manager and so on. Well, if you’ve got to get anything done, obviously, you’ve got to have skills from all those different areas .

And the problem usually with the silos is that people in the silos are measured according to their efficiency. How much work are they getting done? How extensively utilized are you? Well, Don Reinertsen does a really interesting analysis of queuing. Essentially, if everybody is operating at full utilization, there’s no room to do anything new. Any time you add anything new, you basically have to get at the end of a line because there’s a bunch of other people waiting for that person’s time as well. So, essentially, in the full realization of these specialized departments is that everybody is busy all the time. But you’ve actually maximized the amount of time that people spend waiting for someone else.

So part of what a self-managing team does, a cross-functional self-managing team, is it collects all the expertise that you would need to do to satisfy that customer outcome on that team, so you don’t have to go wait on somebody. Now, some organizations, they organize through kind of a matrix management where the people on self-managing team still technically report into their sort of specialty. I mean, I don’t know that I really care whether they do or not. It’s more like do they have to go ask their boss when there are decisions to be made? So, you know, if there’s no dependency, if we don’t have any wait time involved, who cares? Matrix management can work. But if you have to go back and check, let me go check with my boss to make sure that it’s okay for me to do, then it’s going to completely blow your decision process.

So removing dependencies, moving to more and more of a cross-functional self-managing team by, in the sense, bringing everybody together on the team with the right skills is really key. Now, immediately as people bring up and go, well, that’s going to mean huge teams, right? 50 people on the team or 20 people on the team. And, of course, that won’t work. And we know from various kinds of dynamics that a team starts to get less effective after about 10 or 11 people on the team. Scrum, we sometimes talk about seven plus or minus two. That’s not a hard rule. It’s just the way that humans communicate. The complexity of the communication. Once you get above 10 or 12 people, then you end up with subgroups in the team, little cliques and things like that.

So people come back and say, well, we can’t operate, you know, we can’t have all the expertise we need on the team. Well then, in order to still keep decision latency low, what you have to do is figure out ways to eliminate dependencies in queuing. So if you happen to need an expert from, let’s say, information security on your team to help you design a more secure component for your system, you don’t want to have to go wait for several weeks for that person to become available. You actually want them. “Hey, you know what? We’re going to be working on that tomorrow. Can you join us and help us?” And what the organization has to do is to staff those specialty skills so that no team has to wait, which means that they have to accept that those specialists might be spending some time sitting around waiting for a team to be ready to be helped, as opposed to the team waiting on the specialist. But it’s still much better. You’ve got one person waiting (the specialist) instead of 9 or 10 people waiting virtually all the time. So you still basically get more things done, even if you’re just measuring in terms of work, not outcomes. But it’s hard for organizations to do that. The specialists, when they have free time, they can be figuring out creative ways to solve problems. So maybe what they need to do is that information security specialist needs to write a set of automated tests that every team can build into their Continuous Delivery pipeline so that it automatically tests for security threats every time you do a build, which means every time you deliver code.

But you have to invert your way of thinking about dependencies. Invert it from being dependent upon the specialist. The specialist is there to serve the team whenever the team needs it. And that’s true, whether it’s HR or legal or InfoSec or a leader. But if you start working towards reducing those dependencies, then over time it will help the team to become more self-managing. The whole goal is to run those feedback loops faster. So anyway, ultimately, figure out ways to reduce dependencies. Wait time is a big indicator of a dependency, and so then if you’re a leader, you need to figure out, okay, what do we need to do to reduce this wait time? Reduce queueing.

Henry Suryawirawan: So, as you mentioned all this, I think a lot of insights here. How do you manage dependencies? You have to also think about the wait times between all these bottlenecks. I call it simply bottlenecks, right? Because there are certain teams that are overloaded because it’s like serving so many other teams. Maybe these small functions like HR, or maybe project manager, whatever that is. So these small teams tend to be like a bottleneck, because everything goes through that team rather than that team being rotated across other teams, and there’s no wait time in between. Maybe removing dependencies is one way of improving self-management. Are there any other things that we can do to actually improve our self-management?

Kurt Bittner: Well, every daily scrum is an opportunity for self-reflection about how to improve things. But from a bigger picture, every sprint review gives you an opportunity to really reflect upon the value that you’re producing. Every sprint retrospective gives you an opportunity to reflect upon the ways that you’re working. One of the nice things I think about Scrum is that it sort of builds in that pattern. Every couple of weeks, you have an opportunity to step back and say, “Hey, this last sprint was pretty rough in some areas. Maybe it was rough because of some dependency or it was rough because the team lacked a particular skill. You know, that opportunity to step back and do some reflection on what you could improve, and then feed that back into the next planning process to say, okay, so, maybe we need to build some time in next sprint for us to learn how to do that thing better.

The other thing is that teams can get complacent. There’s always a tension between it takes a high-performing team a long time to form. And you lose one person or add a person, that can sometimes upset the whole thing. But the same thing happens is that if the team has been together for too long, they can get into kind of a group think about things, and they don’t challenge each other. Maybe there’s an existing sort of almost internal team dynamic that says you don’t ask about things like that. A Scrum Master can help that a little bit. Maybe changing team members occasionally is also a good thing. But you have to keep in mind that might reduce your overall team effectiveness for a couple of months until you really learn how to work together.

But the point of it is that the team collectively needs to decide what skills it needs and how its team members need to grow. That gives team members an opportunity to challenge themselves, to have personal growth and whatever. But that might not fit into some standard job description, and that should be okay. Because that’s what the team needs and that’s what the organization needs, and you might learn something from it. You might learn we need a completely different kind of skill set than we’ve had before. So I think letting go of standard job titles and standard job progressions is an important step. But it raises the question of what is a career? Because if you’ve been thinking, I’m going to go from junior developer to developer to senior developer to distinguished engineer to whatever. I mean, I’ve seen those kind of progressions in organizations. I think my view is that they keep you locked in the past. Really, there’s a whole range of things. I mean, I’ve seen people come straight out of university and they come up with a way to solve a really complicated problem. Because they’re smart or maybe they were exposed to that in university or maybe in an internship or something. Maybe they’re able to perform on that particular thing at a higher level than maybe somebody who’s been there several years. So, this notion of kind of lock step job progression as an individual, I don’t think really fits the modern world or at least the Agile world.

But what does make sense is being a member of a high-performing team. And over time, what an individual develops is the ability to help other people on their team and the ability to, in a sense, exhibit leadership skills within that team. Even though they might not have “leader” anywhere in their job title. That’s what really makes them valuable to the organization is that they can help to build new teams. You could take that person and put them onto a team of maybe a bunch of new hires. And that person can really help that team form and grow and really perform very quickly. They’re kind of like a seed for a new team. That’s really, I think, what we should be recognizing in people is that their ability to act as leaders and coaches and mentors. Whether they’re a developer or whether they’re a leader that we used to call a manager. And I think that’s what organizations need to reward because being able to grow a team that’s high performing, that’s like the mitochondria for the cell. That’s the energy source of the organization are all those teams because they’re the ones who produce value.

So I think that’s sort of the big challenge for organization in the people development areas. It’s that they need to recognize that the old job title, job progression career path doesn’t make sense. It probably never made sense. But, we all accepted that it was sort of true and whatever. But it’s much more rewarding. I’ve seen people really shine in their ability to help other people develop and they enjoy it. But anyway, that’s kinda what I think.

Henry Suryawirawan: Wow. So many things to unpack here. So from things like leadership. You mentioned that leadership is not necessarily just a role. Everyone can be a leader. So either you’re a developer, if you’re the manager, if you’re whatever, young person joining the team, it doesn’t matter. You can exhibit this leadership. Be the mitochondria of the cell, like you mentioned. I really love that analogy. You also unpacked things about career progression, and things like that. Maybe that’s the old way. People love to make standards out of things. Sometimes that doesn’t fit in the real practice because people are different and unique, and people grow as well. So maybe one day you are like this, but maybe next year you become different. Thanks for sharing all these.

[00:47:50] 3 Tech Lead Wisdom

Henry Suryawirawan: So Kurt, it’s been a pleasure talking about this. I really learned a lot, so many things that you uncovered. But unfortunately we have to wrap up due to time. But I have one last question that I normally ask all my guests, which is for you to share your version of three technical leadership wisdom. So think of it like an advice for people to learn from your journey or experience. So what will be your three technical leadership wisdom, Kurt?

Kurt Bittner: Oh gosh. So I think the first thing we talked about was empiricism. It’s that shifting from a view on activities and outputs to focusing on outcomes. So that’s probably the first thing.

The second thing is that we actually don’t know what’s valuable. And so we have to use empiricism to figure out what’s valuable.

As we’re doing that, we have to constantly help people to grow as a team to reach a higher levels of performance as a team. Not just focusing on individuals, but focusing on the broader team, because there’s virtually nothing that we do in the business context or in the world in general, that we can do as individuals. Almost everything that we have to do, we do as a member of some kind of team. And so, really focus on helping that team to grow, remove waste and impediments, remove things that stand in their way. So those are kind of the three things. Focus on value, use empiricism, and grow teams.

Henry Suryawirawan: It’s like a summary of our conversation. Thanks for sharing that. I really love that when you mentioned like, most of the times, we actually don’t know what the value is. So that’s why we need to use empiricism.

So it’s been a pleasure, Kurt, to have this conversation. For people who would like to continue this, or maybe find you online, maybe get the book, is there a place for them to reach out to you?

Kurt Bittner: Uh, Yes. Usually on LinkedIn you can find me there. Happy to take any requests. Usually when I write something, I try to remember to post it. So you’ll see anything new coming that way.

Henry Suryawirawan: So I must say that many of your articles are actually very insightful as well. I read a couple of your blogs in preparation of this conversation. So I think for people, do check out Kurt’s blog. I think they’re really well written, and lately you also post some new blogs as well with other people. I really enjoyed reading that. So thanks, Kurt, for your time. Thank you so much for this conversation.

Kurt Bittner: Okay. Thank you, Henry. It’s been great.

– End –