Learning to Handle Uncertainty

Episode 21

Does project work feel like a guessing game? What happens when projects go off track, and how can this affect customer relationships? Better yet, how can we navigate uncertainty when we estimate and plan — but things still go wrong? Standing in uncertainty, learning to handle it, and living in inquiry are topics of discussion in this episode.

 

 

Show Notes

• We’re going to talk about the idea of being able to hold uncertainty in our mind, start to get comfortable with it, and some mental tools and patterns of how to handle
• When we find ourselves uncertain, we oftentimes crave certainty.
• Be comfortable holding your plans with an element of uncertainty.
• It’s really easy for you as a manager to observe generally how people are working.
• Product management and prioritization are all about cutting away, they’re all about subtracting
• I’m going to propose that you get into a habit and create a practice of reestimating and replanning.
• I want to focus on this very simple three part steps to something that Human Systems Dynamics calls an adaptive action.
• Standing in uncertainty, learning to handle uncertainty, living in inquiry

Links:

• Sponsor: GitPrime

Transcript

Speaker 1: Welcome to the Programming Leadership Podcast, where we help great coders become skilled leaders and build happy, high-performing software teams.

 

Marcus: Whenever you start a new project, you enter a confusing new situation. Now there’s a lot that’s known. Your team’s probably known, your boss is probably known, maybe even the people or the framework you’re using is known, but there’s always an element of unknown at the beginning of every new project. You don’t know exactly how the code needs to be changed. You don’t know exactly what the ramification will be on the users. You don’t know precisely how it supposed to look and act and feel. In fact, with all of these unknowns, it might be easy to even say there’s a lot more that we don’t know than what we do know, and that’s what we’re going to talk about today. We’re going to talk about the idea of being able to hold uncertainty in our mind, start to get comfortable with it, and some mental tools and patterns of how to handle uncertainty.

 

There’s a particular reason why I think this is important for you as a technical leader. When I find myself in an uncertain situation, if I have any status, or authority, or title at all, and someone asks me what I think, I find myself at a key position to have to think, am I going to admit that I don’t know, or am I going to pretend that I do know? When I pretend that I do know, I am really pretending to be certain about something. Now, I know this might sound very abstract, handling uncertainty, dealing with abstraction and uncertainty, but the reality is is that I’ll bet you face this same temptation. Your boss says, “How long will that take?” You don’t know. And by the way, if you think you know, I’m going to assert that you’re wrong because you don’t actually know. You can make a guess. You could say between one year and a million years, and from that perspective you would be right, but that probably is not going to make your boss very happy.

 

So, how do we handle uncertainty? I think it starts within us. When we find ourselves uncertain, we oftentimes crave certainty. We want to feel safe. We want to feel like we know something, and so we begin to take stock of what we do know, we, “Okay, well I know it’s this framework and this team,” and other things we do know. “I do know that the last project took this long and the one before that, or our velocity is typically been a 71 and this feels like it’s that big a project,” so we go to what we know.

 

But while what we know are important data points in any complex adaptive system, our past performance might be completely shot out the window. Right? I’m sure you’ve found this because your plans don’t go exactly to plan. They don’t execute exactly like you thought. I mean, my guess is your team is not hitting every sprint perfectly. Their plans, their estimates are not coming out exactly right.

 

So what can we do? Should we stop planning? No. I’d like to propose the planning is very, very important. But I also want to propose something that might sound completely illogical, and that is planning is important, but that plan should be able to be thrown out the window at a moment’s notice. Or maybe even better, not thrown out the window, but instead of writing your plans in pen, write them in pencil. Maybe that’s kind of the key lesson I want to get across today, is being comfortable holding your plans with an element of uncertainty. Saying, “This is my best guest today,” and just using those words. “This is my best guess today, and we can start down that direction, but I will update it.”

 

Now you might say to yourself, that sounds great, Marcus, where you work, but where I work, we set a plan in motion and if we deviate from the plan, people get in trouble. First, I’m sorry you work at a place like that, but, second with the idea that what you do actually impacts other people in the system, I want to suggest that you try this. I realized that it might sound like I’m thinking as I talk, and that is exactly what’s happening. I’m thinking while I’m talking. I have this thing that I used to do and that was I would reestimate the whole project every sprint.

 

Let’s just break that down. Instead of estimating everything upfront and then saying, “All right, well we’ve got 3,500 points here and we’re going to do this much per week, so it should take that many weeks,” we would actually re-estimate the whole project every single sprint during sprint planning. And by we, I mean the team. You might say, “That’s crazy, Marcus. Think about how long that would take!”

 

