What I Had to Get Good at to Run an Engineering Team

Nobody really taught me how to run an engineering team. I was thrown into my first management role years ago without much of a playbook for what the job actually required.

That’s not to say I haven’t had training. I’ve been through countless leadership trainings focused on feedback, performance, coaching, and difficult conversations. The basic “here’s how to be a good leader or manager” stuff. But I’ve had very little training on engineering management. How do you actually run an engineering team? Most of that I’ve had to learn by doing it. I’ve also had some great mentors along the way who helped me figure out parts of the job.

I certainly don’t have it all figured out. I still learn new things every day and make plenty of mistakes along the way. But over the years, I’ve developed a much clearer picture of the skills required to run engineering teams.

One note before I get into them: I’m using “engineering management” broadly. It looks different across companies and levels, and many of these responsibilities can and should overlap with other roles. This isn’t a map of who owns what. These are simply the skills I’ve found valuable for running engineering teams.

Here’s what I’ve learned so far.

Understand the Problem

Know the problem your team is solving deeply. That means understanding the customer, business, product, and technical context. You need enough technical depth to challenge assumptions, understand tradeoffs, spot risks, and have an informed opinion. You don’t need to be the deepest expert in every area, but you do need to connect them.

I try to be the SME on the problem, not necessarily the implementation.

When you understand the problem deeply, you can give the team more than a list of things to build. You can explain why it matters, where you’re going, and how the work connects to it. That creates a shared vision and helps the team actually buy into what they’re building.

You can’t get there from requirements and meetings alone. Use the product. Understand the people using it. Stay close enough to the implementation to understand the realities of delivering it.

The problem should be clear before the solution enters the conversation. That gives the team room to understand it, challenge it, and ultimately own how it gets solved.

Turn Intent Into Something Shippable

A lot of engineering work starts as an idea, a desired outcome, or a problem that’s much bigger than something a team can simply go build.

One of the most useful skills I’ve developed is turning that ambiguity into shippable increments that everyone can understand. I’m not talking about tickets or task breakdowns. I’m talking about: What behaviors will actually ship? In what order? What does each increment enable?

Getting this right creates shared understanding across everyone involved. That might include engineering, product, sales, stakeholders, or other teams. Everyone can talk about the same thing, make tradeoffs against the same thing, and understand what progress actually means.

This doesn’t mean figuring it all out for the team. The team should be heavily involved in shaping how we get there. The goal is to turn the intent into something concrete enough that everyone understands where we’re going and can move on it.

If we can’t clearly describe what we’re going to ship next and what it enables, we’re probably not ready to build it.

Own the Outcome

It’s easy to become a pass-through manager. Someone asks a question, you ask the team, then carry the answer back. A decision gets made somewhere else, and you relay it to the team. Before long, you’re a human message bus.

I’ve learned that I need to own the message. I should understand it, believe in it, and be able to add the context and judgment necessary to represent it well. The same applies in the other direction. I should know what we’ve shipped, what’s next, where we’re struggling, and what might get in the way without asking the team every time someone has a question.

But knowing what’s happening isn’t the outcome. Shipping isn’t the outcome either. Did what we build actually work? Did it solve the problem we started with? What did we learn?

The goal isn’t to be the person with all the information. It’s to take ownership of whether the work actually produces value.

Make Decisions Without Certainty

Engineering management is full of decisions where you don’t have all the information. Requirements are incomplete, estimates are uncertain, technical unknowns exist, and you don’t know exactly how customers or systems will respond.

Waiting for 100% confidence isn’t an option. At some point, you have to make a call.

I’ve had to get better at understanding how much confidence is enough. I try to answer three things:

1. What do I know?
2. What am I uncertain about?
3. What happens if I’m wrong?

That last question matters a lot. If a decision is easy to reverse and the downside is small, I can move with relatively low confidence and learn. If it’s expensive, difficult to reverse, or creates significant risk, I should demand more confidence before committing.

That’s where the metaphor clicks: you don’t need to see the entire path, just enough to know the next move.

Then there’s time. More information usually has a cost. Another week of research might increase confidence, but is that increase actually worth waiting a week? Sometimes the right decision is to move while explicitly accepting what you don’t know.

Good judgment isn’t having all the answers. It’s knowing when you have enough to move forward, when you don’t, and being clear about the uncertainty and risk you’re accepting.

Build a Dependable Team

Teams need to ship quality work, and they need to deliver when they say they will. That matters. But engineering is full of uncertainty. Plans change, unknowns surface, and sometimes the original commitment stops being realistic. Pretending otherwise doesn’t make a team more dependable.

I’ve learned to think about dependability as a combination of delivery and transparency. Make realistic commitments and do everything you can to meet them, while constantly asking: Are we still confident in what we committed to?

When the answer changes, act on it. Don’t just report that something is at risk. Ask: What changed? What does it affect? What options do we have? Maybe we reduce scope, move the date, change the approach, or knowingly accept more risk. Reset expectations while there’s still time for those choices to matter.

The whole team should be able to do this. I don’t want to be the only person who knows we’re in trouble. Engineers should be comfortable saying, “I’m no longer confident in this because of X,” so we can have that conversation early and decide what to do about it.

Dependability isn’t perfection. It’s making commitments that mean something, delivering on them consistently, and managing reality when things change.

Be Dependable Without Being Depended Upon

It’s easy to become a bottleneck as an engineering manager. You have the context, relationships, and authority to answer questions, make decisions, or resolve issues yourself. Do that often enough and the team starts to depend on you to keep things moving.

I’ve learned to ask: Does this actually require me? Sometimes it does. Other times, stepping in takes away an opportunity for someone else to build context, judgment, and ownership.

I typically manage several teams at once, all with very different needs, experience, and makeup. Some hardly need my involvement, while others need me in almost everything. Teams have different levels of maturity, experience, and time together, so that’s not necessarily a problem. The problem is when that dependency never decreases.

A useful test is: What stops working when you’re gone for two weeks? If decisions stop, communication breaks down, or the team can’t navigate ambiguity without you, it’s worth asking whether your involvement is actually necessary or has simply become how things get done.

The goal isn’t to make yourself unnecessary. It’s to build ownership that extends beyond you. Give the team what it needs today while continually building its ability to make decisions, navigate ambiguity, and keep moving without you in the middle of everything.

Still Learning

I wish I had understood these things when I first became a manager. Instead, I learned them slowly by running teams, making mistakes, watching great leaders, and figuring out what worked and what didn’t.

I’m sure this list will evolve. There are things on it today that I understood very differently five years ago, and I expect I’ll say the same five years from now. There isn’t a single playbook. Teams are different, problems are different, and what they need from you changes over time.