« All Episodes

Portraying Confidence in the Face of the Unknown

Published 7/24/2024

In today's episode we discuss how you might build your confidence without being disingenuous. This isn't a lesson in psychology or tricks - it's about building true confidence in what you do (and importantly, don't) know.

🙏 Today's Episode is Brought To you by: Unblocked

Your developers know how to write code. What they’re missing is the context to know what code to write. Unblocked gives engineering teams the answers they need to get their jobs done – without having to wait on or interrupt their teammates. Get started for free at getunblocked.com.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

🧡 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.

Transcript (Generated by OpenAI Whisper)

One of the biggest misrepresentations that you'll face in your career is about confidence. One of the things we talk about a lot on this show, we keep on coming back to the theme of producing some kind of reliable estimate for your work. And the reason for this is because it is kind of the perfect encapsulation of the typical problems that a software engineer has to face in their role. Because if you think about the fundamental nature of the question, when is this going to be done? It requires for the engineer or for the manager, for whoever is being asked this question, to gather some kind of information. And make an assertion about uncertainty. This is why it's such a good kind of testing ground, a proving ground for so many of the principles that we care about on this show. Because if you could tell the future, then this podcast would not need to exist. The entire goal of our working lives is to try to imagine the future. Try to predict. Try to get ahead of the future. Try to wrangle uncertainty. And so this is such a good basis to talk about some of the principles. But in today's episode, I want to focus in on this specific idea of confidence. In our kind of cultural situation, we substitute confidence for knowing. The person who knows the most is de facto the most confident. And this is a poor substitution. Because our jobs are about wrangling the unknown. And so if you were to have two different people and compare their levels of confidence, they would theoretically have a linear relationship with knowledge of the future. Available to those two people. But in practice, what we see with confidence is that people tend to project that they know something. They tend to sell that they know something. And this is actually what we are defining our perception of confidence by. But here's what I want you to pay attention to. There is no one person who knows more about the actual future. Than any other person. At least not in any direct sense. We learn about the future by paying attention to the past. We may try to shape the future by gaining, for example, commitments from other people. And setting intentions. Setting intentions with other people. Setting intentions for ourselves. Imagining the future and simulating it through whatever means we have available. But it is still. A level playing field. Assuming all of that information, all of that influence is available to two people. Neither necessarily has a leg up on telling the future. So how can we as engineers or as managers in any kind of growing leadership position in our careers. Project confidence when everyone has the same information. That's what we're going to talk about right after we talk about today's sponsor. How long should it take to write seven lines of code? A couple of minutes? An hour? What if it takes five days? You might be tempted to think that developers on your team need help writing the code. But that's almost never the case. The biggest drag in software development isn't writing code. It's having enough context to know what code to write in the first place. In a perfect world, your engineering team wouldn't waste time. Days or sometimes weeks searching for the context to understand your application. But on average, most developers work more than two hours a week trying to find information about how a code base works. And that's why there's Unblocked. To give your engineering team the answers they need to get their jobs done at the speed they, and you, both want. Your code base is a compilation of thousands of past decisions and discussions that live across tools like GitHub, Slack, Jira, Confluence, and more. There's so much value in this history, and Unblocked surfaces that history next to your code. So everyone on your team has the context they need. And when someone has a question, Unblocked answers with the accuracy of your most experienced engineers. Get started today at getunblocked.com. That's G-E-T unblocked.com. Thanks again to Unblocked for sponsoring today's episode of Developer Team. How can you portray confidence when the same amount of information is available to everyone about the future? Now, I know there's somebody who is about to close the podcasting app that you're using right now because... You're afraid that we're going to start dipping into body language discussions or some other kind of psychological concept. And that is not the goal of this episode. Instead, I want to help you focus on the right things. Because focusing on portraying as if you know something you don't know will fall apart. And it'll either fall apart now when you're trying to portray this information. Or later whenever... You're wrong and everybody knows it. And that's not to say that you can't guess correctly. But it is to say that that's not the goal of portraying confidently. The important factor for portraying confidence is not necessarily that you explain how things will happen in the future. Instead, it's about the clarity of what you do know. As well as... As well as your ability to deal with what you don't know. There's a subtle difference here. And the difference is simple. Let's imagine we have two approaches. The first approach is to try to convince everyone to trust you that you know what's going to happen. Even though you don't necessarily know. And the second approach is to portray confidently despite the fact that you don't know what's going to happen. We're going to talk about how you actually accomplish that. In the first case, you may try to make statements that you don't necessarily have full confidence in. But you're going to act as if you do have confidence in them. This is ultimately not true. Some people are not necessarily intentionally lying when they do this, just for clarity. I don't want to cause a bunch of undue strife with you and your teammates if they have a habit of doing this. Some people are thinking wishfully. Or perhaps they imagine that they know more than they actually do. They're optimistic about the future. And that optimism is what they use as proof for projecting what the future will be. But if you are on the other side, if you want to portray confidently and honestly at the same time, reckoning with the reality of the unknown, the important thing to do is to be able to explain the unknown, clearly. This is the thing that the first example, the first person, person A, did not do. They didn't investigate the unknown and explain it and put clear boundaries around it. There are a couple of simple techniques that you might use to do this, although we're not going to be able to talk about every technique, of course, but some very well-established techniques for this. One is to express things. With a confidence interval. What does this mean? In most cases, this means having some kind of percentage confidence. In other words, you could say, we believe that we're going to accomplish this work, this body of work that we've been talking about, whatever it is, in the next, say, four months. And we have about 80% confidence that we could do it in the next four months. Now, this allows you to have a more nuanced, discussion about what is keeping you from having a higher confidence level. Maybe 90%. It's allowing you to have a more nuanced discussion around the fact that you'll never get to 100% confidence until the thing is actually done. And this is simply because of the nature of the unknown. There are any number of factors that may keep you from actually accomplishing this work within a given period of time. Now, this technique extends beyond just estimates. What you're doing is you're explaining your uncertainty with some kind of magnitude measure. You're giving a confidence interval because humans naturally parse confidence in a more binary fashion. In other words, you could say, we believe we're going to get this done in about four months. And someone may take that to mean, we know that we're going to accomplish this in four months. And therefore, we're going to get this done in about four months. And therefore, anything more than four months is a problem. We've fallen outside of it. But again, we can apply this in multiple other scenarios. The underlying technique here is that you are explaining with clarity and honesty what you don't know about something. And therefore, you are drawing conclusions that provide you with something you do know. In other words, you're converting, you're adding this unknown quantity. You're using that as a starting point for learning something. Instead of ignoring it or imagining that it doesn't exist or not dealing with it in some way, you're using this as a basis for another part of the discussion. In other words, you're sizing this uncertainty by about 20%. This gives you some measure of what are we going to do about this or how big of a problem. Is this. This kind of confrontation that you're producing, you're confronting the unknown. This provides the people who are listening to you a much higher sense of confidence in what you are saying. They are perceiving you as more confident as a result. Now, interestingly, this still happens even if your confidence intervals that you're assigning are lower. So if you said, for example, my confidence for this is, is less than 80%, maybe 50 or 60%. Then what you're saying is, I've done the work to try to gain confidence in this, but unfortunately there's too many unknowns. I can't get past those unknowns to increase my confidence level or there's work yet to be done to get past those unknowns. Another good technique for this is to identify when you are not the best person to answer a question and to ask who might be. This is ultimately the point of having a team of people, specifically a team of multifaceted, talented individuals who each may have areas of expertise or specialty that not everyone necessarily shares. What this means is that if you can identify your own areas of expertise and also you're able to understand what areas are not in your expertise, counterintuitively, this is another way to improve other people's confidence in you and you're projecting better confidence in yourself. Why is that? What is the mechanism there? It's most likely because when we know ourselves well enough to identify areas that we should not be participating, then what that means is when we are on the flip side of that, when we are identifying areas where we should be participating, people are more likely to trust our judgment about what we're doing. Because everyone kind of intuitively understands that not any one person can do everything. And so if someone is portraying that they are capable of doing everything, then we're less likely to trust them on any given thing. If instead the person is portraying that they have a smaller set of skills, then we're more likely to trust them about that smaller set of skills. This just so happens to work out well for people who do this because they're more likely to trust them than they are to trust themselves. They actually are able to work using the skills that they are competent and capable in. And they're not having to operate in things that they're more kind of middle-of-the-road capability in. This is ultimately the effect of proper delegation. If you're delegating everything, then people will pick up on the fact that you're not actually contributing in any particular way yourself. If you're delegating some things, and you're being explicit about why, then folks are more likely to trust that your why is dependable. Not only does this increase the perception and the reality of confidence, you are more confident in the work that you're doing because you're selecting work that you are actually capable of doing, but it also means that you have more time to do those tasks that you are more capable of doing in the first place. The theme here is, is centralizing around the idea of knowing reality or investing in figuring out reality. The reality of the unknown, you're investing in figuring out and kind of putting boundaries around that so that you can point to it and you can clearly say, we can't have confidence about this because it is unknown. If you're able to invest in knowing the risks, knowing your own shortcomings, knowing your own capabilities, being able to, to communicate about those, this is going to go a long way for both how you actually spend your time and confronting reality yourself and how others perceive you confronting reality. Ultimately, confidence is about understanding what you know very clearly and taking advantage of what you know very clearly. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Unblocked. Your developers already know how to write code. That's why you hired them. What they're actually missing is the context to know what code to write in the first place. Unblocked gives engineering teams the answers they need to get their jobs done without having to wait on or interrupt their teammates. Get started for free at getunblocked.com. That's G-E-T, unblocked.com. If you enjoyed this episode, please share it with someone else that you think might enjoy it as well. You can share directly through your podcasting app of choice, most likely. This episode and every other episode of Developer Tea can also be found at developertea.com. And you can come and talk to me and other listeners of this show on the Developer Tea Discord. Head over to developertea.com slash discord to join for free. Thanks so much for listening. And until next time, enjoy your tea.