Leading What I Haven't Lived

The Uncomfortable Reality of Leading People Who Know More Than You

There's something incredibly humbling about walking into a room full of brilliant software engineers and realizing you're probably the least technically proficient person sitting at the table.

Especially when you're the manager.

I've spent the last several years of my career managing software engineers across varying degrees of experience, from associates just beginning their professional journeys to senior engineers who have spent years mastering their craft.

And if I've learned anything, it's that managing engineers is an entirely different challenge than simply managing people.

Not because engineers are inherently more difficult to lead, but because the nature of their work requires a depth of technical understanding that I didn't develop through the traditional path of being a software developer.

I'm not a developer by trade.

I've dabbled in software development over the years, primarily on the front end. I understand enough to follow many technical conversations, appreciate the architecture behind an application, ask questions, and occasionally fill in gaps when necessary.

But I also recognize something incredibly important.

Knowing how something works is not the same as having spent years being responsible for making it work.

There's a depth of understanding that comes from writing code every day, troubleshooting seemingly impossible defects, navigating technical debt, maintaining aging systems, and making architectural decisions that will affect applications long after you've moved on to something else.

You can't replicate those experiences by reading documentation, taking a few courses, or spending your evenings building personal projects.

Those things matter. They've certainly helped me become a better partner to the engineers I serve.

But they aren't replacements for experience.

And one of the first things I had to become comfortable with was acknowledging that reality without allowing it to undermine my confidence as a leader.

Because while I may not know everything my engineers know, I bring something different to the table.

And learning to recognize the value of that difference has been one of the most important lessons of my career.

The Learning Curve Nobody Really Prepares You For

One of the things I've found fascinating about engineering management is how dramatically the needs of the people you lead can differ.

Consider an associate software engineer.

They're often navigating an entirely new world.

They're learning how to work within an established codebase, understanding development practices, becoming familiar with organizational expectations, and discovering how the theoretical concepts they learned translate into production environments.

For some, it's their first experience working within a large organization.

For others, it's the first time they've encountered a problem that doesn't have a clearly defined solution.

They need guidance, patience, feedback, reassurance, and opportunities to make mistakes without feeling that every mistake is a reflection of their potential.

Now consider a senior engineer.

Their challenges can look completely different.

They may be navigating complicated architectural decisions, balancing long-term maintainability against immediate business needs, mentoring less experienced colleagues, or learning how to influence technical direction without having formal authority.

They might understand the technology better than almost everyone around them, yet struggle with communicating that understanding to people who don't share their expertise.

They may need fewer answers and more opportunities.

Less direction and more autonomy.

And sometimes, they need someone willing to challenge them in ways that have absolutely nothing to do with writing better code.

Now imagine trying to support both of those individuals, along with everyone who falls somewhere between them.

That's the challenge.

There isn't a universal approach to developing people, because people aren't universal.

What motivates one person might frustrate another.

The guidance that helps an associate engineer build confidence might feel restrictive to someone with years of experience.

The freedom that allows a senior engineer to thrive might leave someone earlier in their career feeling unsupported.

I've had to learn how to recognize those differences, sometimes through observation, sometimes through conversation, and occasionally through getting it wrong.

And I think that last part is worth acknowledging.

I've made mistakes.

There have been times when I should have asked a better question.

Times when I didn't understand a technical problem as quickly as I wanted to.

Times when I had to go away, educate myself, and return to a conversation with a better understanding of what someone was trying to explain.

That's uncomfortable when you're accustomed to being the person others turn to for guidance.

But I've come to appreciate that discomfort.

It reminds me that leadership doesn't exempt me from learning.

In fact, the moment I stop learning is probably the moment I stop being the leader my team deserves.

Technical Credibility and Leadership Credibility Aren't the Same Thing

I think there's an interesting misconception surrounding engineering leadership.

Some people believe that the most effective engineering manager must first have been an exceptional software engineer.

I understand that perspective.

There's tremendous value in having a leader who has firsthand experience with the problems their team encounters.

Someone who has lived through difficult deployments, managed complex systems, and understands the nuances of software development because they've spent years doing it.

That experience provides context and credibility.

I would never dismiss its importance.

But I've also come to believe that being an exceptional engineer and being an exceptional engineering manager require overlapping, yet fundamentally different, capabilities.

