What if the people that you think need the most leadership development already actually have it? Think about your technical team. They might not speak up in meetings the same way as others. They might prefer logic over charisma and precision over persuasion. But every day they navigate ambiguity, they untangle messy problems, and they make smart decisions under pressure. That's leadership. We just don't always call it that. I've worked with lots of technical teams over the years, developers and engineers and architects and analysts. And time after time I've watched someone solve a very human problem like a team conflict or a workflow breakdown or a decision bottleneck, using the very same thinking that they use to solve complex technical problems.

They debug, they prototype, they use systems thinking, they adapt fast and build things that work. So I want to challenge the idea that leadership has to look a certain way, that it has to be loud, or that it has to come from the top down. Because if your team already knows how to test, adapt and build, well, maybe they're closer to effectively leading than you think. So let's talk about why your technical team has more leadership skills than most people realize and how you can recognize that in them. So I want to share a story about when I was brought in to help a technical team. Now, this was an organization that I had keynoted an internal event for, and then they brought me in to do some additional training. And one of their high level managers said that they needed some specific help within one of the teams. And so I was working with them on a variety of factors inside that team and that you could sense that it was palpable, the tension between two senior engineers on this team.

And so outside of the conference room where I could feel that tension, I asked the manager, I was like, what's, what's up with these two? Like something's going on there. And the manager told me, oh yeah, well, they've just got a personality conflict. These two just don't get along. Now I never necessarily just it as a personality conflict, I mean, in all of my decades, in all of my life, I have maybe felt what I would call personality conflict with two people, two specific individuals. And I could name them, I will not, but I could name them. So I'm not going to just leave it as a personality conflict. So I asked the manager, I said, well, the next time we're together with all, you know, with the team, can I ask a few more probing questions? Can I, you know, can I finesse this a little bit, see if we can get to some root cause and the manager said, oh, absolutely, like, do whatever you can. If we could clear this up, that would just make things just so much better for the whole team.

So I got a chance then to ask some follow up questions. So when I felt this tension brewing, I said, hey, wait a minute, I, you know, I, I'm curious to know what's, what's behind that because I felt some tension there and I, you know, and so one of them jumps up, grabs the dry erase marker and goes up to the whiteboard in the conference room and said, let me just diagram this for you, and drew this complex organizational chart with these dotted lines of who reports to who and who has the dotted line relationships and all of that. And as he's drawing that his, his counterpart, the one that he supposedly has the personality clash with, is completely agreeing with everything he's drawing. And he's like, yes, it is that complex and yes, it is that. And so once the whole diagram was up there, I just acknowledged and appreciated, well, that's a lot of complexity for decision making and getting work done and so forth. And they, you know, they agreed, but you know, it was kind of like one of those moments of when you're the fish swimming in the fishbowl, you don't realize you're in water. They, so they didn't really have much appreciation for the complexity of the organizational system that they were working in. But once they drew it out like that, or you know, one of them drew it and the other one completely agreed with it that they had a deeper appreciation.

And of course I was calling out the appreciation to it as well, but literally it was not me solving the problem, it was me asking a couple of questions and then solving the problem with the nuance that was in this diagram. So they were basically using a debugging mindset to identify the root cause of what was going on. So what it ultimately came down to, and I did add a little bit of additional technical language of my tech, you know, the management, management speak, if you will, on top of what they were doing. But what they had done is debugged the problem. And then what I was noticing is that they were both taking orders, sometimes from the same people, sometimes from different people, but they were experiencing the recency effect. So whoever had communicated them with, with them the most recent, that was the boss that they were leaning towards. And they weren't always getting the same information in the same cadence. So once we were able to tease that apart and they saw that we can't be relying on the recency effect of who's heard what from whom.

The most recently, we have to really be looking at what's the overall project structure, what's the overall goal and timeline and so forth. And they basically just needed to be in greater communication with each other and not relying on the recency effect of who'd heard what from whom most recently. And they solved it themselves. They basically debugged their own problem. So again, I think we often underestimate technical folks in terms of their ability to use their existing expertise and knowledge to lead, whether that's leading from the side or whether that's leading from a higher place on the organizational chart. Now, again, this guy wasn't just debugging a system, he was debugging his team. And that is absolutely leadership. Now, it's also UX thinking, which, if you listen to the last episode where I really got into the nuts and bolts of what I mean by UX thinking, this is exactly what he was doing.

He was using UX thinking to explain what was going on. And together they reduced friction. You might remember that from that episode as well. They reduced friction and found a way to work through a challenging situation. And they basically did it themselves. I mean, I gave a couple prompting questions to get the conversation started, but they're the ones who solved it. So there's lots of different ways that this unfolds in organizations. And what we often think of when we think about technical managers, and I'm sure you've heard it, the term the Peter Principle.

And the idea with the Peter Principle is that mostly technical people get promoted to their level of incompetence. So they are maybe a really good coder, and then they become a lead coder, and then they become a supervisor, then a manager, then a director. And they're working their way out of the skills that they do so well and into a set of leadership and management skills that they maybe haven't been trained for or formally trained for, let's just say. But I am of the ilk of the persuasion that if they lean into their technical skills and apply their technical skills to the people problems and to the team problems, they are going to really accelerate their leadership not only for themselves, but how they're perceived as leaders in the organization. There are lots of transferable skills that technical folks have. And I want to just say that these are leadership skills by another name.

