Virtually everything we do on our teams is an exercise in building and maintaining trust. And not only maintaining that trust, but managing it. Finding places where trust is no longer necessary, where we can offload trust to a process or to a tool. In today's episode, I want to talk about this lens for thinking about your team processes. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Trust is a fundamental currency in the work that we do. And it goes down to every single keystroke. We have some belief, which is a rough mapping to trust. That belief that trust might be at that very simple mechanical level. You're going to trust that your tools are going to react to your input in a particular way. This is the most atomic kind of trust that we can imagine, a fairly stable trust. And it's one of the reasons why when your keyboard stops working, you feel like your computer has kind of violated that trust. But it gets much more intense when we start involving other people processes, even trusting ourselves. We might even create systems of accountability for ourselves so we can improve in areas where we have a lack of trust. At a very fundamental level, all of our jobs, assuming you're on a team, assuming your team as a part of a company, your jobs are formed on the basis of trust. Yes, we can have contracts that reinforce that trust. We can have norms and practices that we rely on and it's shaped around to that trust. But for most people, you join a company with the trust that the company will do what they said they would do. You join a team with the trust that you all have similar goals. Trust runs so deeply in our daily lives that we often substitute when we talk about things that we trust as fact. As a simple example, and we may have talked about this on the show before, how do you know for yourself that the earth is not flat? There are ways to verify this. You can do a few simple experiments that will show you that the earth isn't flat. I'm going to leave it as an exercise to you to find out what those experiments are. But most people have not done that. So how would you know that the earth isn't flat? Well, the truth is that most people are trusting the vast majority of the people around them. Whether that person is someone who has authority, like a figure from the scientific community, or maybe it's something that we heard very young from someone that we trust like our own parents or a caretaker, maybe a teacher. Some of our most fundamental facts that we take for granted every day are mostly validated through a system of trust. I want to be very clear here that my goal on this show is not to get you to stop trusting your sources. It's not to get you to go out and run experiments to validate every single thing that you've ever heard. Instead, my goal is to talk about this human behavior, the very uniquely human behavior of relying so heavily and sometimes even unconsciously relying on systems of trust. We're going to talk about two aspects of this system of trust, this network of trust that we build. The first aspect I want to talk about is the fact that so many of the things that we do, we already mentioned this earlier in the episode, is under the cover, kind of covertly about trust management. For example, maintaining a regular one-on-one schedule, most of the things that you talk about in that one-on-one could possibly be handled without a meeting or might be handled in a group setting with multiple people present. On the Facebook, a little more efficient to do it that way. Most one-on-ones are largely an effort of trust building. Often when we do things like sprint planning or if we have some kind of estimation process, some things like pull request, review and pairing, all of these have latent effects on our trust in each other. But here's an aspect I want you to focus on for today's episode. And that is when trust is the underlying problem, masquerading as a different problem. Let's say that you are a manager and one of your reports comes to tell you that they believe that someone else who is not on the team, that their input is flowing the team down. And you have a chance to talk with this other person. That person has some external concern that isn't necessarily the team's concern. It's very possible that the true problem here is that there's a trust breakdown between that external party and the people on your team. Specifically, the people on your team may implicitly believe, there's a critical part, there may be a hidden accidental belief, an implicit belief that this external party is trying to take advantage of the team's energy. And this may not be totally unfounded. Sometimes other people accidentally take advantage of us. So having this kind of default distrust is natural. It's normal for us to start out relationships, especially with outsiders, with a healthy amount of distrust. And so your goal as a manager in that scenario, or potentially as the external party, is to figure out how can we build a shared sense of trust? Specifically, for example, how can we get on the same page about how important my request is with relative kind of importance or prioritization to the existing work that this team is already doing? If we can get on the same page about that, then perhaps when I bring something to this team, then they will trust me because of what I know. They'll trust me because I have context into what they do, into their priorities, recognizing as early as possible that the exercise to be done is not one of, you know, painstaking, perfect definition of your problem. But instead, it's likely one of trust building between two people or between two teams. If you figure this out early on, you're likely to solve the problem with a lot less headache. We're going to take a quick sponsor break and then we're going to come back and talk about the second aspect of this lens of trust. Developer Tea is supported by Square. There are millions of sellers across the globe using Square to run every aspect of their business and many are looking for customized solutions that are deeply connected and easy to use. Does that sound like something you can build? Well, you can grow your business by extending or integrating with Square using free APIs and SDKs to build tools for sellers. Learn more by going to developertea.com slash square. That's developertea.com slash square. Takes again to Square for supporting Developer Tea. We're talking about trust in today's episode and an important aspect of trust is recognizing that it is indeed a fundamental resource and you should treat it as a resource. In other words, don't spend it in places where it shouldn't be spent. We'll talk about one phenomenon that might lead you to spend trust where it shouldn't be spent in today's episode. That's called the Halo Effect. Imagine you have an engineer on your team who has done an excellent job as an engineer for, let's say, seven years. They're a senior on your team. They've seen every problem that this business has encountered. Basically, they've been here from the start. They've seen scaling issues. They've seen interpersonal issues and they've handled all of their work to the most professional degree. A new position is opening up on a team parallel to yours and that position is an engineering manager role. This person has expressed that they would like to get a promotion and so you recommend them for the role. I'll press forward a few months, the person is very unhappy and unfortunately has not done well in that role. This doesn't seem to cognitively line up because when we trust somebody very deeply in one area, when we've built a relationship of trust between us and another person that has a lot of evidence, a lot of backing in a particular area, we often hearistically, meaning automatically, kind of without really processing it deeply, we allow that trust to bleed over into multiple other areas. If we think about this a little bit more, it makes sense. Our brains can't really adequately categorize people in terms of what skills they have that run really deeply. Instead, our brains are optimized for networking, for creating some kind of social understanding of who is dependable and who is not. When this trust is conferred essentially, because you trust one part of a person deeply or because you have a positive feeling about them in a particular way, which essentially transfers into trust, then it confers out to other areas and you may misplace an extra amount of trust in that person. I do want to be clear here that we're not talking about actively distrusting a person as an alternative. Much of the usage of the word trust in this episode could likely be swapped out with the word belief, but trust works in non-specific ways. You may have trust in an area where as you might have to have a belief that a person will act in a specific way. Interestingly, the Halo effect can be applied to kind of network trust as well. So, let's say as a manager, I have a lot of belief in the senior engineer that I was talking about earlier. I believe in them. I trust them and I allow the Halo effect to convince me that they're going to be good as a manager. So I make an official and convincing recommendation to My Boss, let's say My Boss is a director or something. My Boss, in turn, trusts me and therefore transfers their trust in me onto the things that I trust. In other words, this transit of property of trusting doesn't really verify against that original error that I made because of the Halo effect. Now, why does this all matter to our work? This happens on a day-to-day basis in small decisions as well. If we trust other people to review code, for example, and something in that original review process has some kind of error, then that trust can end up being violated. So, it makes sense for us when we're thinking about very important decisions like, for example, having somebody switch tracks from engineering to management. Those kinds of larger career-level decisions, architectural decisions, when those decisions have some factor of trust involved, we should pay attention to the origins of that trust and be very clear about what exactly it is that we're trusting. For example, we might take the time to convert our trust into a stated set of beliefs. We have a trust in this person, but our trust is informed by these specific beliefs, and these specific beliefs are informed by this specific evidence. If trust is a type of resource, then this process was essentially budgeting. At the end of the day, it's likely that your team will work better if you are generous with your trust rather than stingy. But you should make it well-known that trust is not a cheap resource, and that it's everybody's job to protect it. Thanks so much for listening to today's episode of Developer Tea. This discussion on trust, I hope you enjoyed it. I hope it was challenging and helpful. Thank you again to today's sponsor Square. You can get started with Square's free APIs and SDKs by heading over to Developer Tea.com-square. I'd love to talk to you about your career, about your life, about the questions that you have, whether it's for the show or for yourself. And there are other engineers who would love to talk to you as well. If you'd like to have that discussion, join us in the Developer Tea Discord, head over to Developer Tea.com-square to get started today, that's totally free for the listeners of this show. Thanks so much for listening, and until next time, enjoy your tea.