One is largely about applying technical expertise to solve complex problems.

The other is about creating the conditions in which people with technical expertise can consistently solve complex problems together.

Of course, engineering managers still need sufficient technical understanding to evaluate risks, participate in meaningful conversations, recognize trade-offs, and connect engineering decisions to business outcomes.

Technical ignorance isn't a leadership strategy.

But neither is pretending to possess expertise you haven't earned.

I've never wanted my engineers to believe I'm the smartest technical person in the room.

In fact, if I consistently were, I'd probably be concerned that I wasn't surrounding myself with enough people who could challenge my thinking.

What I want them to know is that I'm going to listen.

I'm going to ask questions.

I'm going to challenge assumptions when something doesn't make sense.

I'm going to advocate for them when they need support, and I'm going to hold them accountable when they need to grow.

And when I don't understand something, I'm going to say so.

Not because I'm uninterested in learning, but because pretending to know something I don't would be a disservice to everyone involved.

I don't need to be better at their jobs than they are. I need to become exceptionally good at helping them succeed in those jobs.

That's a responsibility I take seriously.

The Most Valuable Thing My Teams Have Given Me

Trust.

It's such a simple word, yet I don't think we always appreciate how much weight it carries.

When someone joins a team or begins reporting to a new manager, they're placing a remarkable amount of trust in another person.

Not just trust that they'll receive reasonable assignments, fair evaluations, or a paycheck.

They're trusting someone with a portion of their professional future.

Think about that.

They're trusting that you'll recognize their contributions.

That you'll provide honest feedback.

That you'll advocate for them when opportunities arise.

That you'll help them navigate difficult situations.

That you'll see their potential even when they haven't quite figured out how to demonstrate it.

And in many cases, they're trusting that you'll help them move closer to the life they're trying to build outside of work.

Because careers don't exist independently of people's lives.

That promotion someone is working toward might mean being able to purchase their first home.

That salary increase might provide some breathing room for a family that's been struggling.

That opportunity to take on greater responsibility might be the confidence someone needs to finally believe they're capable of more than they've allowed themselves to imagine.

Those things matter.

And I don't take lightly the fact that people have trusted me to play a role in those journeys.

Particularly when some of those individuals possess technical knowledge and abilities that far exceed my own.

There's something genuinely remarkable about that.

They understand the technology better than I do, yet they trust me to help guide their professional development.

They trust my judgment.

My experience.

My willingness to advocate for them.

My ability to recognize what they might need to reach the next stage of their careers.

I find that incredibly humbling.

And I'm deeply appreciative of every individual who has extended that trust to me.

Because trust isn't something a title automatically provides.

Authority might give someone a reason to listen to you. Trust gives them a reason to believe in you.

Those are very different things.

The One Thing I Know I'm Good At

For all the uncertainty I've experienced while developing my technical knowledge, there's one area of leadership where I've rarely questioned my ability.

Helping people grow.

I know how to connect with people.

I know how to listen beyond the words they're saying.

I know how to recognize when someone's confidence hasn't caught up with their capability.

And I know how to help people begin closing the distance between where they are and where they want to be.

It's something I've spent much of my career doing, long before I ever managed a team of software engineers.

I've always been fascinated by human potential.

Not just what people can do today, but what they might become with the right opportunities, challenges, support, and environment.

I don't believe talent always announces itself.

Sometimes the person with the greatest potential is the quietest person in the room.

Sometimes the individual struggling with confidence is capable of extraordinary things but hasn't yet experienced the success necessary to recognize it.

Sometimes a person who appears to be underperforming isn't lacking ability at all.

They may simply be operating within a system that doesn't allow their strengths to emerge.

And sometimes, people need to be challenged because they've become so comfortable with what they're already good at that they've stopped exploring what else they might be capable of.

Those situations require more than a career development template or a standardized performance conversation.

They require getting to know people.

Understanding what motivates them.

Learning what they value.

Recognizing what they fear.

And being willing to have difficult conversations with them because their growth matters more than whether they always enjoy what you're telling them.

I believe in people, but I also believe in holding them accountable to the potential I see in them.

That doesn't mean imposing my ambitions on their lives.

Their aspirations belong to them.

Some want to become principal engineers.

Some want to move into leadership.