So let's just go through a handful of them. And so we'll look at what's the technical skill. And then how does that translate into a leadership capacity? So debugging now? And that was exactly what was going on in the situation that I had just described for you, where we have these two at senior level technologists who supposedly have a personality conflict, but really there was nothing about their personalities or their traits or anything that was incompatible. It was just that they had some conflict that was inherently built into the system because of how complex it was. And so this requires asking questions, staying calm, and drilling down into those root causes. So a root cause analysis, I mean, one of the best techniques and technologies for doing root cause analysis to get to the bottom of the why a problem is occurring is to use a tool called the five whys. Now, they didn't use the tool called the five whys in that particular instance, but they could have. And it's very similar to debugging a piece of code that isn't working.

So the question that you would ask yourself was, well, why isn't this working? And then you, you know, go down kind of layer by layer, finding the parts that are working, the parts that aren't working, and continuing to ask why, why, why, why? Until you debug the whole system. So debugging equals conflict resolution. So if you know how to debug a piece of code, you can do conflict resolution. All right, systems thinking. So systems thinking from a technology standpoint is really understanding how, you know, this part of a system interacts with this part of the system and could potentially cause problems for this part of a system. A lot of times when a person changes a piece of code over here, it impacts something over there after it all gets compiled and it all starts working together. And so if you've got that sense of systems thinking where you can see how things are interrelated, well, that equals organizational awareness. So leaders need to see how different parks parts of the organization interact.

They need to see how different people interact with one another, how different people interact with the clients, whether those are internal clients or external clients. And then they need to be able to anticipate downstream effects and then look at optimization of the whole system, not just these siloed tasks. They're really looking at how all the different pieces play together. So if you are skilled at systems thinking, I'm going to posit that you have organizational awareness.

All right. The third technical skill I want to talk about is process design. So when engineers build processes, they're making intentional decisions about how things get done. So we could take a process, like a software methodology process like Agile or like Waterfall, and think about how all the various steps are sequenced to design that particular process.

If you can do that, well, my friends, you can do strategy, because this is how the leaders at the top of the organizational chart, the ones in the C suite, this is how they do strategy. They're thinking about and they are making intentional decisions about how things get done and what outcomes that's leading to, and they're being intentional about doing that. So, so process design, if that's a skill that you've got, well then, my friends, you've got strategy as a skill.

All right, Design principle number or skill number four Technical skill number four, rapid prototyping. So when with rapid prototyping you build something, you don't build it all the way out, but you build it just enough for it to kind of do the thing that you want it to do. And then you start to see where there's friction, what's working, what's not working, and you continually iterate and you make it better, better and better and better instead of getting all the way finished and then going back and looking for where you can make fine tune or, or where the problems are. With rapid prototyping, you're constantly watching at every short and small iteration of the prototype, looking for feedback, trying to fail, literally trying to fail fast and find those failure points and then fix them before you've created something that's fully baked. Because it takes a really long time to create something that's fully baked and then, you know, load test it and look for the failure points.

So with rapid prototyping, we're looking for failure points all along and we're going through rapid cycles of making things better. If you're doing that, my friends, if you know how to do that, then you've got adaptive leadership in your back pocket. These are the cornerstones of modern leadership. We want systems to fail fast because we don't want to, you know, find out at the quarterly earnings report what happened. No, we want to fail fast and find out what's going on so that we can fix it before we get to the end of the quarter, we want to fix it this week, maybe even today. So that is adaptive leadership. And then finally the fifth one, if you're good at documentation, and I don't care if that is a technical spec, if that is end user documentation, if you can write clean, clear, crisp language, maybe even reusable code, that is documentation. And documentation is leadership in action, that is communicating clearly, so clarity in your communication, teaches scales and supports others.

So if you've got Documentation down, you have at least a running start on clear communication. Now let's for a moment break this apart and look at why don't we always see it this way? Why don't we see these things as leadership skills? Well, there is a cultural bias towards extroverted folks, high visibility people, and we equate that with leadership. And that does not necessarily scale to your technical folks. That does not necessarily resonate with your technical folks. And many organizations over index on presence and communication skills at that high level. Maybe that's public speaking skills, maybe that's running a meeting effectively, those kinds of things. So many organizations will over index on those rather than problem solving. And then finally, technical folks often undervalue their own contributions if it doesn't look like traditional leadership.

So despite all of the progress that we've made in rethinking what leadership looks like, because I mean, leadership is a discipline that continues to grow. And for as many people as there are who speak about leadership, there are just as many definitions and methodologies and everything. And so we've made lots of progress in expanding what leadership looks like. But we still carry some deeply ingrained assumptions, many of which do not serve technical teams. So let's break those high level things down that I was just talking about a little bit more. So first of all, we overvalue visibility. So most traditional leadership models reward those who are vocal, who are persuasive, who are great at presenting in the spotlight. But many technical leaders have a quieter form of leadership.

