It probably won't be the first time you hear this, but your words have power. They change the people around you, or at least they influence the people around you. Maybe a philosophical argument is that the people around you have chosen to be influenced by your words, but nevertheless your words matter. And your words matter in a different and unique way from your coworkers. You may have a different type of influence in a specific context than your own manager or the CEO of your company. Everybody's words have different influences on the people around them, and it's important to realize when these influences have a profound effect on your evolution. on teams and companies. In today's episode, we're going to talk about this idea. We're going to talk about it in the frame of leverage. My name is Jonathan Cottrell. You're listening to Developer Tea. And my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And you've probably experienced this before. If you've been working very long in this industry, or really in any social context, you know that the words that one person says can have a profound impact on the teams that they're involved with, or even just the group of friends that they have. The people who are natural leaders, but not just the leaders, can have major influence over their group. Instead of thinking about this in terms of leadership, think about it in terms of representation. What do the words of a given person represent? Social. Or politically in a given group. What do they mean to the group? And this is how we arrive at the concept of leverage. And for the sake of today's episode, we're not talking about financial leverage. It's a totally different concept. Instead, we're talking about the more scientific concept of leverage. The idea that with the same words or the same effort put forth, you can move more. You can have more, in this case, influence. And if you want to carry this metaphor all the way out, your context is kind of the fulcrum of that lever. What you represent to the group, that is the context, the fulcrum of your leverage. And it's important to understand, or at least try to understand, what you represent in a given group. For example, it can be very clear, some of the things that you might represent. If you're a manager, you might represent the gateway to growth for your direct reports. And so your words about what should or shouldn't be done may be taken more to heart than another developer on the team. This particular position is not that surprising of a position of leverage, but there may be more surprising positions of leverage, and they may change over time. We're going to talk about a few of these positions of leverage, and how you might avoid the harm that this leverage could create while taking advantage of the good that the leverage can create, right after we talk about today's sponsor, Abstract. Designers and developers face a lot of similar problems. For developers, we've always needed to merge our code together. If you have two developers working on the same project, they're inevitably going to work on the same files at the same time, and ultimately they're going to need a single source of truth. But designers haven't really had that single source of truth. And designers know this all too well. They spend a frustrating amount of hours searching for files, consolidating feedback from multiple sources, never really knowing what changes have been incorporated or approved. All these problems are why Twitter principal designer Josh Brewer co-founded Abstract. It's like GitHub, but for designers. And Abstract is your team's version-controlled source of truth for designers and developers. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it's a great it's a great way to get the most out of your team. And it's a great way to get the most out of your of your team. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it's a great way to get the most out of your team. And it brings all of your design workflow into a single unified place, where designers, developers, and stakeholders can collaborate and keep work moving forward. Companies that you know, like Microsoft, Spotify, Cisco, thousands of others across 75 different countries, rely on abstract to improve their design workflows and increase collaboration. And with abstract, you can version design files, present work, request reviews, collect feedback, and give developers direct access to all the specs, all from one place. Spend less time searching for design files and tracking down feedback, and more time focusing on innovation and collaboration. Sign up for a free 14-day trial by heading over to www.abstract.com. Thanks again to abstract for sponsoring today's episode of Developer Tea. So what are these common points of leverage and perhaps some less common or less intuitive points of leverage that you might have on your team? Well, leverage changes over time because people don't have the same amount of leverage that they used to have when they were changing their team. For example, a new person on a team might for a little while have extra leverage because, quite simply, the novelty. This can be really valuable because someone coming in with fresh perspectives or some particularly important expertise from another company that they're bringing with them, this can greatly improve your team. So allowing that leverage to play out might actually be the best thing to do. So if you're a new person on a team, you can leverage your team to do what you want to do. But that will change over time. As you build relationships, different types of relationships create different dynamics of leverage. And your leverage from one person is not going to be the same to the next person, even if your relationship to them, professionally speaking, is at the same level. Maybe you have two direct reports, and with one of them, you have a certain type of leverage, and with another one, you don't. Now, we should be very clear that leverage is not, holding something over someone's head. We said this in a recent episode of Developer Tea, the concept of leverage is not to give you power to strong arm someone, but instead, to influence them in a direction that is mutually beneficial. But most of the time, we don't really know our own influence. We don't know the types of leverage that we have over people, and our words have unintended consequences. For example, another role on the team that has a lot of leverage is someone like a product owner, someone who represents the stakeholder, or represents the customer. These people tend to have a lot of leverage because they're seen as the kind of abstracted way of learning about what the customer wants. And the way this tends to play out is that the product owner or some kind of stakeholder position will present to the team what they want to do. And they're going to be the ones that are going to believe the customer wants. And in full confidence, they're not trying to trick the team. And this is where the leverage comes in, because these specific points where the product owner or the stakeholder, they bring information to the team, the entire team springs into action in response to this information. This is a very common pattern of information and response on a software development team. It's interesting. Sometimes those product owners don't have it right, or they're guessing. Or maybe they just don't have enough information to be able to kind of leverage the entire team's efforts. But nevertheless, because most humans, and this includes all developers, we want to simplify our understanding of a given situation. So we want to flatten what the product owner represents into an authoritative version. An authoritative representation of the customer. Instead of digging in and validating that, we often treat this product owner or stakeholder's voice as a perfect translation or a transparent view into the customer's requests. Now, this can be problematic for obvious reasons, because if the whole team is leveraged, then this can be like a faulty rudder, or at least an uncertain rudder that's steering the whole ship. And so what can we do about imbalances of leverage? The gut response may be to remove the leverage point altogether. But this is also problematic, because if everyone has to share all of the responsibilities, none of us can focus. No one has the opportunity to lead in a particular area. This can be problematic because making decisions, and all of them through consensus, can stall out the team. So how can you preserve the important leverage that you want to opt in, while avoiding some of the leverage that would steer the team in the wrong direction? There's no silver bullet answer to this question. There's no specific process to manage this. One of the most important things is to be mindful of the leverage that you might have in a given situation, and to try to evaluate whether what you're saying is going to have the intended effect that you want. Additionally, having guardrails so that when you say something that could put an entire team into action, you have some way of validating it with maybe another person. If you have someone who works as your peer, for example, if you are a product owner and you have another product owner in the company, this is a great way to cross-check what you believe to be true. As a team, it's important to face these issues head-on. Talk about the points that are leveraged within the team. Talk about the types of influence that different people on the team have. Do this both in a one-on-one context, but also as a group. Once you have this awareness, you might ask more meaningful and deeper questions of each other. Initially, these questions might come off as challenging some level of authority or competence, but if everyone is on the same page that they don't want the team swinging in all directions, then they're not going to be able to do it. If you're not willing to do it, then you're not going to be able to do it. If you're not willing to do it, then you're not going to be able to do it. These can be really meaningful moments for your team, both at a personal growth level, but also in terms of productivity as a group. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Abstract. Head over to www.abstract.com and start your 14-day free trial for your team today. Today's episode wouldn't be possible without spec.fm. Head over to spec.fm to find other shows like this one. For designers and developers who are looking to level up in their careers. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.