Why Technical People Sometimes Struggle to Lead

Episode transcript

Transcript provided for accessibility and search. Minor transcription errors may remain.

SPEAKER_00 0:00

You're listening to How Work Really Works with Steve. Practical advice to help you communicate better, lead with confidence, and advance your career. There is a fairly common career story in technical organizations. Someone becomes very good at the technology. They understand the systems, they solve the difficult problems, they stay calm during outages. They are the person everybody calls when nobody else knows what is happening. So naturally, the organization promotes them into management, and then asks them to stop doing most of the things that made them successful. Welcome to leadership. The assumption is that if you are excellent at the technical work, you will also be excellent at leading the people who do the technical work. Sometimes that is true. But technical expertise and leadership are different capabilities. They overlap, certainly. Credibility matters, judgment matters, understanding the work matters, but leadership introduces an entirely different operating system. Technology is logical. It has documentation, rules, buttons, and predictable responses. If something is broken, there is usually a reason. It may take six hours, three vendors, and a slightly concerning amount of coffee to find it, but there is a reason. People are different. People have ambitions, insecurities, expectations, moods, outside pressures, and opinions about meetings, mostly negative opinions about meetings. I did not make a clean, deliberate transition from technical work into management. Mine happened organically while I was working in the Middle East. I was given responsibility for a large technical transformation project. The assignment expanded, the number of people involved increased, and before long, people were reporting to me. The project role gradually became a management role, and management eventually became a permanent part of my career. There was no dramatic ceremony, nobody collected my technical credentials and handed me a leadership manual, the work simply changed. But my habits did not change at the same speed. I still knew the technology. I still had access to the systems. I still knew how many of them had been built because I had either built them myself or been heavily involved. That made it very tempting to remain the person who solved everything. And that is the first trap for technical leaders. You are promoted because you can solve problems. Then your new job requires you to stop solving every problem personally. Your value is no longer just what you can do with your own hands, your own knowledge, and your own heroic late-night intervention. Your value becomes what the team can accomplish because of the environment you create. That sounds obvious when you say it calmly into a microphone. It is considerably less obvious at 2 in the morning when a system is down and you know exactly where the password is. I am Steve, and this is how work really works. Today we are talking about why technical people sometimes struggle to lead, why I certainly struggled with parts of it, and how technical expertise can become either a leadership advantage or a very comfortable trap. The hardest technical habit for me to surrender was access. I had accumulated access to all sorts of technology throughout my career: domain controllers, file servers, firewalls, security tools, infrastructure platforms. Having access gave me control, and control felt responsible. If something went wrong, I could get into the system, investigate it, and help fix it. That sounds useful, and sometimes it was. It was particularly useful in cybersecurity, where speed, authority, and decisive action genuinely matter. But control has a habit of expanding beyond the situations where it is useful. If you can step in, you probably will. If you believe you can solve the problem faster, you probably will. If somebody is struggling and the deadline is approaching, taking over can feel like the responsible thing to do. I did that many times. I stepped in, took control, solved the problem, and worked the long hours necessary to get it finished. The immediate problem was resolved, but there was another consequence that was less visible. I had taken autonomy away from the person who was supposed to be learning how to solve it. I did not let people fail forward. They did not get to wrestle with the problem, make the decision, experience the consequences, and develop the confidence that comes from getting through it. They learned something else instead. They learned that if the problem became sufficiently difficult, Steve would eventually take over. That is not delegation. It is delayed intervention. And it creates a very capable manager surrounded by people who are never allowed to become as capable as they could be. This is one of the hardest transitions for technical leaders because the instinct comes from a good place. You care about the quality of the work, you understand the risk, you feel accountable for the outcome. You may genuinely know the technology better than the person working on it. But leadership is not a permanent demonstration of your superior troubleshooting ability. Sometimes your job is to watch somebody approach the problem differently from you. Sometimes your job is to let them make a decision that is not the decision you would have made. And sometimes your job is to allow a small, recoverable failure now so that they are ready for a much larger problem later. That does not mean abandoning people. Good delegation is not saying you deal with it and disappearing into another meeting. It means defining the outcome, explaining the boundaries, making the risks clear, and agreeing when they should come back to you. Then you give them room. Delegation took me a long time to develop because I had been with the organization for years. I knew the history. I had helped build many of the technologies. I took the environment personally. But if everything still depends on the person who built it, you have not created resilience. You have created dependency with excellent documentation, if you are lucky. My control sometimes produced good results, especially during serious cyber situations. It gave me authority and allowed me to move quickly, but it also created bottlenecks. It frustrated people around me, and, looking back, it probably limited the career development of some of the people who worked for me. I regret that. Technical leaders have to recognize that control can protect the system while quietly restricting the team. The question is not whether you can solve the problem. The question is whether you are building other people who can solve it without you. The second major challenge for technical leaders is discovering that the technically correct answer is not always the answer the organization will choose. Technical people often think in relatively clear terms. The design works or it does not. The system is secure or it is exposed. The capacity exists or it does not. Ones and zeros. Then you enter broader leadership conversations and discover budgets, strategy, timing, commercial relationships, existing contracts, organizational politics, and executives who have already mentioned a particular solution to the board. Suddenly, the answer is not binary. You may need to use a partner you would not have selected. You may need to delay the technically ideal solution because the business has another priority. You may need to accept more risk than you would prefer because eliminating all risk would eliminate the project as well. This can be deeply frustrating for someone whose identity has been built around finding the right answer. But leadership requires more than technical correctness. It requires understanding the business context, explaining the consequences, and helping the organization make an informed decision. Your job is not always to win the argument, your job is to make the trade-off visible. Communication becomes critical here. I was always comfortable talking with technical people, individually or in groups. The harder skill was learning how to translate technical language into business language. Technical people often explain how something works before explaining why anybody should care. We begin with the architecture, move through the protocols, provide a short history of encryption, and eventually arrive at the business problem just as everybody else leaves for lunch. Leadership requires the opposite sequence. Start with the business problem. Explain the effect, describe the decision that is needed, then provide the technical detail appropriate for the audience. I often tell people to explain it as though they were explaining it to their grandmother. If she can understand what the problem is, why it matters, and what needs to happen, you have probably got the communication about right. This is not about treating non-technical people as unintelligent. Quite the opposite. It is about respecting them enough to explain the issue in language that connects with their responsibilities. A finance leader does not need a 12-minute explanation of firewall policy structure. They need to understand the exposure, the financial consequence, the available choices, and the cost of waiting. The ability to translate in both directions is also one of the strongest indicators that a technical person may be ready to lead. Can they go into marketing, operations, or finance and gather requirements without making the other department feel foolish? Can they bring those requirements back and turn them into something the technical team can act upon? Can they explain a complex solution simply without making it inaccurate? That ability to move comfortably between technical and business conversations is leadership currency. Technical leaders must also become comfortable managing people who know more than they do. Earlier in my career, I was often deeply familiar with the technologies my team supported. Later, people developed specialist knowledge far beyond mine. That is not a threat. It is the objective. Surround yourself with people who are smarter than you in their areas. You do not need to prove that you can configure everything they can configure. You need enough understanding to ask good questions, evaluate risk, connect their work to the strategy, and remove the obstacles in their way. If you always have to be the smartest technical person in the room, you will eventually build a room that is not particularly smart. There is one more assumption we need to challenge. Not every successful technical person should become a manager. Some people love technology. They want deeper expertise, more difficult problems, and greater technical responsibility. They do not want to discuss performance objectives, resolve interpersonal conflict, or explain for the fourth time why completing a timesheet is not an optional creative exercise. That is perfectly reasonable. But many organizations still build career ladders that push technical people toward management. You reach a certain level, and the next available promotion is supervisor, manager, director, and so on. The organization takes an excellent engineer, removes much of the engineering work, gives them six direct reports, and then acts surprised when nobody is happy. Human resources teams and technical leaders need to create credible specialist career paths. A highly capable technical professional should be able to gain status, compensation, and influence without being required to manage people. Management should be a career choice, not the administrative consequence of being good at something else. So, how can you tell whether a technical person may be ready to lead? Look beyond technical expertise. Do they communicate clearly? Can they translate between technical and business audiences? Do colleagues seek their help because they develop people, or only because they provide the answer? Can they allow somebody else to receive the credit? Can they make decisions with incomplete information? Can they accept that another reasonable person may choose a different solution? And perhaps most importantly, do they actually want to lead people? Or do they merely want the title and compensation attached to the role? Those are not the same ambition. If you are already a technical leader, here are a few things to put into practice. First, identify the decisions and activities that still depend unnecessarily on you. If the team cannot move while you are unavailable, do not immediately congratulate yourself on being indispensable. Ask why the dependency still exists. Second, stop answering every question immediately. When someone asks what they should do, ask what they recommend. Make them bring judgment, not just a problem. Third, delegate outcomes rather than individual tasks. Explain what success looks like, define the boundaries, and let the person determine how to get there. Fourth, practice translation. Take one technical issue and explain it in plain business language. No jargon, no unnecessary architecture, no abbreviations that require their own glossary. If your grandmother would interrupt after 30 seconds and ask whether the television is broken, try again. Finally, decide whether you genuinely want to manage. Leadership can be enormously rewarding. You can build teams, develop careers, and accomplish things far beyond what you could deliver alone. But you give up some of the certainty and direct control that technical work provides. Technology has rules. People bring grey areas, emotions, politics, and occasionally a resignation email sent at 4.30 on a Friday afternoon. The lesson I wish I had understood earlier is simple. Trust other people. You are not the only person who knows things. You are not the only person capable of solving problems. You do not have to carry all the responsibility yourself. And you certainly do not have to be the only person awake at 2 in the morning fixing everything. Other people can be awake at 2 in the morning too. Let them share the burden. Give them the opportunity to develop the judgment, confidence, and experience that you gained by being allowed to solve difficult problems yourself. Technical expertise can make you a credible leader, but leadership begins when your expertise stops being the center of everything and becomes something you use to help other people succeed. That is how work really works. I am Steve. Thanks for listening, and I will see you next time.