Well, two thoughts. One, it did take time, but it always revealed a surprise, and I was always so glad to that even on the second week my estimates were wrong. I didn’t have to wait until the 10th week or the 10th sprint or something to go, “Oh gee whiz, we’re halfway through and now I realize that nothing’s working right,” or that we’re not going to make our dates. Because at that point, you’re just going to say, “Well, maybe we can get people to work harder, or add people to the team, or work weekends,” and none of those strategies are going to get you what you need. If you knew the second week or the second sprint that your plan, that your estimates were not accurate, you would not only know something really important, but you would be able to do something about it.

 

I want to take just a moment and thank my sponsor, GitPrime. GitPrime is sponsor the show, not just because they’re fantastic people, but because they really believe that leadership and engineering is about people, it’s about conversations, and GitPrime is a platform that allows you to have better conversations with people. Yes, it has lots of other benefits. You can probably plan better. You can see metrics about individual performance. But let’s just take that one idea about individual performance. Whenever I talk with a GitPrime user, and by the way lots of my clients are GitPrime users, they always tell me how surprised they were at what was really happening on the team.

 

See, it’s really easy for you as a manager to observe generally how people are working. You can look at PRs, you can look at who’s assigned what tickets. You as the CLM, the software engineering manager, you get a notion for what people are doing, but there’s always these beautiful surprises about who is really performing well and who’s secretly struggling. About who’s the person that’s saving everybody’s bacon through fixing a lot of stuff behind the scenes, and who is absolutely doing all the PRs. This kind of data lets you move from looking at people as just, well, they’re all engineers and they’re all kind of doing engineering work, to seeing exactly where each one of them is strong and has opportunities to grow. That’s why I love this tool so much. I believe that new and surprising conversations come out of data, that when you can sit down with somebody and start to understand and intuit why things are happening, you’re going to create even better quality of exchanges.

 

And by the way, you know here on this show we talk about the fact that leadership is what keeps people connected to their work, and prevents turnover, and keeps them motivated. It’s about the relationship. I like to say they GitPrime not only lets you build better software, it lets you build a better relationship with your team members. Start a free trial today gitprime.com.

 

So if in the second iteration, you say, “We’re going to re-estimate our work, all of it, everything we know we’re going to reexamine from top to bottom. We see our old estimate, we’re going to update it with the new one. Some things we don’t have any more information on, so the estimate may remain the same. But doggone it, an iteration in, we sure know a heck of a lot more, and there’s more assumptions, and there’s more particulars, and there’s more specifics. That API that we thought we could depend on, that thing doesn’t work hardly at all. That other team we thought we were going to interface in, turns out they just got a big project, so they can’t really give us the amount of time we thought.”

 

So now, now we can start to really take into account reality with our plans and we reestimate. But, and this is so incredibly vital, we don’t just keep that estimate to ourselves. We must share it with the stakeholders. If you could imagine this, you might say, “Well my stakeholders will just get really mad if every iteration I send them an updated estimate.” They might, but I doubt it. I think actually what they’re going to say is, “Wow, you are really committed to getting this right. You’re really committed to communication. You’re really committed to making sure that even if everything can’t be done by the deadline, that we see that the scope and the project size is bloating, is increasing, maybe not even the scope, maybe the complexity. That the estimates you originally thought weren’t right, and so therefore you want to make sure that the most important work gets done.”

 

When you re-estimate those things and you start to see that, “Oh, my gosh, by second iteration I get already tell we weren’t going to hit our original goal.” Now the idea of prioritization becomes so much more important, because instead of imagining, “Oh, you can have everything in six months,” which was probably the original thought. How long does it take to have everything? It takes six months. Well, now you say it, “How long does it take to have everything?” It takes seven months. Whoa. That six month commitment, that was really important. Okay, so now the question is what can be delivered in six months? What’s the most important things to deliver?

 

Product management and prioritization are all about cutting away, they’re all about subtracting, and that means they’re all about having real conversations to say, “Okay, we’ve already seen that we’ve slipped in the first iteration, which was only a week, now we’ve slipped by a month. So let’s measure again the second iteration, and let’s see how much farther we’ve slipped. Golly, now we’re two months off. At this rate, we’re going to need a drastic reduction in scope.” But how much better to know that you either need a drastic reduction in scope or some other miracle. By the way, we’ll get to miracles here in just a second. How much better to know those things on week one and week two then halfway or 75% through?

 

Because that’s when most of us let our optimism get the best of us. We wait and we have the sneaking suspicion things are not going to work, but we don’t like to stand in uncertainty. We are not good at handling uncertainty, and so we moved to pretending. We pretend we have the answers, we pretend we’re confident, and sometimes we engage in a fairy tale. Once upon a time in a land far, far away, adding more resources to a project, made it come in on time, or decreased the amount of time. That project took that my friends is a fairy tale. It just doesn’t happen. Right?

 

You can look all over the internet. We see and your own experience is going to prove that adding more people to a late project only makes it later. So when your boss or you are attempted to say, “Well, if only we could add two more front end people, I think we could take the pressure off of Nate. Then you know what, we’d really have this on time.” I want you to stop and realize how much am I increasing the communication overhead, the coordination overhead, the complication, the partitioning of the work across two brains or three brains.

 

