Protecting Uncertainty
Published 4/20/2020
At some point our knowledge runs out, but even more perplexing is the ability to look forward in time. In today's episode, we're talking about uncertainty that teams experience and how that uncertainty within a team can be a healthy marker to successful workers.
🧡 Leave a Review
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
🍵 Subscribe to the Tea Break Challenge
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Transcript (Generated by OpenAI Whisper)
We've been talking a lot recently on this show about what we don't know. In today's episode, we're going to talk about that fundamental uncertainty as a marker for healthy teams. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help gym developers like you find clarity, perspective, and purpose in their careers. Today's episode is a short episode. We're going to be doing a little bit more of these short episodes as we move into the future. Some of these episodes are favorites among the community of people who listen to this show. Hopefully you will enjoy today's quick discussion on uncertainty. The truth, as we've said in recent episodes, is that you have such a small amount of information at any given point in time. In fact, all of humanity's availability of information is so vastly limited that we don't even necessarily know our own history. We know parts and pieces, but at some point our knowledge runs out. Even our recorded knowledge runs out. But even more perplexing is our ability to look forward in time. For even the concept that we might be able to look forward in time, this is perplexing because so often much of our attention and energy is put into this particular effort, predicting what will happen next. So much of our brain's activities are built to prepare us for what is about to happen rather than recovering or reflecting on what already has happened. In fact, you could probably argue with a neurologist or even a sociologist that the purpose of reflection and recovery is still an anticipation of whatever is coming next. And so it shouldn't surprise us that many of our attempts as companies, as teams are to try to predict that future. Or if we can't predict it, we try to control variables around that future. We offload the responsibility of predicting a future that we know very little about to other people who might know more about it. For example, we ask Developer To estimate how long a certain amount of work will take if we are not subject matters in that particular area. And there's nothing particularly wrong with us on its own. But we have some incompatibilities that we need to deal with as teams that often break product teams and cause them to fail in drastic ways. Specifically, we have to come to the realization and acceptance of the fundamental uncertainty that surrounds us. And what this looks like in practice is that in our attempts to predict the future, to make estimates, for example, or create roadmaps on our product plan, whatever thing you're trying to do to cast into the future, we have to recognize and consistently, here's the key for this episode, consistently protect our understanding of uncertainty. So many of our efforts are, once again, focused on converting that uncertain future into something that is certain, sometimes this happens unconsciously. We ask a developer for an estimate, and then henceforth, we treat that estimate as a commitment. In these scenarios, one of two things must be true. Either one, we believe that the developers have some unique ability to forecast into the future that we don't have, or two, we're asking a developer to consume the uncertainty and the negative effects of that uncertainty for themselves. Now why is this bad? Because we should be able to share the burden of uncertainty as a team, right? So asking a developer to consume the negative burden of uncertainty seems reasonable for a certain amount of the work that they're going to do. But here's where the problem arises. If we ask people to consume their own bits of uncertainty, then we're kind of accidentally incentivizing people to create more certain estimates. In other words, to inflate their estimates so that the uncertainty is reduced for them. So what can we do instead? As leaders, it is our responsibility to systematically protect uncertainty. Instead of viewing uncertainty as the enemy, view it as an ally. Uncertainty allows us to stay in a state that is unresolved, that creates a positive creative tension for the developers or for our team, for the people that we're working with to navigate through. Instead of shooting for making our commitments, instead, are focused on solving the problems. And that's my homework for you today, a simple thought experiment. Consider in the regular ceremonies and processes that your team has adopted, how can you respect and protect uncertainty? Thank you so much listening to today's episode of Developer Tea. In lieu of a sponsor, I would like to ask you to go and leave a review for Developer Teaon iTunes. In the first couple of years that we launched this show, we had a ton of reviews, incredibly helpful, not just because it helps push the show up and help other developers find the show, but also it provides some critical guidance to me to continue making this show better. Thank you so much for listening to today's episode. This episode was produced by Sarah Jackson. My name is Donna ThinCutrell. Until next time, enjoy your tea.