From time to time, I get questions from senior software engineers, from engineering leaders, managers, sometimes even CTOs, about what it means to be a good leader. Now, specifically, we're talking about engineering leaders, but a lot of this will apply outside of that group as well. And of course, the scope of that conversation of what it means to be a great leader can't be covered in one episode of Developers. But the first response, my first response for pretty much anyone who is looking to develop in their leadership, especially those who have the least experience, the first response I give is to focus on creating clarity. Focus on creating clarity. Brene Brown says, And dare to lead that being clear is kind. You probably have heard this before, but maybe it hasn't really made total sense. The inverse of this then could be considered true. Being unclear is unkind. So what does this exactly mean that being clear is kind? And how can we begin to develop clarity as engineering leaders? Let's start with the first question. How is clarity kind? When we think about both the meaning of clarity and the meaning of kindness, the answer to this question becomes apparent. The definition of clarity in this case is not certainty. This is something I want to make very clear. The difference between clarity and certainty. Clarity is absolute honesty and transparency. And when we talk about honesty here, we're not talking about telling everyone everything. Managers, our jobs as managers, our jobs as directors or VPs or CTOs is not just to be an open book about everything. We know all the time. That wouldn't be very helpful. We should be paying attention to the information that the people that we lead need to make good decisions. And when we have information that could allow them to make better decisions, this is what we need to be clear about. If we have information, let's say as an engineering leader, let's say even just a tech lead, a engineer. Let's say a tech lead. If we add information that might allow another person to create a better implementation of a particular feature, then sharing that information in a way that is abundantly clear is kind. This makes sense, right? Because if you are the other engineer, you could kind of use the golden rule here. I would want somebody to tell me if they have information that would help me do my job better. now apply this abstractly all the way up the chain this clarity is kindness mantra can can be seen all the way through the top levels of leadership if i have clarity about goals or importantly remember certainty is not the same thing as clarity if i know that the company or that the department that we don't have goals set yet being clear about that reality is kind because here's where your reports are thinking they're thinking okay how do i do my job better how can i perform well in the current circumstance well ostensibly the thing that i want to do is meet the goals meet the things that my uh direct superior or the leadership chain above me, whatever that is, the company, whoever represents the company to me, I want to meet the goals that they have set out for me to meet. Now, if the company has not set those goals, then the individual contributor or the manager that reports to you, they're going to wonder, are there unspoken goals? Is there something that I don't know that I'm supposed to be doing? This can lead to a lot of kind of circular roadmaps and kind of guesses in the dark. The better thing, the more kind thing to do for your reports is to be clear. We don't have goals set yet for this quarter. So in that picture, your reports have a different kind of agency. They have a different kind of mindset. They have... They have an awareness that the work that they're doing, they may need to take on a little bit more of that goal setting for themselves, for example. So your clarity as a leader allows that person to operate without fear of the unknown, right? If the unknown truly does exist, in this case, not having goals, then they can face that head on rather than having to face it. They can face multiple unknowns. The kind of known unknown in this case is that the goals have not yet been set. Well, if I know that, then I can go forward and try to set my own goals. At the individual level, and this is where most managers and tech leads, when you're providing feedback to another person, providing clear feedback, right? In other words, being totally honest with your feedback, explaining what you mean, explaining what that feedback is in very clear detail, including not only the observation that you're making, but also the consequences of that observation. Being as clear as you can about the situation that you're providing feedback on is kind, simply because the person receiving the feedback now has to answer the question, now what? What do I do with this feedback? What can I do now? And if your feedback is very... If it's vague or if it's not specific enough to the problem that's being identified, or even for the positives that are being identified, if you're not being clear about those things, then the resulting action from the feedback recipient is difficult to determine. What should they do with the vague information that you've given them? In this case, you've created not an opportunity for performance, but instead a guessing game with that report. And even worse, if you've told them that they're doing a good job when actually there's a performance problem, it may feel kind, but in fact that kindness, talking about the definition of kindness for a second, results in the same thing that somebody who is sabotaging that person's career would do. Think about it for a second. If you knew that someone's job was on the line based on a change in their performance, let's say you have a person on your team, their performance is suffering, and you know that if they don't turn things around, then they may have a negative consequence. They may lose their role. They may end up being on a performance improvement plan. Maybe they will not get a bonus. They won't get the promotion that they're looking for. You know that there's going to be some tangible impact on their career if they don't turn it around. Now imagine that you are devious. You are trying to sabotage their career. What would you do? Well, you would withhold that information. And in fact, you would probably tell them, keep going, keep going. You're doing a great job. Keep going the direction you're going. You're headed for the cliff that I want you to go off of. So this idea that you're being nice to the person is actually functionally the same as you sabotaging their career, sabotaging their interests. So withholding that information, withholding the information that you know is important, is important. At the same time, We also need to understand how we can start to generate better clarity on a day-to-day basis in our teams. We've mentioned a couple of different ways, giving clear feedback, providing clear pictures of the current state of things. But if you're a senior engineer, maybe you don't have reports yet. How can you start developing clarity as a discipline? One way you can do this is by asking questions where the clarity is low. On a team, it's pretty common for people not to ask questions that they think everyone already knows the answer to. Think about this. If you are new on a team and you have a question about how things are built, everyone else on the team, you might assume, already knows the answer. And so either you have to... Admit your lack of understanding. Or you have to go on not understanding and trying to figure things out on your own. Now, the interesting thing is, a lot of the time, there are other people who have the same question as you. Even if they've been in that role for even years, they may not know how something that they work on actually works. And this is not just because... You know... They're a bad engineer or something like that. It's not because they're not paying attention. It's not because you're not paying attention. It's because the simple fact that software can be complex. Software that we inherit can be working for a long time without us touching it. We can come to trust software that we don't know exactly what's going on inside of it. Sometimes things work differently than we were told they work or than we assumed they work. So there may be a lack of clarity. Even amongst the more senior and more experienced members of your team. So your role in asking questions in areas where clarity is lacking for you doesn't just improve your situation. It improves your entire team. This is true, once again, at all levels of engineering leadership. Whether you're an individual contributor all the way up to a CTO and everything in between. The small risk... The risk of asking a question that somebody already knows the answer to or that everyone else in the room knows the answer to... Is heavily outweighed by the upside of gaining more clarity both for you and for the other people on your team. So here is your homework. Here is your homework. First, in the next week or so, try to ask a thoughtful question. At least one thoughtful question trying to increase clarity. In whatever your domain is. Whether it's on a team, in a leadership meeting. Maybe it's from you to your manager. Wherever that question can be asked. It doesn't matter if it's asynchronous or synchronous. Ask a question that creates more clarity. One question every day. One question every day. That's your first piece of homework. Your second piece of homework is... Gather feedback from the people that you have either influence... Over or that you report to. About the level of clarity that you create. Alright? So this can happen as a one-time thing. Maybe you're going to do it informally. Maybe you ask them in one-on-ones. Whatever it is, gather the feedback about how clear they perceive you to be. This is incredibly important for your growth in your career. If your colleagues... If your co-workers... Your peers... Your leaders... Your reports... If they think that you are... That you have room to grow in clarity... This is a signal that you need to pay attention to. If they think that you are operating with a lot of clarity... Ask them why. What is it that you're doing that is creating clarity? Is there something that you need to do more of? That you can protect so that you don't stop doing it? Maybe you've gotten feedback that you... That you're harsh. Right? But you don't want to swing back too far the other direction... If people are giving you that feedback. And trade off clarity for harshness. Right? In other words, you don't want to stop being clear for the sake of trying to be less harsh. And so it's incredibly important that you recognize... Hey, maybe my reports are telling me or my peers are telling me that I'm harsh. But also, they appreciate part of that. They appreciate the clarity part of that. Right? So those are your... Your two pieces of feedback. One, ask at least one question every day over the next week. In whatever your domain is. That creates more clarity. And secondly, gather feedback from your peers. Maybe your reports. Maybe your superior. The people you report to. About how clear you are. Thanks so much for listening to today's episode. If you enjoyed this discussion, you would also enjoy the DeveloperTea Discord community. Head over to developertea.com. Discord to get started today. That's totally free. It always will be. A community of software engineers and beyond who are really just looking to improve in their careers and create community while they're doing that. So head over to developertea.com. Discord to get started today. Thanks so much for listening. And until next time, enjoy your tea.