What engineering management actually is (and isn't)

After a 3.5-year break, the Ladybug Podcast is back for its seventh season! Emma and I didn’t return lightly. We dedicated the entire season to engineering management because too many engineers step into the role without realizing what the job actually is, and what it isn’t.

I'm going to share the key takeaways from each episode here. Let me know if this is helpful or if you prefer this as a bonus email (or not at all). You won't hurt my feelings too much :)

Management vs. leadership

Management is the logistics of shipping—deadlines, dependencies, delivery. Leadership is influence. It’s how you show up, how you earn trust, how you handle conflict.

Mix them up and you either bury yourself in Jira tickets or spend all your time talking about vision without delivering anything. Some of the strongest leaders I know are senior ICs. They don’t manage anyone, but their impact is obvious. The difference is they lead through expertise and mentorship, not through authority.

Make yourself redundant

Emma put it well in our first episode: “If I’ve made myself redundant, I’ve done my job.”

It doesn’t mean you’re useless. It means you’ve built a team that can prioritize, decide, and move forward without you in the middle.

Progress shows up when work ships without you. The team knows the priorities, makes the calls, and pushes things forward. That’s ownership, and it’s the real measure of success as a manager.

If you’re still jumping in on every decision or solving every problem, you’re not managing. You’re slowing everyone down.

Staying technical without becoming the bottleneck

You need enough technical depth to stay credible, but not so much that you become a blocker. I’ll still jump into debugging or help untangle an API issue, but I don’t take on critical-path work anymore. My role is to keep people unblocked, not to own the implementation.

ADHD means I forget a lot of what I absorb, so I keep notes on project status, blockers, and dependencies. They help me stay oriented, and the team uses them too. What matters isn’t remembering every detail. It’s staying curious and being honest when you don’t know something.

Managing former peers

This is one of the hardest transitions. Boundaries matter. Friendships can continue, but not at the expense of judgment.

At some point you will need to give sharp feedback or part ways with someone you like. It feels uncomfortable every time, and it should. If it ever feels easy, you’re probably avoiding something you shouldn’t.

Surprise, you’re also the project manager

When you don’t have project managers, the role falls on you. Capacity planning, dependencies, escalations, customer commitments—yep, all of it lands on your desk.

By week six of the quarter, most of the plan has already shifted. That’s why I lean toward shorter cycles. They’re easier to deliver honestly and harder to pretend about.

My hot take on team leads

Team lead works as a stepping stone but not as a permanent role. You end up half IC and half manager, which usually means neither job gets done well. Eventually you need to pick a lane.

What to read

📚 The Making of a Manager – the book I recommend most often to new EMs. Practical and approachable.
📚 Crucial Conversations – the best toolkit I’ve found for conflict. It helped me at work and at home.

Try this

Pull up your calendar from the past two weeks. Add up how much time was spent coding and how much was spent managing.

If you’re still taking on critical-path work, that’s a problem. Your team needs you focused on people, process, and direction. If you stay buried in the code, you’re not managing—you’re just acting like a busier IC.

Listen to the full episode: A Brief Introduction to Engineering Management