Leadership That Empowers Is Not “Non-Technical”, It’s How Tech Scales

I read a LinkedIn post today that stayed with me.

It described something many of us quietly recognize:

that when your leadership style centers on empowering others, influencing direction, and creating clarity at scale, it can trigger an assumption, that you must somehow be less technical.

That framing landed deeply.

Because being boxed for how you lead, rather than what you understand, is familiar territory.

And as a woman in tech, I’ve spent years navigating rooms where my methods were mistaken for absence rather than intention.

This Was Never About Speed, It’s About Method

This conversation often gets framed around pace, trajectory, or titles.

But that misses the point.

What gets labeled as “non-technical” is rarely about capability.

It’s about method.

I don’t lead by positioning myself as the smartest engineer in the room.

I lead by asking questions that surface assumptions.

By breaking complex problems into shared mental models.

By helping teams connect technical decisions to constraints, outcomes, and long-term impact.

These methods don’t always look technical in cultures that still equate technical leadership with constant hands-on execution.

But they are.

Why I Often Speak Last

In many rooms, I speak last, on purpose.

Not because I don’t have an opinion.

And not because I’m unsure.

I do it because I want to understand how others are seeing the problem before I shape the conversation.

I want the room to surface its thinking, not mirror mine.

Speaking last helps me avoid being trapped in my own bias.

It keeps curiosity alive longer.

It creates space for better questions and stronger decisions.

Real technical leadership isn’t about leading with certainty.

It’s about knowing when certainty would be premature, especially in complex systems where assumptions compound quickly.

Curiosity Is Not a Lack of Competence

There’s a persistent myth in engineering spaces that strong leaders should always have answers ready.

I don’t agree.

Some of the most responsible technical decisions emerge when leaders are willing to say,

“I don’t know yet, let’s understand this properly.”

Curiosity is not weakness.

Listening is not disengagement.

Restraint is not a lack of technical depth.

They are signals of care, responsibility, and systems thinking.

Empowering Leadership Is a Technical Skill

When I empower engineers and leaders of engineers, I am not stepping away from technology.

I am:

💚 shaping architectural conversations

💚 influencing prioritization and trade-offs

💚 guiding decisions toward scalability and sustainability

💚 reducing risk by surfacing blind spots early

💚 translating complexity into clarity across disciplines

That work requires deep technical understanding, just applied at a different altitude.

And yet, especially for women in tech, these methods are often misread as “soft,” “coachie”, “people-focused,” or somehow detached from engineering itself.

They are not.

They are how engineering organizations scale.

Empowerment Does Not Mean Avoiding Direction

Empowering leadership does not mean being passive.

I am very comfortable shifting direction when needed.

I guide teams toward goals.

I challenge thinking when it’s off.

I help people see misconceptions, technical, strategic, or organizational, even when that’s uncomfortable.

I can be firm.

Clarity sometimes requires tension.

Alignment sometimes requires saying no.

And responsibility sometimes means holding the line when momentum drifts or assumptions harden into dogma.

The difference is how that firmness shows up.

Not through authority that silences,

but through reasoning that convinces.

Not through control,

but through direction that people understand and can stand behind.

Why I Don’t Push Code Anymore

I don’t avoid pushing code because I’m incapable.

I pushed code to production for over twenty years.

I stepped back because I remember exactly how it felt to be an engineer.

I remember how disempowering it was when leaders stepped in “to help” and quietly took ownership away.

How unsafe it felt to challenge authority, even when you knew something was wrong.

How I once wasn’t brave enough to tell a CTO that their code was outdated and needed to be fixed.

Not because I lacked insight.

But because the system didn’t make it safe to speak.

That experience stayed with me.

So when I lead now, I choose differently.

I don’t push code because my role is no longer to be the loudest technical voice,

it’s to create the conditions where engineers can speak, challenge, and decide without fear.

Where technical judgment is shared, not overridden.

Where authority doesn’t silence insight.

Where engineers don’t need permission to name technical debt or architectural risk.

That, too, is technical leadership.

Why Reviewing Code Can Also Be Unsafe, Especially When You Appraise People

There’s another reason I’m careful with hands-on code involvement as a leader.

It’s not just unsafe for engineers.

It can be unsafe for the leader too.

When the same person who evaluates performance also reviews or contributes to code, power quietly enters the room, even with the best intentions.

Engineers may hesitate to disagree.

They may avoid pointing out flaws or alternatives.

They may optimize for approval instead of quality.

And once that happens, the signal a leader receives becomes distorted.

You’re no longer seeing the team’s real thinking.

You’re seeing what feels safest to show.

From the leader’s side, this creates another problem.

It becomes harder to tell:

🔥 whether the team truly owns the solution

🔥 whether growth is happening independently

🔥 whether agreement is genuine or cautious

🔥 whether silence means alignment or fear

That ambiguity undermines fair appraisal.

Separating technical guidance from technical authority protects both sides.

It keeps engineers safe to challenge.

And it keeps leaders honest in their judgment.

That separation isn’t disengagement.

It’s ethical leadership.

Stepping Back Is Not Stepping Away

Not pushing code does not mean I stepped away from technology.

I’m deeply involved.

I stay curious.

I attend meetups and conferences.

I follow architectural conversations closely.

I experiment with new technologies in my own time.

I still write code, not because I have to, but because I want to understand what’s changing and why. And it’s fun!!!

That curiosity sharpens my judgment.

It allows me to catch nuances in technical discussions.

To recognize weak assumptions.

To ask questions that influence direction.

And to make decisions with confidence when trade-offs matter.

My involvement didn’t disappear, it changed shape.

From execution to sense-making.

From ownership to enablement.

From control to responsibility.

Why This Matters, And Why I Wrote About It

This is exactly why I dedicated a chapter in my book to raising engineers and engineering leaders who can:

❤️‍🔥 map technical needs to business outcomes

❤️‍🔥 understand different types of business value

❤️‍🔥 ask strong, precise questions

❤️‍🔥 communicate technical decisions clearly and responsibly

Not to dilute technical depth, but to strengthen it through clarity, context, and shared understanding.

Because the leaders who make the greatest impact are rarely the ones building everything themselves.

They are the ones creating the conditions for others to build the right things, well, sustainably, and at scale.

A Final Thought

If leadership that empowers gets labeled as “non-technical,”

then the problem isn’t the leader.

It’s the definition.

And I hope we’re ready to evolve it.