All of that means not only do these people have to communicate, but you’re going to find people stepping on toes, they’re not passing work effectively back and forth, one is doing the work that another should be doing. I mean, there’s all kinds of stuff, and that’s all fine, but it’s when you imagine that it just magically works that we’re entering fairytale realm.

 

What do we do instead? Okay, here’s what I’m going to propose. I’m going to propose that you get into a habit and create a practice of reestimating and replanning. That is where you look at where we’re at now. You say, “What does this mean and imply for our estimates?” And now what estimation? How do our estimates, how does our staffing, because sometimes staffing changes, how does the project scope change? This is in a nutshell, something called an adaptive action loop.

 

Now, it’s also called an OODA loop. It’s actually called a whole bunch of things. You might think about it as an ORID debrief, an ORID loop. But I want to focus on this very simple three part steps to something that Human Systems Dynamics calls an adaptive action. That’s first we ask what. What are the facts? What is happening? What is the situation, what are the truths, what are the beliefs, what is going on, and what do we know? Then the second thing is to say, so what does that mean? What does it imply? What might it mean? What does it mean for you and for me, what does it mean for the stakeholders? Now, part of this is we’re not just looking for objective truth. By the way, I totally am an objective data kind of person, but in this case there are at least three kinds of truth that we need to keep in our mind.

 

The first is objective truth and that is numbers, data, things we can see and touch and all agree on. But in software, there’s not a lot of that, so oftentimes we moved to normative truth. What is it that the group, that the group we, that the company we, that culture we, agree on. What is the truth we see when we look at the project, and the backlog, or the fact that, “Oh, that API that the client said they were going to give us, turns out they’re just in the middle of creating that.” Maybe we collectively agree that that that’s a truth, that it is a true risk, and we’re all going to agree on that.

 

Then there’s the idea of subjective or very personal truth. What one person sees as a data point for them and the way they feel about it is true. They’re going to feel like it’s terrible that the API isn’t ready, and someone else might just say, “Oh, that’s not a big deal. We weren’t ready either.” For them, it has a whole different feeling to it. As we gather our whats, let’s make sure to ask, what kind of facts are we looking at here? Are they normative facts? Are they objective facts? Are they subjective facts that are very personal?

 

Once we’ve gathered some information about kind of where are we is if we’re using a geographical metaphor. Where are we? And now we moved from what, what is our point on the map, to so what. What does it mean? What does it mean that the API wasn’t ready? What does it mean that we’re already behind before we started, to coin a phrase I’ve heard. “We haven’t even started and we’re already behind.”

 

What does it mean that other departments we depend on de-prioritize our work, that they have more important work, or that they are getting new people that don’t know the system and that’s the resource we have to use. What does that mean to us? Not in a good or a bad way. There’s no naughty or nice, but just what does it mean from all the facts and from the meaning. Then we can compile, together and individually, a next wise action. Just a small one. Now what? So we have what, so what, and now what? Now what should we do? In the adaptive action cycles, the idea is you take a step in the now what. You look at your possibilities and you say, “Let’s try and make a change.”

 

Then you move right back to what you say. How did that change affect the system? I’m going to guess that between you and me, your act of re-estimating on a regular basis may change your customer’s perception of what an estimate is, how sure it is, how they even get their estimates. They might be looking at this thing called an estimate as a promise, but if you set the ground rules immediately to say, “These are going to change every iteration,” well, they’re not really promises are they? They’re the view from here. I want you to think about me doing air quotes. The view from here is that it’s going to take another three months. The view from here is that we’re not going to make it and we don’t want to be magical fairy tale unicorn princess mindset about it. We don’t want to pretend things.

 

We need to live in the reality, and so as you take these adaptive actions and you ask yourself what is happening? What am I seeing? Now what does that mean? I’m sorry, so what does that mean, and then now what action should we take, even this very small action so that we can then move back into the whet phase of observing. As you do that and you start to get better, hopefully you’ll notice that you can navigate one step at a time with fewer missteps and easier recovery, because you haven’t tried to overreach too far. You’ve just taken a step. You’re doing little bits at a time.

 

All right, standing in uncertainty, learning to handle uncertainty, living in inquiry. It all is much harder than I’m making it sound. It is really a process of, I don’t want to say building confidence, but I do think we can build skill around these ideas of what mental tools do we have for handling uncertainty, and I think that adaptive action, and these working in small chunks, and maybe simply re-estimating which changes the way those estimates are perceived, those are some ways that you can handle uncertainty differently than ways you’ve possibly been handling them in the past.

 

All right. I hope this was useful for you. Drop me a line marcus@marcusblankenship.com and we’ll see you next week.

 

Speaker 1: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast www.programmingleadership.com, and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time