Some want to deepen their technical expertise without ever managing another person.

Others are still figuring out what they want, and that's perfectly fine.

My responsibility isn't to decide where they should go.

It's to help them understand their options, recognize their capabilities, identify the gaps, and move intentionally toward the future they've chosen.

And when they get there?

I want them to recognize that they earned it.

Not because I gave them something.

But because we worked together to create the conditions in which they could become ready for it.

Trust the Process Doesn't Mean Trust Me Blindly

There's something I often come back to when thinking about professional development.

Trust the process.

I know. It's a phrase that's probably been repeated so frequently that it's begun to lose its meaning.

But I believe in it.

Not as an empty promise that everything will eventually work out.

Not as an excuse to keep someone waiting indefinitely for an opportunity they deserve.

And certainly not as a way of asking people to place blind faith in a manager's judgment.

To me, trusting the process means recognizing that meaningful growth takes time, intentional effort, honest feedback, and a willingness to work through uncomfortable moments.

There will be setbacks.

There will be disappointing conversations.

There will be opportunities someone wants but isn't quite ready for.

There may even be situations where someone is ready, but the organization doesn't currently have the opportunity available.

I can't promise that every promotion will happen on a specific timeline.

I can't manufacture organizational opportunities that don't exist.

And I won't tell someone they're ready for something simply because it's what they want to hear.

But here's what I can promise.

I'll be honest with them.

I'll help them understand what success looks like.

I'll work with them to identify the experiences and capabilities they need to develop.

I'll create opportunities for them to demonstrate growth whenever I can.

I'll advocate for their contributions, and I'll make sure they understand where they stand.

And when the path we originally envisioned no longer makes sense, we'll have the courage to reevaluate it.

Trusting the process should never mean surrendering your ability to question the process.

Quite the opposite.

A good development process should become more transparent and more collaborative over time.

I want the people I lead to challenge me.

I want them to tell me when something isn't working.

I want them to feel comfortable saying, "I don't think this is getting me where I want to go."

Because if we're genuinely committed to their development, we should be willing to adjust our approach when the evidence suggests we need to.

And sometimes growth means helping someone find an opportunity beyond the team, or even beyond the organization.

That's not always an easy thing for a manager to accept.

Losing a strong contributor can create real challenges.

But I don't believe people exist to fulfill my staffing needs indefinitely.

They have their own lives, ambitions, and futures.

If I've done my job well, their success shouldn't depend on remaining under my leadership forever.

In fact, I'd argue that helping someone outgrow the opportunities you can provide is one of the greatest compliments a leader can receive.

Leadership Is a Responsibility, Not a Competition

One of the most liberating realizations I've had as an engineering manager is that I don't have to compete with the people I lead.

I don't have to understand every technology more deeply than they do.

I don't have to be the first person to propose a solution.

I don't have to demonstrate my value by inserting myself into every technical decision.

And I certainly don't need to be the person who receives the recognition when something goes well.

My value comes from something different.

It comes from helping the team recognize problems worth solving.

From removing obstacles that make meaningful work unnecessarily difficult.

From connecting individuals whose strengths complement one another.

From protecting the space people need to concentrate, experiment, collaborate, and learn.

From asking whether the way we're working is actually producing the outcomes we're trying to achieve.

And, perhaps most importantly, from recognizing that the people doing the work deserve both the ownership and the recognition that come with it.

I want engineers to feel proud of what they accomplish.

I want them to own their decisions.

I want them to challenge existing practices, discover better ways of solving problems, and develop the confidence to make increasingly difficult decisions without needing someone to reassure them at every step.

That's what empowerment should look like.

Not abandoning people in the name of autonomy.

Not micromanaging them in the name of accountability.

But providing the right balance of support, context, challenge, and freedom as their capabilities evolve.

The best leaders I've encountered understood that their role wasn't to make themselves indispensable.

It was to help other people become increasingly capable.

That's the kind of leader I aspire to be.

I'm Still Learning. I Hope I Always Will Be.

I sometimes wonder what the engineers I work with think when I ask a question about something they probably consider elementary.

Maybe they're surprised I don't already know the answer.

Maybe they appreciate the curiosity.

Maybe it depends on the day.

But I hope one thing is always apparent.

I'm trying.

