how i lead engineering organizations

01Understand before you act

I ask a lot of questions. Sometimes more than people expect.

That's how I understand complicated systems, whether we're talking about software architecture, organizational structure, delivery processes, or team dynamics.

Slow delivery can mean unclear requirements, technical complexity, too many handoffs, or friction between teams. Burnout might be about deadlines, conflict, scope churn, or some combination of those things.

The solution depends on the cause.

I'd rather spend time understanding a problem than confidently solving the wrong one.

02Make the tradeoffs explicit

Engineering doesn't operate separately from the business.

Sometimes the business genuinely needs us to move faster. My job isn't to reflexively say no, and it isn't to quietly turn that request into a death march.

If we need more speed, what changes? Scope, quality, capacity, sequencing, or risk? If we hire more people, how long before that capacity becomes useful? If we change our process, what problem are we actually trying to solve?

Engineering capacity is an investment, and I want to understand what the business expects in return. Sometimes the right decision is to stabilize a platform, sometimes it's to prioritize new functionality, and sometimes it's to stop an experiment that hasn't demonstrated enough value to justify continuing. I don't believe every technical investment needs an immediate financial return, but we should understand what we're trying to accomplish, what we're willing to spend, and what would cause us to reconsider.

Every week spent on one thing is a week not spent on something else. I'm willing to put off work engineers would love to do when something else matters more to the business right now. When we take on technical debt, it should be a decision someone made out loud, not something we discover later.

When we try something new, including changing how we build software with AI, I want to know what would tell us it isn't working. An experiment can teach us a lot and still not be worth continuing, and I try not to confuse learning something with building something the business needs. Some risks aren't ours to trade at all: security, compliance, and regulatory obligations limit what the business can accept, however attractive the deadline.

I want the business and engineering to understand what they're choosing, including the consequences. Then we can make a decision together and own it.

03Step in when it matters

I believe strongly in ownership.

If a production system is on fire, I'm not going to watch from the sidelines. I'll be there asking questions, helping diagnose the problem, and doing what I can to get things under control.

If something important has no clear owner, I'm not comfortable watching it fall through the cracks. I'll step in.

But taking ownership in the moment shouldn't mean becoming the permanent owner. Once the immediate problem is resolved, we need to understand how the gap happened and make ownership clear.

I step in when clarity or risk demands it, and then I make sure the system doesn't depend on me next time.

04Seniority should create leverage

I don't want the most experienced engineer on a team spending their days cleaning up everyone else's work.

That's an expensive janitor.

A strong senior engineer raises the quality of the people around them. They coach, explain why something matters, offer useful feedback, and help others develop judgment. They learn to give away the Lego blocks.

I see leadership the same way. My job isn't to make myself indispensable.

05Build an organization that can make decisions

I believe an Engineering Manager is responsible for people, process, and outcomes, in that order. That isn't because outcomes matter less; capable people working in a healthy system are what produce results that last. The goal isn't to create managers who have all the answers. It's to develop people who can think through difficult problems, make sound decisions, and take ownership without constantly looking upward for permission.

Some good managers still write code and some rarely do. What I care about is whether the people around them are growing, and that usually means teaching them how to weigh alternatives and risks rather than handing them the answer.

That philosophy extends to how I think about organizational design. Teams should have clear responsibilities and meaningful authority over the systems they own, with decisions made as close to the work as practical and escalated when they affect other teams or carry real risk. I prefer lightweight processes that help people make decisions rather than committees that require everyone to agree. Sometimes that means an architectural decision record with a clear owner and the right reviewers, sometimes it means involving the right subject matter expert, and sometimes it means recognizing that the organization itself needs to change.

Consulting people isn't the same as needing everyone's agreement. The exception is risk that belongs to someone else: security and compliance should have real authority within their domains, not just a seat at the table.

06Hold a high bar without forgetting the human

An engineering organization is a team, not a family.

I care about the people I lead. When someone is struggling, I want to understand why. I'll work with them to identify the issue, give clear feedback, and establish a measurable path to improve.

But empathy doesn't mean avoiding accountability.

When coaching isn't enough, expectations and consequences need to be clear. Sometimes that means a formal improvement plan; sometimes it ultimately means making a difficult personnel decision.

Avoiding that responsibility isn't fair to the person who's struggling, or to the rest of the team.

07Own your decisions

I'm going to make mistakes. Every leader does.

When I get something wrong, I want to own it publicly, explain what we're going to do to fix it, make the correction, and recognize the people who helped put things right.

Owning a decision also means being honest about what kind of failure it was. Sometimes I made a poor call. Sometimes the call was reasonable and the outcome still went against us, or the engineering was solid and the business bet didn't pay off. Those deserve different responses, and none of them is a reason to hold up an engineer as the cause. I'll explain the business impact to the people above me, the team's manager will lead the fix, and the engineers closest to the problem will help us understand what happened. The postmortem is for learning, not for finding someone to blame.

Credibility doesn't come from pretending to be right all the time. It comes from being accountable when you're not.

08Know when to get out of the way

When a team is healthy, delivery is predictable, people trust each other, and decisions are being made effectively, I don't need to be at the center of everything.

I fade into the background.

I'll stay close enough to see emerging friction, coordinate when needed, and be there when something requires my attention. But the team should be able to operate on its own rhythm.

My job isn't to be the hero. It's to create the conditions where the team can succeed without me.