Modern engineering leadership

I’ve been thinking a lot lately about what it means to be an engineering leader right now. Not in a doom-and-gloom, “AI is coming for our jobs” way, but in the quieter, more uncomfortable sense of realizing that some of the things we anchored our careers to are shifting under our feet.

There’s a lot of noise about tools writing code for us. Copilots, agents, prompts, whatever the next thing is going to be by the time this gets published. The tooling is new, but the feeling is not. What’s becoming clear to me is that this shift isn’t really changing what teams need from engineering leaders. It’s just making the gaps more visible.

If I’m being honest, coding was never the hardest part of software development. It was just the most visible one. The hard parts were always human. Deciding what not to build. Explaining tradeoffs. Getting alignment. Helping someone grow without crushing their confidence. Shipping something imperfect and standing behind it. Code was just how we expressed all of that. AI doesn’t remove these challenges, it makes them harder to ignore.

When craft becomes identity

One of my engineers told me recently that he was hesitant to lean too heavily on AI-assisted tooling. Not because it didn’t work, but because it worked really well. He was worried about losing his craft. Worried that the instincts he built over years of debugging, rewriting, and shipping would dull. Worried about skill atrophy in the thing he built his career on.

This wasn’t someone afraid of learning. It was someone afraid of losing a part of himself. I don’t think that fear is irrational at all.

For a lot of engineers, our value was tied directly to what we could produce with our own hands and brains. We learned through repetition and failure. We earned fluency the hard way. When a tool shows up that can do parts of that work instantly, it forces an uncomfortable question: if this is easier now, what does that say about what I’m good at?

That conversation stuck with me because it wasn’t really about tools. It was about trust. Trust that experience still matters. Trust that judgment still counts. Trust that we’re not erasing the past ten years every time we accept a suggestion from a machine.

Coding was never the bottleneck

Here’s the part I keep coming back to: the code was never the bottleneck. It just felt like one because it was slow and manual.

What actually slowed teams down was poor decision-making. Unclear ownership. Missing context. Optimizing the wrong thing. AI doesn’t solve any of that. In some cases, it makes it worse because bad decisions get implemented faster.

I was taught that the idea of a “10x engineer” at the leadership level was about creating an environment of mentorship, guidance, and autonomy. Hire smart people, get out of their way, support them when they need it. I still believe that.

What I didn’t expect is how much time I now spend establishing shared approaches to tooling and workflows. Not because I want control, but because without some guardrails, everything turns into noise. Reviews get harder. Knowledge stops flowing. Growth becomes uneven. That shift took me a while to accept.

Alignment is the new leverage

It doesn’t sound glamorous to say that part of my job is making sure we’re using tools consistently. It sounds like process. But in an AI-assisted world, alignment is where the leverage lives.

When everyone uses tools differently, outcomes vary wildly. Expectations drift. Quality becomes subjective. Consistency isn’t about stifling creativity. It’s about reducing cognitive load so people can spend their energy where it actually matters.

In that sense, tooling decisions are a form of mentorship at scale. They communicate what we value. They set expectations. They help newer engineers learn how to think about problems, not just how to solve them. This is where I think engineering leaders who feel disoriented right now might want to focus.

Decision quality over code quality

When code is cheap, decisions are expensive. If AI can generate something that compiles in seconds, the real question becomes whether we should be building it at all. Or building it this way. Or building it right now.

As a leader, I’m spending less time nitpicking implementations and more time asking why we’re choosing one path over another. Teaching teams how to recognize irreversible decisions. Encouraging them to slow down when something has long-term impact. Making it clear that “working” is not the same as “correct.”

Context as a first-class skill

AI has no memory of your organization. Your team does. It doesn’t know why a decision was made three years ago. It doesn’t understand customer pain that never made it into a ticket. It doesn’t feel the political or operational constraints that shape real-world software.

Helping engineers build and share context is more important than ever. Writing down the why, not just the how. Telling the story of how things got here. Pairing engineers closer to product and design earlier than feels comfortable. Context is what turns generated code into good software.

Redefining growth without erasing the past

There’s a lot of quiet anxiety around career progression right now. If writing harder or more complex code isn’t the obvious path forward anymore, what is? I don’t have a perfect answer, but I’ve been explicit that growth now looks like better judgment, clearer communication, stronger ownership, and knowing when not to automate. Seniority shows up in the questions you ask, not just the output you produce. That doesn’t invalidate the craft people worked hard to build. It builds on it.

So what’s the job now?

I don’t think engineering leadership has become easier. I think it’s become more exposed. When tools remove friction, what’s left is intention. Teams still need help forming that intention together. They still need mentorship, guidance, and trust. The shape of that work is just changing.

Lately I’ve been orienting my teams less around output and more around clarity. Clear goals, clear constraints, clear ownership, and shared context. The better we get at those things, the more leverage the tools actually give us.

I’m still figuring this out. Some days it feels like I’m letting go of things I used to be really good at. Other days it feels like I’m finally seeing the job for what it always was. The code changed, but the people didn’t. That’s still the job.