What happens when your role outgrows your technical background
One of the guarantees of career progression in technology leadership is that, eventually, you will outrun your own resume.
Most technology leaders start as specialists. Frontend, backend, SRE, QA, mobile, data. Your first leadership role is often managing a team you used to be on, doing work you understand deeply. That familiarity is comforting. It’s also temporary.
As your scope grows, you start owning work you’ve never done yourself. A backend lead suddenly finds themselves managing frontend teams. An application developer finds themselves responsible for mobile, infrastructure, data, or security. Eventually, the gap widens enough to feel genuinely uncomfortable.
That discomfort is normal. It’s also where many leaders get stuck.
Early in my management career, I felt that pressure acutely. I had spent years as a C++ application developer. That expertise was my credibility. When I found myself responsible for iOS clients, Ruby backends, and systems I didn’t know well, I worried that I was no longer qualified to make decisions or lead effectively.
My instinct was to compensate by trying to learn everything. I wanted to stay technically credible in every domain I owned.
That instinct turned out to be the wrong one.
The trap of technical credibility
As leaders, we often confuse credibility with expertise. We assume that to lead an area, we need to be the smartest person in the room about it. That might work when you’re leading a single team in a domain you know well. It breaks down quickly as your scope expands.
If you try to become an expert in every system your organization owns, you slow everything down. Worse, you undermine the people you hired to be experts. You become a bottleneck without realizing it.
The opposite mistake is just as damaging. Some leaders disengage entirely from unfamiliar domains. “I don’t know that area, so I’ll just trust the team and focus on what I know.” That signals disinterest, even if you don’t intend it to. Teams notice. Motivation drops. Accountability weakens. And you’re still responsible when things go wrong.
Neither extreme works.
The real challenge isn’t a lack of knowledge. It’s understanding how your role changes as your scope grows.
How leadership actually shifts
There’s a progression most leaders have to make, whether they realize it or not:
You start by doing the work.
Then you review the work.
Then you design how the work gets done.
Eventually, you design the system that produces good decisions.
When you’re leading areas you’ve never worked in, your role moves firmly into those last two stages. You are no longer there to solve problems directly. You’re there to make sure the right problems are being solved, in the right way, by the right people.
That shift is uncomfortable if your identity is still tied to being a strong individual contributor. But it’s unavoidable if you want to lead at scale.
Failures at senior levels rarely stem from a lack of subject-matter expertise. They come from unclear ownership, misaligned incentives, poor decision-making systems, and leaders who stop being curious about the parts of the organization they don’t personally understand.
What to focus on instead
You don’t need deep expertise in every domain you own. You do need a solid mental model.
That means understanding the vocabulary, incentives, constraints, and common failure modes. It means being able to follow the conversation, ask good questions, and recognize when something doesn’t quite add up.
The questions that matter at scale are remarkably consistent, regardless of domain:
- What does “good” look like here, and who decides?
- What happens if this fails?
- What risks are we knowingly accepting?
- Are we relying on heroics?
- How do problems surface early?
Those questions don’t require you to know the implementation details. They require judgment, context, and experience. That’s the transferable part of your background.
Your job is to let specialists own the “how,” while you own the “why” and the “so what.” When you provide clear context and intent, good teams make better decisions on their own.
Things you have to stop doing
Leading unfamiliar domains also requires unlearning some habits.
You have to stop pretending to be the smartest person in the room. Your job is to hire people who are better than you at their craft and give them room to do it well.
You have to stop asking detailed technical questions just to mask uncertainty. People can tell when you’re doing it, and it erodes trust rather than building it.
You have to stop measuring success only through artifacts and dashboards. As you move up, outcomes matter more than outputs. Metrics are signals, not substitutes for understanding.
Trust without abdication
Trusting domain experts doesn’t mean stepping away. It means staying engaged without micromanaging.
You are still accountable. You still ask questions. You still challenge assumptions. But you don’t make decisions for teams in areas where they clearly know more than you do.
You also have to create space for people to disagree with you. Role power makes that harder than most leaders realize. When you suggest something, people often hear a decision. If you don’t actively invite dissent, you lose valuable signal.
That matters even more when you’re not the expert.
The long view
Over time, leading unfamiliar domains gets easier. Not because you become an expert in everything, but because you get better at learning just enough, asking better questions, and building trust with the people who know the details.
Progression doesn’t mean abandoning your technical background. It means extracting the lessons from it and applying them at a different level.
If you’re feeling exposed because you’re leading something you’ve never done before, that’s not a sign you’re failing. It’s usually a sign that your role has changed faster than your self-image has caught up.
That gap is uncomfortable. It’s also where real leadership growth tends to happen.
To hear an extended discussion of this topic, please listen to my podcast episode: Leading What You’ve Never Done Before.
Originally published in the It Depends: Lessons in Technology Leadership newsletter at https://kevingoldsmith.substack.com/p/leading-what-youve-never-done-before