They lead through action, not through airtime. They don't always talk about the solution, they just quietly go off and build it. And that can be easy to overlook in performance reviews and especially during succession planning when the senior leaders are thinking about that next level of developing a bench of who's going to step into leadership positions as they become available. So number one, we overvalue visibility. Number two, we mistake communication style for capability. If someone struggles to articulate their ideas in real time or prefers to process internally before sharing, we might assume that they're just not ready to lead. But in reality, their communication, well, they just might be wired differently for communicating. They might be more thoughtful, more written down than spoken out loud, more signal than noise.

Now that doesn't mean they aren't leading, it just means they have a different communication style. So we need to look for, we need to be more expansive about considering communication styles as it relates to leadership. So number two, we mistake communication style for capability. Number three, we separate soft skills from hard skills. And that's A false divide. There is nothing soft about managing conflict, my friends. There is nothing soft about aligning project stakeholders or keeping a team moving through complexity. There's nothing soft about any of that.

But because we've siloed emotional intelligence and people skills from the technical domains, we often forget that many technical folks do these things. They just don't always call them by the same names. So we separate those soft skills from hard skills, and that's a false divide. Number four, tech people don't always identify as leaders. So even when they're leading by mentoring junior developers or designing scalable solution solutions or preventing system failures, they often don't label it as leadership. They just see it as doing my job. And unless somebody helps them reframe those actions through a leadership lens, they may not see a path forward for themselves as a leader. So number four, technical people don't always self identify as leaders.

And then number five, managers don't always know what to look for. Too often, technical excellence and leadership potential. Too often technical excellence and leadership potential are treated as separate tracks. But if you know what to look for, patterns like anticipating downstream effects, simplifying complex problems, or influencing decisions through logic, well then you start to see leadership embedded in the day to day work of your technical team. And then you can start to spot it when they've got it. So number five, managers don't always know what to look for. Now let's talk about what to do about it because, you know, I'm not just going to open a big can of worms like this and leave you with it. Let's talk about how we can do more to capitalize on the technical strengths of our technical folks and start to see that as leadership.

So if you are a leader or a manager, whether that's a supervisor or all the way up to the C suite, be the catalyst. A catalyst is a substance that speeds up a chemical reaction without necessarily being, you know, permanently and always involved in the process. So in simpler terms, it's something that makes a reaction happen faster, but it doesn't become part of the final product. Catalysts are both crucial in chemistry and biology and I'm going to say in your organization. So here's how you, as a manager, a supervisor, or part of the C suite, who can be a catalyst. Start identifying these hidden leadership behaviors in your team, the five that we just talked about. Look for them. Absolutely look for them.

And call them out when people do it. And you will need to make the dotted line. And sometimes not even a dotted line. Sometimes you need to Outline it in no uncertain terms that that thing that person did, that debugging the personality conflict is leadership. And don't wait for somebody to be more vocal to see their leadership potential. Look for it and use language that they resonate with. Words like architecture, iteration, versioning. Use those as metaphors for growth, their own personal and professional growth.

Now, if you're a technical team member, so you're the individual contributor and some of what I've said today resonates for you. You're like, yeah, I do have those things, technical skills. And I never thought about that as leadership before. Here's what I want you to do. Reframe your skills. Leadership isn't something you need to go out and get. It's something you already practice every single day. So notice when you are successful in leadership, look for it in your own behavior.

If you don't look for it, you won't see it because we don't see what we're not looking for. So you need to look for it and identify it and then self identify as a leader. So you will not see it if you are not looking for it. So I need you to go start looking for it and then own it. Be confident about it. The same way that you're confident about your subject matter expertise and your technical skills. You own that. I mean, I can't even tell you how many times I've sat in a conference room and heard some technical person totally go to bat for their technical idea because they know it's right and they feel strong conviction, conviction behind it and they make the most persuasive argument.

So when you see your own leadership skills, I want you to own them. Own it just the same way that you own your expertise in your, your area of subject matter, expertise and domain. So start owning the leadership that you're already doing. Whether that's debugging meetings, architecting processes, anticipating risks, whatever it is, just own it because it's there. All right? If your team already knows how to test, adapt and build things, maybe they are closer to leading effectively than you think and they are further from Peter's principle than you think. They just need a catalyst to activate their leadership chemistry and give them the confidence to move through the world as a leader. So I want you, my dear friends, to share some examples with me. When you see someone on a technical team showing unexpected leadership, I want you to share it with me.

Share it with them too. Take them aside afterwards and say, hey, that was awesome. You know, that was actually leadership. Or maybe you yourself are starting to realize your own skill set has leadership baked into it. So I want you to see it. I want you to own it. And if this episode resonated for you, I want you to share this episode with another technical person just like yourself. Because I don't want this to just be a one off.

I want this to be a movement. So my call to action for you, my friends, is right now. As you finish listening to this episode, I want you to think of one person who could really use this and send it their way. Because when we do that, well, you're not going to be surprised to hear me say this. That is leadership. Okay, my friends, stay ahead of the curve. Keep doing all the things you're doing. Keep using UX systems, thinking and baking it into all of the work that you do.

Until next time, my friends, be well.