I'm genuinely interested in understanding their world, not because I believe I'll eventually become a better engineer than they are, but because I believe understanding their work makes me better equipped to serve them.

Every technical discussion teaches me something.

Every architecture review gives me additional context.

Every conversation about a difficult defect, unexpected dependency, or complicated deployment helps me better appreciate the challenges they navigate.

And every conversation about someone's career reminds me why I chose leadership in the first place.

I didn't pursue engineering management because I believed I was the most technically gifted person in the room.

I pursued leadership because I believed I could help talented people accomplish things they might struggle to accomplish alone.

That belief hasn't changed.

If anything, the last several years have strengthened it.

I've become more aware of what I don't know, but I've also become more confident in what I bring to the table.

I understand that humility and confidence aren't opposing characteristics.

You can be humble enough to admit you don't have every answer while remaining confident in your ability to help people find their own.

You can respect someone's expertise without surrendering your responsibility to lead.

You can learn from the people who report to you without diminishing the value of your own experience.

And you can be proud of your leadership abilities while recognizing that you still have an enormous amount to learn.

The best leaders aren't necessarily the people who have finished learning. They're the people who refuse to believe they ever will.

To the Engineers Who Have Trusted Me

If there's one thing I'd want the engineers I've had the privilege of leading to understand, it's this:

I recognize the responsibility you've placed in my hands.

I recognize the years you've spent developing skills that I may never fully possess.

I recognize the complexity of your work, the frustration that comes with solving difficult problems, and the pride that comes from finally making something work after countless attempts.

I recognize that your careers are more than job titles, performance ratings, and compensation bands.

They're personal.

They're connected to your aspirations, your families, your confidence, and the futures you're trying to build.

And I appreciate the trust you've extended to someone whose professional journey looks different from your own.

I won't always get everything right.

There will be times when I misunderstand something.

Times when I'll need you to explain a technical concept again.

Times when we'll disagree about the best approach.

And times when the path toward your goals will feel longer than either of us hoped.

But I can promise you that your growth matters to me.

Not just because it makes our team stronger or helps our organization succeed.

But because I genuinely want to see you become everything you're capable of becoming.

I want to celebrate the promotions, the milestones, the breakthroughs, and the moments when something that once seemed impossible becomes second nature.

I want to see you develop the confidence to take on opportunities you might once have avoided.

And eventually, I want to see you reach a point where you look back at where you started and realize just how far you've come.

I have a tremendous amount of respect for the work you do.

And while I may not always know exactly how to solve the technical challenges in front of you, I have an unwavering belief in our ability to work through the challenges that stand between you and your aspirations.

It may take time.

It will certainly take effort.

And the path may look different from what we originally imagined.

But we'll keep learning, adjusting, challenging ourselves, and moving forward.

Because if there's one thing I've learned throughout my career, it's that helping people recognize and realize their potential is what I do best.

And I don't intend to stop.

A Final Thought

I think we spend too much time defining leadership by what someone knows and not enough time evaluating what they help others become.

Expertise matters.

Experience matters.

Technical fluency matters.

But so do empathy, curiosity, courage, accountability, and the ability to see possibilities in people that they may not yet see in themselves.

The engineers I lead don't need me to become a carbon copy of them.

They need me to respect their expertise, understand their challenges, advocate for their growth, and create an environment where their abilities can flourish.

And I need them to continue challenging me, teaching me, and trusting that my commitment to their success is genuine.

It's a relationship built on mutual respect rather than identical experience.

I'm still becoming a better engineering manager.

Just as the people I lead are still becoming better engineers, mentors, architects, collaborators, and leaders.

None of us have arrived at some final destination.

We're all works in progress.

And maybe that's the part of leadership I've come to appreciate most.

I don't have to be the person who knows how to do everything. I have to be the person who believes in what we can become, and is willing to do the work necessary to help us get there.

To every engineer who has trusted me with even a small part of their professional journey, thank you.

I'm learning from you just as much as I hope you're learning from me.

And wherever your aspirations take you, I hope you eventually look back and recognize that the trust, effort, difficult conversations, and patience were worth it.

Because my greatest accomplishment as a leader will never be the code we shipped, the applications we built, or the deadlines we met.

It will be the people who went further than they once believed they could.

And if I had even a small part in helping them get there, that's a career I can be proud of.