There is an assumption that leading a technical team means you need to be the most technical person in the room.

I am not.

I lead people who can troubleshoot networks, dig through logs, build automations, solve complicated system issues, and occasionally have conversations filled with acronyms that require me to stop and ask, “Okay, explain that part to me.” And I have learned that this does not make me less capable of leading them. In some ways, it has made me better at it.

You Don’t Need Every Answer

One of the most useful things a leader can say is: “I don’t know. Explain it to me.”

Technical people know when someone is pretending to understand something they do not. I would rather ask questions and learn than try to sound like the expert. What is happening? Why does it matter? What are our options? What would you recommend?

Those questions help me understand the problem while also encouraging the person closest to it to step back from the technical details and think about the bigger picture.

Curiosity Matters More Than Pretending

Being non-technical does not mean being uninterested in technology. I am constantly curious about how things work, how they can work better, and why we do things the way we do.

When someone builds an automation, I want to know what problem it solved. When a technician says a process is frustrating, I want to understand why. When someone says, “There has to be a better way,” I want to hear the idea.

My team may understand the technology better than I do. My perspective is often focused on how that technology affects the client, the process, workload, cost, or the company as a whole. Both perspectives matter.

Learn Enough to Ask Better Questions

A non-technical leader still needs to learn. I may never configure the firewall myself, but I should understand why it matters. I may not write the script, but I should understand what it is automating and what success looks like.

Over time, you learn the language simply by staying curious. Ask what the acronym means. Ask someone to show you what they built. Read about the new tool. Learn enough that the next conversation makes a little more sense than the last one.

You do not have to know everything. You just have to keep learning.

Trust the Experts You Hired

There is something humbling about managing people who know significantly more than you do about their area of expertise. That requires trust.

If I hired someone because they are technically skilled, then their expertise needs to have a voice in the decisions we make. That does not mean leadership disappears. I still have to consider cost, risk, client impact, process, and the bigger business picture.

“You know this better than I do. What do you think we should do?” Then I need to actually listen.

Technical Skill Does Not Replace Accountability

Technology can be unpredictable. A ten-minute issue can suddenly become a three-hour problem. That is part of the work. But complexity cannot become the explanation for everything.

Clients still need communication. Tickets still need updates. Escalations still need to happen. Documentation and processes still matter. I may not always know exactly how to solve the technical problem, but I can ask whether we are solving it efficiently, communicating well, and learning from it afterward.

Strong technical teams need both technical excellence and operational discipline.

Sometimes the Simple Question Is the Useful One

Some of my favorite questions are also the simplest:

• Why do we do it that way?
• Does a person really need to do that step?
• Could we automate it?
• Could we catch this before the client notices?

Sometimes the people closest to a process are so used to it that they stop noticing the unnecessary parts. Someone looking at it from a different perspective can occasionally spot an opportunity everyone else has learned to work around. That is one of the advantages of bringing different kinds of thinkers together.

My Job Is to Build the Environment

Eventually, I realized my job is not to become the best technician on my team. My job is to create an environment where great technicians can succeed.

That means removing obstacles, setting expectations, encouraging ideas, recognizing good work, watching the data, holding people accountable, and connecting technical work to the larger goals of the organization.

“Sometimes leadership is knowing the answer. But often it is knowing who to ask, asking the right question, and being willing to learn from the people around you. When you lead experts, you do not have to compete with their expertise. You get to build something with it.”