Can You Lead Engineers Without Knowing Their Tech Stack?
Following up on the LinkedIn post that reached 110K+ impressions.
Last week, I shared a LinkedIn post about leading engineering teams without having hands-on experience in their tech stack.
I expected some debate.
I didn’t expect over 110,000 impressions, hundreds of comments, and dozens of private messages from Engineering Leaders around the world.
What surprised me wasn’t that people agreed or disagreed.
It was how many admitted, privately, that they were living this exact reality.
Some were leading .NET teams after spending their careers in Java.
Others had moved into AI, Data Engineering, or Mobile without ever writing production code in those domains.
And almost every message carried the same emotion.
Not curiosity.
Not excitement.
Fear.
“What if they realize I’m not technical enough?”
That question resonated.
Because a few years ago, I was asking myself the very same thing.
I thought I had to prove I belonged
The first time this really hit me was about five years ago.
I was asked to lead an Android team.
Up until that point, my entire career had been built around Java and web apps. I had never developed Android applications professionally.
The moment I accepted the role, I felt a responsibility to prove I deserved it.
So I did what I thought a good Engineering Manager should do.
I spent evenings reading Android documentation.
Weekends watching conference talks.
I tried to understand every architectural decision, every framework, every library the team was using.
At the time, I was leading only a handful of engineers, so it felt achievable.
I genuinely wanted to contribute as much as I could.
And if I’m honest...
Part of me believed that the more technical I became, the more credible I would be as their leader.
And I thought it worked… for those 5-6 months I was responsible for that team.
But a few years later, it happened again.
This time with a .NET team.
My first instinct was exactly the same.
Open the documentation.
Buy another course.
Learn the framework.
Catch up as quickly as possible.
Then, halfway through that journey, I stopped.
This time, I asked myself a simple question.
“What exactly am I trying to achieve, here? I know how this goes...”
Even if I spent every evening learning .NET, I would never catch engineers who had spent ten years building production systems with it.
And honestly...
Why was I trying to?
That was the moment I realized I had been playing the wrong game all along.
Instead of becoming a better Engineering Manager, I was trying to become another senior engineer.
Those are two very different jobs.
So this time, I chose a different path.
Focusing on the right question
Looking back, I don’t think my biggest challenge was leading technologies I didn’t know.
It was managing my own insecurity.
I wasn’t learning .NET because the team needed me to.
I was learning it because I needed to feel worthy of leading them.
That’s an important distinction.
Emotional Intelligence isn’t just about understanding other people.
Sometimes it’s about recognizing the stories we keep telling ourselves.
Mine sounded something like this:
“A good Engineering Manager should always have the answers.”
The problem with that belief is that it quietly changes your behavior.
You stop asking questions because you’re afraid they’ll expose what you don’t know.
You speak sooner than you should.
You challenge decisions just to prove you’re engaged.
You spend your energy trying to look technical instead of trying to understand.
Ironically, the more I tried to protect my credibility, the less effective I became as a leader.
Everything changed when I gave myself permission to stop pretending that my value came from being the smartest engineer in the room.
Because it didn’t.
My value came from something entirely different.
Helping smart engineers make better decisions.
Creating an environment where people challenged each other respectfully.
Removing obstacles.
Connecting technical decisions to business outcomes.
Helping people grow.
Making sure the team stayed aligned when the pressure increased.
None of those things required me to write the best .NET code.
They required something much harder.
The confidence to admit what I didn’t know... and the curiosity to ask better questions.
So what did I actually do Instead?
When I joined my .NET team, I made a conscious decision.
I wasn’t going to compete with my engineers on technical depth.
Instead, I focused on creating an environment where their expertise could actually flourish.
I stopped asking questions to test people.
I started asking questions to understand.
Instead of asking:
“Why didn’t you use this framework?”
I’d ask:
“What options did you consider, and what trade-offs led you to this decision?”
I wasn’t looking for the “correct” technical answer.
I was looking for the quality of the thinking behind it.
Because that’s what ultimately matters.
As a leader, I’m rarely making the architectural decision myself.
But I am responsible for making sure the team is making good architectural decisions.
There’s a big difference.
I also stopped feeling uncomfortable when someone knew more than I did.
In fact, I started seeing it as a requirement.
If my Senior Engineers don’t know more than me in their domain, then something is probably wrong.
My job isn’t to replace them.
It’s to create the conditions where they can do their best work.
That means understanding who should be involved in a decision.
Making sure different perspectives are heard.
Recognizing when someone is defending an idea because it’s technically better... or simply because it’s their idea.
Helping the team separate facts from opinions.
Keeping discussions focused on the problem we’re trying to solve instead of the technology people are emotionally attached to.
Most engineering decisions don’t fail because people lack technical knowledge.
They fail because of poor communication.
Unclear ownership.
Egos.
Fear of challenging each other.
Misaligned incentives.
Or simply because nobody asked the uncomfortable question.
And that’s where I believe Emotional Intelligence becomes a technical advantage.
Not because it replaces technical excellence.
But because it allows technical excellence to emerge.
Don’t misunderstand me
None of this means technical knowledge isn’t important.
It is.
If you’re leading engineering teams, you need enough technical understanding to ask good questions, recognize weak reasoning, and follow architectural discussions.
You can’t lead effectively if every technical conversation sounds like a foreign language.
But there’s a huge difference between understanding enough to lead...
...and believing you must become the strongest engineer on the team before you deserve to.
I think that’s where many Engineering Managers get stuck.
Especially those transitioning from Senior Engineer or Tech Lead.
For years, their identity was built around having the answers.
Being the person everyone turned to.
Solving the hardest technical problems.
Leadership quietly changes the rules.
Suddenly, your value is no longer measured by the quality of the code you write.
It’s measured by the quality of the environment you create.
How well your team collaborates.
How quickly people grow.
How effectively decisions are made.
How safe people feel challenging each other.
How often your team succeeds without depending on you.
That’s a very uncomfortable transition.
Because unlike writing code...
...you don’t get immediate feedback.
You don’t ship a pull request.
You don’t see a green checkmark.
You simply watch other people succeed.
And if your identity is still tied to being the smartest engineer in the room...
That can feel surprisingly empty.
The leadership test I use today
Today, I ask myself a very different question.
Not:
“Did I have all the answers?”
But:
“Did my team make better decisions because I was in the room?”
Sometimes the answer is yes because I challenged an assumption.
Sometimes because I asked a question nobody else asked.
Sometimes because I helped two engineers understand each other.
Sometimes because I decided not to speak at all.
Ironically, the less I tried to prove my technical value...
The more trust I earned.
Not because my engineers suddenly thought I knew everything.
But because they knew I was there to help them think better… not to compete with them.
And looking back...
That’s probably the biggest lesson those Android and .NET teams taught me.
Leadership isn’t about becoming the smartest engineer in the room.
It’s about making the room smarter.
P.S. Here’s the link to my viral post. :)