Before You Can Explain It

When I first became a manager, I thought I knew what performance problems would look like. Clearly they would involve someone yelling in a meeting. Maybe a policy violation. Definitely an obvious technical failure so glaring it couldn’t be ignored. I had a mental catalog of scenarios, and I was confident I’d recognize one when it showed up.

For the most part, that’s just not how it works.

Underperformance rarely arrives as a single event. It usually arrives as a pattern.

Looking back, I don’t think I recognized those patterns by noticing the engineer. I recognized them by noticing how my own behavior shifted.

The first time someone on my team was genuinely struggling, I didn’t have a lightbulb moment where I suddenly knew what was happening. Instead, I found myself asking a quiet question that lingered in the back of my mind.

Is something off here?

In the first moment I consciously had that thought I would have struggled to tell you why. Nothing had exploded. There wasn't a failed release or an angry customer. It was just the growing realization that every project involving this engineer seemed to require a little more attention than the rest.

I was checking in on their projects more often. I hesitated before giving them leadership opportunities that should have been an obvious fit for their level. I found myself mentally building contingency plans before deadlines arrived. Sometimes, without realizing it, I was quietly lowering my expectations just to keep the work moving. None of those decisions felt significant on their own. It was only later that I realized they were all pointing in the same direction.

At the time, I thought I was just being thorough. Looking back, I had already started managing them differently. That's the moment I've learned to pay attention to. Not because it tells me someone is underperforming, but because it tells me I don't yet understand what's happening.

My role in that moment isn't to decide whether they're underperforming. It's to understand why I've started responding differently. That's why I investigate before I coach.

If one person consistently occupies more mental space than everyone else - you’re wondering whether they’ll deliver, building backup plans before you need them, checking in just one more time - that’s worth understanding. Not because they’re guilty of anything, but because you’ve already started adapting around something you haven’t yet explained. If I ignore those signals, I don't avoid the problem. I quietly adapt around it.

Early on I thought performance problems would be obvious. I also assumed someone else would point them out if they weren't. I had already started managing that engineer differently, but because no one else was saying anything, I convinced myself I was imagining it. Waiting for external confirmation didn't make the conversation easier. It just delayed understanding what was actually happening.

Performance dips happen to everyone. We all have projects that go sideways. We all have weeks where we’re distracted or simply not at our best.

Underperformance is the pattern that continues after expectations have been clarified. After coaching has become specific. After someone has had a chance to adjust.

By then, the cost is rarely isolated to one person. Teammates have started compensating. The manager has started checking in more often, making backup plans, and lowering the bar just enough to keep things moving.

The danger isn't that you'll miss the problem. It's that you'll adapt to it.

You stop giving them stretch work. You check in more often. You assign someone else as backup. You quietly redefine what "good enough" looks like for one person.

That's unfair to them because they never get the coaching they need. That's unfair to the rest of the team because you've quietly changed the standard.

That’s why I pay attention when I catch myself managing someone differently. Not because I’ve reached a conclusion - I haven’t yet. But because that’s when there's still time to understand the problem instead of adapting around it.

Pull Requests Are Trust Infrastructure

I’ve lost count of the number of one on ones with direct reports I’ve had where someone complains about another engineer’s pull requests. “Theyre chasing perfection” or “they’re cutting corners” being the two extremes the feedback pendulum swings between. The engineer asking for more tests thinks they’re protecting production. The engineer pushing back thinks they’re protecting delivery speed. Both think they’re defending good engineering.

It’s easier than I’d like it to be to wind up with a team stuck in a pull request standards debate that won’t resolve no matter how explicitly you define the rules. Teams rarely argue this long about standards unless something else is going on underneath.

When technical standards debates get stuck, the problem usually isn’t technical.

If I hear a team is engaging in pull request standards debates, I suspect a lack of trust because pull requests are usually where trust problems surface first.

Why?

Because PR reviews force engineers to answer heavy questions about their teammates like: Do I trust your judgment? Do I trust your testing habits? Do I trust your production instincts? Do I trust your ownership boundaries? Do I trust your definition of “done”?

Those are organizational questions disguised as formatting comments.

Pull requests are one of the places where trust gets tested most visibly. They force teams to make implicit expectations explicit.

Teams with trust merge faster because they debate and rewrite less. Not because they review less carefully, but because they can review more efficiently. They spend their attention on genuinely risky changes instead of re-litigating every convention.

Teams with little or no trust relitigate everything, over-specify standards, and escalate to managers.

I’ve seen this show up as reviewers asking for excessive test coverage from some engineers but not others, or pushing back on PR size from newer teammates but not experienced ones. Even just spending longer reviewing one engineer’s code than another’s. Those aren’t really standards disagreements. They’re signals about where confidence hasn’t caught up yet.

No matter how many review guidelines we wrote down, there was still a disconnect on the team. Our documentation may have changed, but the underlying trust didn’t. I have seen managers help guide teams out of this scenario by calibrating reviewers, reinforcing shared ownership, and building reliability confidence across engineers.

One place I’ve seen this show up repeatedly is when newer engineers join. They should participate fully on the team, and that includes reviewing pull requests. But with a steep learning curve around identity engineering, new reviewers may not yet have calibrated around expectations. In one case we kept review participation broad but preserved a smaller group responsible for final merge confidence until context caught up across the team. Over time the extra layer stopped being necessary because the trust gap closed.

Then standards suddenly became easy again.

I’ve been having more discussions around pull requests lately than I have in a long time largely because of the effect AI has had on them. From AI generated code to increased number of pull requests to AI review - people want to understand what these changes mean for our standards. 

AI is changing how code gets written and reviewed. But it hasn’t changed the underlying reason teams struggle to agree on standards. Organizations regularly add automated reviewers to pull requests because they’re great at enforcing the exact standards engineers used to debate about. Review velocity expectations are shifting.

But the trust layer underneath review standards is actually becoming more important, not less. Teams still need shared trust about what “good enough” means. AI can accelerate code review, but it can’t replace trust.

Before AI, pull request standards debates often looked like disagreements about correctness versus speed versus style. After AI, pull request standards debates should become about what counts as trustworthy engineering work when authorship is changing.

Now teams are still asking the same questions about trust but with a different target. Instead of trusting their teammates they’re asking even bigger questions: 

Do we trust AI-generated code?

Do we trust the engineers on our team to validate AI output? 

Do we trust engineers to know what they didn’t write?

That’s not process friction.

In a code review context, it’s the difference between “I trust this code works” and “I trust the process by which you decided this code works.”

Fix trust first. Standards will follow.

Technical Debt Does’t Stay in the Code

We usually talk about technical debt as something purely technical, something only the engineering department cares about deeply. But the reality is it doesn’t stay there.

It spreads into planning cycles. It changes how teams estimate. It shapes who gets trusted. It alters escalation patterns. Eventually it becomes organizational structure.

Once upon a time, an engineering team owned a shared library that required updates across every consuming service whenever changes were made. Each change to the library required PRs with owning teams, triggered feedback loops across multiple services, and introduced coordination overhead measured in weeks.

Over time the engineers on the team avoided recommending solutions that depended on the library at all.

Eventually the library was converted into a service. The team had to make the case for time on our roadmap, showcasing the data of just how much faster we would ship every subsequent feature if we took the time to make this change.

The scariest part of this story is that before reducing the technical debt the engineers weren’t choosing the best solution. They were choosing the least expensive coordination path. And I couldn’t blame them. As their manager I also wanted to avoid that library.

I hadn’t realized how much technical debt was impacting the team. It wasn’t just an engineering “nice to have.” Technical debt had narrowed the solution space. At some point it had stopped being just technical debt and had become organizational debt — not because it was legacy code that annoyed engineers, but because it changed behavior across teams. Because technical debt had begun silently steering architectural decision-making.

On another team, only a subset of engineers deeply understood the system they were responsible for. This created implicit dependencies: reviews routed through those specific engineers, estimation confidence depended on them, roadmap sequencing depended on their availability, change safety depended on their presence, onboarding slowed, cross-team collaboration narrowed.

When faced with this scenario, resolving it became my top priority. Our velocity was a snail’s pace, but equally important there was no space for a marketplace of ideas. No one knew enough to contradict those with deeper knowledge. As a manager all I could think about was a clock ticking until one of these critical engineers left the team and our ability to ship ground to a halt.

This wasn’t just a knowledge gap. It was an organizational dependency structure created by technical complexity. Technical debt wasn’t just shaping delivery time. It was shaping authority and risk ownership. In critical legacy systems the solution is usually a combination — chip away at technical debt while simultaneously investing in learning for newer engineers, until I no longer heard that ticking clock.

None of these stories looked like technical debt problems at first. They looked like roadmap tradeoffs. They looked like staffing risks. They looked like cautious estimates. It took me time to realize they were all the same story. The library story is about debt shaping what gets built, the knowledge story is about debt shaping who gets trusted.

By the time technical debt reaches that point, it isn’t just slowing teams down. It’s shaping how the organization works.

Technical debt doesn’t just live in the code. It becomes the org chart.​​​​​​​​​​​​​​​

Explaining the Why Reduces Manager Overhead

Moments where leaders don’t take the time to explain the “why” create overhead.

I understood the value of explaining the why early on, but it took me longer to feel what it changed on a team I managed. 

When I think of my teams there’s one scenario that I think highlights the impact of sharing the why, which is urgency without context versus urgency with context. Asking an engineer to do a task urgently can go a lot of different ways. The engineer may re-triage mentally or second-guess the interruption cost to their current work or ask follow-ups or delay slightly. Asking an engineer to do a task urgently hits differently when I explain to them that it’s a security issue. Armed with the “why” they reprioritize immediately, act confidently, and stop needing confirmation from me about what they need to do next. They already know what to do because we’ve pre-aligned on how to handle security issues and as their manager I need to show them I trust that they know how to handle the situation accordingly.

This was the progression that surprised me most. By explaining why, I’m empowering my engineers to make decisions on their own and act in alignment with the goal we’re solving for. Context lets engineers make aligned decisions without waiting for me. If they understand why, they don’t need me in every room and every decision. That’s when context becomes a scalability mechanism. I have more bandwidth to do the work that only I can do. Someone made a decision I hadn’t explicitly authorized — but it was the right one. I was able to set the direction and have engineers execute inside it. That's when I realized context had replaced approval.

Managers often try to solve for alignment with increased structure. They had specific actions they wanted their team to take, and they were doing everything they could to make it as easy as possible for them to just get on board with the plan. I've watched managers build templates, checklists, recurring reminders, and dashboards to encourage behavior they never explained in the first place. They never explained to their direct reports why they wanted the specific actions they had asked for. They had created an entire system to compensate for missing context.

There is a high emotional cost to missing context around the work we do. Without context, changes feel like they’re happening to people. 

Lack of context creates resistance overhead on the team. It can feel like whiplash to have a plan laid out in front of you only to have it swapped out for something else with no idea why that change was made. On a healthy team engineers can and should feel a strong sense of ownership over their team’s roadmap. Making changes without context can be incredibly destabilizing. Engineers without context hesitate, disengage, escalate more, and even question the legitimacy of the changes. Slowing down to explain the why replaces all of that with ownership, and that’s a cultural overhead reduction. 

A lot of times explaining why can feel like overkill. Do the engineers even care? Am I wasting my breath taking the time to go over the same details across all of my direct reports’ one on ones?  But I always come back to the same conclusion: I’d rather give my engineers insight into how I’m thinking about something basically every single time. It lets them know that what’s happening around them isn’t random, that there is a plan and a strategy. It helps them understand the direction we’re driving in the long term. Explaining why makes people feel included in direction, not controlled by it.

Explaining why does not make my decisions as a manager optional. I don’t want it to sound like what I’m suggesting is that if you just explain things more then everyone around you will suddenly agree.

Alignment and consensus are not the same thing.

Sometimes I can’t share the why with total transparency — like team personnel changes or blunt operational truths — but part of management is navigating that storytelling. Giving people enough insight to feel empowered without burdening them with information they don’t need or can’t have is an important skill that takes time to hone as a manager. 

Managers, myself included, often have to explain organizational decisions we don’t necessarily agree with. But that’s not the point. The point is finding integrity and value aligning with that direction. Okay, we’re going this way now — how are we as a team showing up for that? 

One of my former managers who I learned a lot from always had multiple variations of a plan, and was always really open about sharing his vision and what he was building for his teams long-term. It made me feel really good, like I was trusted with that insight and like I was building something with him and my peers beyond the day to day tactical moves. It made the road in front of me feel exciting instead of like a dark path through the woods where I couldn’t see the end. That’s the feeling I want to imbue on the teams I manage. 

Providing teams with context looks like communication work, but it’s really scaling work. When teams understand intent, they stop waiting for instructions. Over time, the role of the manager shifts from answering questions to setting direction.

Explaining the why doesn’t just help your team move faster. It changes the shape of your job.​​​​​​​​​​​​​​​​

Hiring Is the Last Thing I’ll Delegate

Someone asked me once if I wanted to hand off hiring for an open role on my team. It was well-intentioned. I was stretched thin, and handing it to another fully capable manager would have been a reasonable thing to do.

I couldn’t do it.

To understand why, you would have to understand what hiring actually is. It looks like a process: a question set, a scorecard, a debrief. But that isn’t the whole story. It’s a series of judgment calls that only you can make for your team, and you’ll live with them long after the decision is made. The person you hire is still there six months later, a year later, shaping the culture and velocity of your team in ways you can’t fully control after the hiring decision is made. Every other call you make as a manager has a close. This one doesn’t.

There was a time in my past when another manager hired engineers for my team. I was on leave, and they did a genuinely good job. But I came back and inherited the consequences of someone else’s judgment calls. The good ones and the bad ones. When it didn’t work out, I was the one in the room having the hard conversations, doing the coaching, making the calls that follow. It was a lot of trust to place in a peer for something I had to live with long after they moved on to their next focus.

So when the offer came to delegate again, it hit a nerve. Hiring had to stay mine.

Part of that is ownership. But part of it is that judgment in hiring isn’t transferable. It takes years to build, and most of us learn it by doing.

Early in my management career I joined a part of the org that was aggressively hiring. It felt like all I did was interview. I remember watching a senior engineering manager who had clearly done this hundreds of times. He was calm, precise, never rattled. And I just kept thinking: how?

The answer was repetition. There was no shortcut.

What repetition gave me, eventually, was pattern recognition. I can hear now when a story glosses over something. When the logic doesn’t quite hold but the candidate is hoping I won’t press. When someone can’t go as deep as they’re implying they can. Early on I wasn’t hearing those things as easily. I was taking the stories at face value.

It also taught me that while I’m evaluating a candidate, they are absolutely evaluating me. How I run the interview, what I ask, how I react when they tell me something unexpected — all of it is data they’re collecting about what it would actually be like to work here. I’ve been in interviews where the interviewer kept a straight face and flat affect the whole time. I am physically incapable of it. I react to what people tell me. I let the conversation move where it needs to move. I get thanked by candidates for this more often than I expect to. That’s not me going easy on them. I’m just not creating artificial stress that obscures the actual signal. If someone performs badly because they’re terrified, I haven’t learned anything useful and neither have they.

The best hire I ever made reminded me why hiring is so difficult to hand to someone else. I recognized it in the interview. Every question I asked, they answered without assumptions. They clarified before they dove in. They were engineering for the future, not into a corner. That’s what I’m actually looking for. Not a list of traits but a way of thinking. Curiosity that refuses surface-level answers. Grit that shows up not as toughness but as the willingness to say: here’s where I failed, here’s what I’d do differently. Engineering is failing and trying again. Anyone telling me their tests always pass hasn’t worked on anything hard yet.

As my judgment improved, I found myself trusting a simple rule that I’ve kept ever since: if it’s not a hell yeah, it’s a heck no.

I arrived at this after an early debrief where I could tell the team wasn’t excited about a candidate. Nothing disastrously wrong, but nothing clearly right. They were visibly afraid we were going to hire this person just to fill the seat. They weren’t wrong to be afraid. That’s exactly what happens when you let the length of the search decide for you. You’re tired, the role has been open too long, and “good enough” starts to feel like a real option.

It isn’t.

A hiring mistake doesn’t stay contained. It spreads into the team’s velocity, the culture, your own calendar.

But the harder truth about hiring, and the one that took me longer to sit with, is what it feels like when the answer is no.

Sometimes the candidate in front of you is incredibly kind and is clearly trying so hard. They genuinely want the role. And they’re not the right fit for what the team needs right now. That’s devastating. I can accept I’m making the right decision, and it still never feels better no matter how many times I have to do it.

Early in my career, I wasn’t carrying that weight alone. I shadowed that senior engineering manager. We’d talk constructively about how the interviews went. There was a sounding board.

Now I do these interviews alone.

I sit down after the interview and I fill out the scorecard by myself. The weight of the decision is mine to carry.

What I’ve learned is that if it’s in my head, it can be harder to see clearly. So I write. Writing is how I find out what I actually think. I write what they did well and what they didn’t, and then I sit back and read it over. The decision gets clearer on the page than it ever does in my head. There’s something clarifying about having to put it into words.

I’ve been the tired EM. The one whose script is so memorized that my mind starts to drift mid-interview. I know what that feels like.

But I always pull my focus back. I have to. Because the person sitting across from me took time off, prepared, and is trying to show me something true about themselves. My team is counting on me to actually see it. The scorecard is mine to fill out alone. I owe them my full attention — and I owe my team my honest judgment, even when it’s hard to give.

Hiring is one of the highest-leverage things a manager does. The person you bring in changes the team. For a long time.

That’s why, whenever someone offers to take it off my plate, I hesitate.

There are plenty of things I’ll delegate as a manager.

Hiring isn’t one of them.

Translation, Not Transmission

I once knew a manager who told his team when he’d started applying for jobs elsewhere. He was really proud of how transparent he was with the team. What he was actually doing was making this everyone else’s problem. No one on the team knew exactly when he’d be leaving or who would replace him or what it would mean for the team. They only knew they had a manager who was jumping ship. What did it mean for them? No one knew. 

Radical transparency sounds virtuous. In practice it’s often abdication dressed up as honesty.

I often write about managers as translators. The role of a manager isn’t to pass raw information directly from the organization to our teams. That’s what email is for. The role is to filter information, contextualize it, and deliver it in a way that sets people up to do their best work. A pilot hitting turbulence doesn’t walk out of the cockpit to tell passengers whether or not it makes them nervous. They let the passengers know there’s turbulence ahead and roughly what to expect. That’s not withholding information. That’s professionalism. 

But the opposite failure is just as dangerous.

A leader who tells people everything is fine when they can see the water rising hasn’t protected anyone. They’ve just destroyed the one thing that actually keeps a team functional in hard times: trust. False certainty isn’t kindness. It’s a lie with good intentions. People make real decisions based on what managers tell them — whether to stay, whether to push back, whether to panic. I don’t get to decide those stakes are too small to matter.

These aren't opposite ends of the same spectrum. They're two different ways to fail your team. One through too little judgment, one through too little integrity. Being a leader requires both.

There’s information that’s mine to hold, not theirs to carry. Knowing the difference is the job. When I know something I can’t share yet, like a team change, a decision still being finalized, I don’t pretend it isn’t happening. I just ask myself a different question: how do I take care of my team right now, with what I’m able to do? If an engineer is transferring teams and that can’t be announced yet, I can still make sure there’s a transition plan. I can make sure the roadmap reflects the capacity change. I can do my job in ways that absorb the disruption before it hits them.

That’s what translation actually looks like. I take in the noise, I filter it, and what comes out the other side is clarity or at least steadiness. Not false certainty. Not chaos. Just a manager doing the hard, invisible work of holding what needs to be held and sharing what needs to be known.

How I Think About Career Anxiety in the AI Era

The headlines lately are relentless. People are guessing left and right what AI is doing to the tech industry, to society, to the world. Junior engineers questioning what they just got a CS degree for. Senior engineers wondering if the job they fell in love with still exists. People with rent and families and plans, watching an industry reshape itself in real time. A layoff isn’t just a financial event. It’s an identity event. And the fact that it’s virtually unpredictable makes it harder to hold, not easier.

I’m not writing this from a place of having figured it out. Anyone who tells you differently is bluffing their way through this. I have small children and a decade in this career and I read the same articles as everyone else. The articles that say we won’t need engineers, and the ones that say we won’t need managers. 

Someone asked me recently how I approach the anxiety of this particular era. How do I sit with not knowing what’s coming?

I told her I think about two things.

The first is that history repeats itself, and not always in the ways we fear. When ATMs were introduced, people predicted they’d replace bank tellers entirely. The opposite happened. The number of tellers actually increased. The cost of running a branch decreased so banks opened more locations. Tellers’ role shifted. The technology changed the shape of the job, not whether or not it existed.

Maybe that’s what this moment is for engineering: not destruction, but a transformation. A shift in what engineering looks like, instead of an elimination of the people who do it. I don’t know that for certain. But history gives me enough ground to stand on that I can stop catastrophizing long enough to breathe.

Which brings me to the second thing: I have no control over this.

That may sound bleak. I mean it as an act of radical acceptance.

When I really sit with the fact that I cannot predict what happens next — not to the industry, not to my company, not to my role — the vice-like feeling in my chest loosens. The anxiety doesn’t disappear but it changes shape. It stops feeling like a problem I need to solve and starts feeling like weather I need to dress for.

So I try to prepare for multiple possible futures. I try to leave doors open. I don’t need to walk through them necessarily, but I can keep them unlocked. For me, options change how uncertainty feels. And then I try, as much as I can, to just go along for the ride.

It’s a roller coaster a lot of the time, but the history piece is what reminds me the track doesn’t end in a cliff. It just goes somewhere I haven’t been yet.

I can’t promise certainty, and I won’t. But I can say this: hope isn’t a plan. It isn’t nothing either. Hope is what keeps you moving when the ground won’t stop shifting.

1:1 vs 1:N Impact

I became a manager of my first engineering team. I got pulled into team ceremonies and alignment meetings and lots of one on ones. Before I knew it the calendar was full. I was being so productive. I was helping so many people.

New managers default to 1:1 work because it feels like so many of the things we want it to feel like: concrete, responsive, visible, fair, and controllable. 1:N work on the other hand feels abstract, slower, riskier, and sometimes invisible. The work that helps one person immediately often feels more real than the work that helps ten people eventually.

So people over-optimize for the wrong layer of impact without realizing it.

I used to talk a lot, when folks asked me about why I wanted to be a manager, about wanting to exponentially increase my impact. That I would scale my impact on the org through those who reported to me by helping them be better more effective versions of themselves. To some degree I did accomplish this, but mainly by leveling up my engineers as individuals.

When I first took on managing two teams, I didn't scale myself. I was treating having two teams like I had the same attention and bandwidth as back when I had one. The same attendance at meetings, the same cadence of one on ones with direct reports. Nothing had changed except my bandwidth was at an all time low.

That’s the moment I knew this didn’t work.

Not because something broke. Because nothing broke, and that was the warning sign.

Many managers assume scaling only starts when things go wrong. But often the real signal is: everything is working and I still have no time left.

I was running a marathon like it was a sprint.

I went into management wanting to make a 1:N impact but had never actually made the shift.

My calendar made that gap visible. Anyone who looked at my calendar could see how I was operating (or wasn’t). The calendar told the truth about my leadership scope. 

No one had ever told me when that transition would be required. I realized the skills that helped me succeed before weren’t the ones I needed next. Being great at supporting individuals is not the same as being effective at leading organizations. I had to stumble into the problem to realize I needed to claw my way back out, one updated meeting invite at a time. 

When I finally started scaling differently, my calendar changed. My one on ones got shorter and less frequent. I stopped being the person who solved problems and started being the person who set the conditions for others to solve them. I didn’t have to be in every room or every meeting to know that the strategy I planned was being executed properly. I needed to build a structure and a team to support that. This was the first time I understood that scaling my impact didn’t mean working more. It meant changing what kind of work I was doing.

When I wanted to become a manager I dreamed of how much greater my impact would be if I expanded the potential of all the people who reported to me. Then I started dreaming even bigger. I was planning in terms of systems and repeatable frameworks. That’s when I stopped measuring my effectiveness by how many people I was helping directly and started measuring how well I was truly scaling my impact. 

Managers are not evaluated on how helpful they are individually. They’re evaluated on what becomes possible because they exist.

When Output Stops Being a Signal

It used to be easier to tell who the strongest engineers were on a team, often just based on output. They were the ones shipping the most, moving the fastest, and getting the most done.

AI is making that harder to do. It made it easier for everyone to produce output, even non-engineers, which means output got a lot noisier as a signal.

To be clear, I don’t think output is or has ever been our best signal. I’ve never loved using Jira metrics as a proxy for performance. I’ve always cared more about whether we shipped what we intended, when we intended to.

But AI makes it harder to ignore.

On one of my teams, an engineer systematically cleared a backlog of low-level tech debt in a single sprint. That was real, valuable work. But when I looked at the metrics alongside an engineer who spent the same sprint on one high-impact change, the numbers showed a major disparity even though the impact to the team was huge in both cases. Output has never been a great signal. AI just made that harder to pretend otherwise.

Some of the most impactful engineers I work with don’t have the highest Jira velocity. They spend time building internal tools, reviewing others’ work, and keeping the team aligned to the technical direction. Their impact shows up in everyone else’s output, not just their own. If I only looked at tickets closed, I’d have undervalued them, which means I’d be optimizing for the wrong things.

It has also become increasingly possible to have two engineers shipping similar amounts of work and operating at completely different levels. One who uses AI to move faster but validates decisions and simplifies the design. The work holds up. The other who uses AI to generate most of the implementation. It passes tests, gets approved, and ships. A few weeks later, it’s the source of follow-up work, edge cases, and confusion. On paper, they look equally productive.

I think a lot of people are focused on “AI slop” and the obviously bad work being passed off as good. I’d argue that while that is a real concern, the bigger risk isn’t even the obviously bad code. It’s the work that looks reasonable - solid PRs, passing tests, sensible structure - but work that’s built on shallow understanding.

It’s easier to skip the deep digging that used to build real intuition, and that gap shows up later in edge cases and design decisions. You can get to something that works without fully internalizing why it works.

I’ve even felt this myself. Early in my own AI usage, I once relayed an inflated estimate to product leadership based on that kind of exploration, only to realize later that most of it wasn’t relevant. It felt so convincing in the moment. 

We’re all learning how to use AI. Mistakes are bound to happen. I use these tools too, but as a manager, I’m often in situations where I have to rely not only on my own ability to use them but on my direct reports’. I’m one degree removed, which puts a lot of trust in a skill we’re all still figuring out.

For a long time, output was an easy “out”. A rough proxy for capability. It was never perfect, but you could argue it sort of worked.

It works even less reliably now.

We need to avoid hyper-focusing on output and spend more time evaluating the things that are harder to measure: how engineers make decisions, whether they can explain why something is the right approach, whether they improve the system around them, not just their own output.

None of this is about AI being good or bad.

It’s about what it changed. Output is easier to produce, which means it’s less useful as a signal.

The difference between engineers hasn’t gone away. It’s just harder to see at first and more expensive to ignore later.

That means more direct conversation about decisions, more investment in code review as a teaching tool, and more weight given to the engineers whose impact multiplies others rather than just their own.

When output stops being a signal, judgment is what we need to pay closer attention to.

Thought Leadership Is Just Solving Problems Out Loud

I’ve had more than one conversation with engineers considering management where this idea comes up — the idea that thought leadership requires some sort of profound revelation, or some kind of anointing process before you’re allowed to participate. Thought leadership is an aspect of management that becomes more expected the higher you go, and is often explicitly called out in leadership role descriptions. Feeling like you couldn’t possibly be a thought leader can make the expectation itself feel like a barrier to entry.

But here’s the most delightful secret: we’re all just figuring this out as we go along.

So if no one innately knows all of the answers, maybe thought leadership isn’t claiming to have the answers. Maybe it’s really just finding a problem you’re excited to solve and solving it while keeping others in the loop who might benefit from seeing how you approach it.

New managers often resist visibility. Hell, I often resist visibility. Even the engineers I manage resist visibility. Just watch how fast they avoid eye contact when I ask them to write an internal blog post or share a demo outside of our team.

People sometimes say engineers avoid visibility because they believe their work should speak for itself. I don’t think that’s quite right. I think we’re just used to solving problems in code. Once the solution works, it’s available to everyone. Anyone can read it.

As a manager, solutions don’t work that way. Some of the work is still code, but a lot of it isn’t. Adjusting to a leadership role meant I had to get comfortable being uncomfortable and share my solutions — my ideas — on a wider platform. It’s a lot like opening a pull request, just with a much larger audience. Both require you to be in the position of saying, “I may not have the perfect answer, but here’s my best shot. Let me know how we can iterate toward something even better.”

The first thing I did that got any real attention as a manager was an internal blog post about driving your own career: career development, conversations with your manager, and promotions. It was a topic I felt really strongly about because people were so often confused or blindsided by the process. Why not try to pull back the curtain a bit? A lot of people ended up reading it and sharing it and referring to it years after I hit publish. It was a real problem I was trying to solve. I didn’t think of it as thought leadership. I thought of it as documentation for a system people were struggling to navigate.

Publishing something that wasn’t code felt strangely vulnerable at first. Code review was familiar. Sharing my thinking about promotions and career development felt much more personal because there wasn’t a compiler to tell me whether I was right.

But what surprised me was the response. Not because I had perfect answers, but because someone finally said out loud what they were confused about too.

I’ve watched incredibly talented engineers and managers struggle because nobody outside their immediate team understood how they thought or what they were solving. Visibility isn’t just about recognition. It’s how organizations learn where trust and leverage already exist.

Visibility isn’t about positioning yourself as an expert. It’s about making your thinking accessible to the people around you. When people can see how you approach problems, they can learn from it, challenge it, and build on it. That’s where influence actually starts.

Most thought leadership doesn’t start with authority. It starts with friction.

As engineers, we’re so good at finding and solving problems. The next evolution of that is finding and solving problems that matter to other people. And not even necessarily solving them. Take your best shot, share your best guess. Thought leadership doesn’t start when you have answers. It starts when you decide a problem is worth solving out loud.

Make the Damn Time

Early on I thought strategy was something that would happen once things calmed down. Things never calm down.

For something that is so clearly important to the role of leadership, it’s kind of amazing how little time a lot of managers dedicate to it in our day to day work. 

I made some pretty classic mistakes when considering strategy. At first I thought it was just something that happened around the other work as a sort of natural side effect of everything else I was doing. That couldn’t have been further from the truth. My early management was defined by reactive, day to day problem solving. It was super grounded in tactical thinking. I figured that because I was being intentional and thoughtful I was operating at a higher level. I would’ve said I was being strategic or thinking strategically and I’d have been wrong.

Management is a much lower stakes game of Emergency Room where new problems are constantly rolling through the double doors and it’s your responsibility to triage those issues. Not solve every single one at the same time, but prioritize and mitigate fallout. 

If I wasn’t actively making time for strategic thinking, there was always other work that would take its place. 

If I was not prioritizing strategic work I will never “just have the time.” 

I began to think of strategic thinking as a defended resource. Not something that happens when the calendar clears, but something that only exists if you protect space for it.

Strategic work is what gets you out of firefighting mode and back to shaping how your team actually operates inside the organization. Because I don’t think anyone really dreams of becoming a manager to fix a team’s broken ticket refinement ceremony for the fifth time in your career. You become a manager to impact a piece of an organization. And that requires strategy. 

So make the damn time!

The question isn’t whether strategy matters. It’s how you make time for it when your calendar already feels full. How do managers actually create space to lead instead of react? 

It’s a loop that reinforces itself. You can’t think strategically because you don’t have time, and you don’t have time because you’re not thinking strategically. At some point something has to give so you can put time on the calendar. Actually blocking it off. 

I started small in my quest to make time for strategy. I found already open blocks on my calendar and reserved them for myself. It wasn’t long before I needed more. I was hooked. It was time to seriously reassess what I had committed to in terms of my time. Were my one on one meetings too frequent? Was I attending recurring meetings that had outgrown their value? I adjusted as needed. Then ruthlessly blocked my time. 

As of this post I have three main blocks on my own calendar that I defend ruthlessly. I have an operational alignment block where I make sure my week is set up to achieve my highest priority goals. I have a deep work block for the to do items that need more than ten minutes between meetings to accomplish. And I have a strategic block. Maybe for others this is a walk outside or a block of time with just your thoughts and a notepad. Because I don’t do well with wide open blocks of time and no clear call to action I have a strategic thinking template I use. It’s a great launching off point each week to get me focused on what’s potentially working or not working about how my teams operate or what the org is prioritizing. From there I can choose my own adventure about which problems to solve but that initial template is what I need to get in the zone. 

Strategic thinking isn’t something managers earn time for later. It’s something to defend now so later gets easier. Strategy didn’t start happening when I became a more senior manager.

It started happening when I started protecting time for it like it was part of the job because it is.

No One Trains You To Be a Manager

One of the stranger surprises about becoming a manager is how little structured support there can be once you get there. Maybe if you were lucky, as an engineer you had a manager who offered some coaching when you told them you wanted to become a manager. But it’s not like engineering where you took classes or honed your skills over years of practice before someone paid you to do it. You never took a class on how to manage people. There’s no real training to prepare you for how to be a manager. 

A totally normal conclusion to draw is: well my manager will teach me how to manage. By the time I actually became a manager, my boss couldn’t be my mentor. They could be my professional coach just like any manager should be, but their time is limited and their motivation in my development had to fit business needs as well as my personal goals. The conversations I could have with the person rating my performance could never be completely unfiltered. Plus once I became a manager I was expected to be a manager - not a manager in training. The expectation was that I was already performing at that level not below it. 

I had to learn on the job and I had to learn quickly because management comes with increased scope and impact. Getting it wrong now would happen on a much bigger platform.

I turned to books for a lot of early management guidance. If someone else has already learned these lessons, why not learn from them faster? There were some leadership style workshops a couple of employers offered. But that was really it. And a lot of those books and workshops were truly helpful. But what I wanted and often needed was less playbooks and more guidance for the specific situations I found myself in or the dynamics unique to my organization.

As an engineer, most people enter the workforce with a certain baseline of engineering knowledge but over the course of your career you learn predominantly from peers. You learn by reviewing code together, watching others solve problems. Once you transition to management, you go from being on a team and learning on the job but with lots of support and oversight from your peers to a much more solo experience. Managers typically have fewer peers, fewer shared problems, and fewer safe practice spaces. That doesn’t mean management is unsupported work. It does mean the support structures change, and most of them become ones you have to build intentionally instead of inheriting automatically.

As a solution to this exact scenario, one recommendation I encountered was leaning into your “first team” of managers or those few who report to the same leader you do. I used to love that advice. As a newer manager it felt extremely comforting to think I could recreate some of the team dynamic I had been missing when I first transitioned into leadership. Having the recommendation point to an easily identifiable group was a bonus. 

Sometimes though this isn’t the built in solution we need. Maybe you can’t go to the managers closest to you hierarchically. Are they people you feel safe being vulnerable with? Are you all vying for the same opportunities? Do they want to be on a first team with you?

Those first team manager relationships do matter. They’re essential partners in the work. But they aren’t always the people you turn to first when you’re trying to figure out how to grow as a manager.

The managers I’ve learned the most from over time haven’t always been the ones closest to me in the org chart. They’ve been the ones willing to share their experiences openly or compare notes. Sometimes they help me — advice, perspective, support when something doesn’t go the way I expected. Other times I’m able to help them in return. They’re the people I reach out to first when I’m trying to make sense of something new.

Not only did I discover there was limited structured learning once I became a manager, but the difference in isolation was a serious adjustment. The higher you go the more that isolation is a factor. I couldn’t turn to the team I was managing and tell them what a hard day I just had with performance conversations, or a difficult chat with the VP. Having a network of other managers I could turn to combat that feeling in a way that made the job feel more sustainable - and usually even more fun. 

You don’t get to choose who your peer managers are. 

But you can choose who you learn from.

You can choose who you watch closely. Who you ask questions of. Who you reach out to after a difficult conversation. Who you pattern yourself after when you’re not sure what the right move is.

Early in management especially, that network matters more than people admit. 

One of my favorite mentees who became a manager last year told me recently that he’s finally starting to reach out to other managers outside his immediate peer group. He said it’s made a huge difference in how he approaches the role. He sounds less like someone trying to survive day to day inside one small space and more like someone operating as part of the organization’s leadership team.

That shift is subtle, but it matters. Those relationships don’t just provide advice and support. They change how you understand the organization itself and where your work fits inside it.

Building that network is one of the first real leadership skills most managers develop, whether anyone tells them that’s what they’re doing or not.

Friendly, Not Friends

One of the earliest pieces of management advice I got was simple: be friendly, not friends. It sounds obvious. But it takes time to understand what it really means.

Friendly means approachable, respectful, and invested in someone’s growth. Friends implies shared loyalty and shared decision-making power. Managers can offer the first. They can’t offer the second.

Most of us spend our entire lives learning how to belong to groups. We learn how to get along with classmates, teammates, coworkers. We learn how to read a room. We learn how to be someone other people want to work with.

And then one day you become a manager.

The dynamic changes whether you want it to or not.

Friendship assumes mutual support, vulnerability, openness, and shared motivation. Management changes the conditions those things depend on.

I was fortunate that my first management role was with a team who only knew me as their manager. I’ve seen engineers struggle much more when they transition into managing former peers. But this trap isn’t limited to that situation. It shows up any time a manager focuses too much on being liked instead of being clear about their role.

Most of us are wired to want to belong to the group we’re working with. Especially at work. It’s where we spend most of our time. Learning how to get along with coworkers isn’t optional. It’s a survival skill.

That’s part of why this shift feels so uncomfortable when you become a manager. You don’t suddenly stop liking the people around you. But the role requires a different kind of relationship with them. The minute you become a manager there needs to be a boundary there. The dynamic has shifted whether you intended it to or not, and pretending it hasn’t usually makes things harder for everyone involved.

Managers are often privy to information the team cannot or should not be aware of. My friends don’t keep secrets from me. My best managers knew when to let me know something and when to be a shield.

You also don’t have the same motivations. Yes, you can want the best for someone as a person. But your performance depends on their performance.

It’s similar to another boundary new managers sometimes struggle with: you’re not their therapist. People bring real life with them to work and those things matter. But your role isn’t to solve them. Your role is to support them as professionals inside the environment you’re responsible for shaping.

I was recently talking with another manager who was new to the role and struggling to get their team to not only buy into their plans, but to act on them. As we talked through the situation, it became clear they were still proposing their ideas like they were optional, like they required group consensus to become real. It made complete sense why they were operating that way. Most of us spent years learning to work that way as peers. And when the boundary between peer and manager still feels blurry, it’s easy to keep acting like one of the group instead of the person responsible for the decision. But management changes what your role in those conversations is. Sometimes your job is to invite input. Sometimes your job is to make the decision. And sometimes the plan is simply the plan.

Friendship also assumes equality. But once someone reports to you, the power dynamic changes whether either of you acknowledges it or not. They can’t disagree with you the same way. They can’t be fully candid the same way. They can’t give you the kind of unfiltered feedback real friends give each other. It stops being an even relationship. The relationship stops being equal the moment you become their manager, even if nothing else changes.

Early in my management career I let this boundary blur once. It didn’t create a crisis, but it changed the shape of the relationship in ways that made it harder to do the job well. Our 1:1s became less focused. Expectations were harder to reset. It became harder for me to show up clearly in the role I was supposed to be playing. That experience changed how seriously I take this advice now.

Sometimes when the boundary shifts too far, the relationship starts to carry expectations it can’t support. Conversations drift away from the work. The manager becomes a confidant in ways that make it harder to do the job clearly.

This relationship shift can feel uncomfortable but it’s necessary for clarity and fairness.

It’s hard. I have and do manage some awesome people and maybe in an alternate timeline we’d be friends but that’s not the one we’re living in.

Managers can be warm. Managers can be kind. Managers can be trusted. Managers cannot be peers to the people they manage.

Managing Engineers Through the Age of AI

I want to write about AI. Transitions like this don’t just change what we build. They change how engineers experience the work itself. I don’t worry about what AI is doing to our delivery timelines. I do worry about what it’s doing to our engineers. Even more specifically, what it’s doing to our most senior engineers. 

From what I’ve seen so far, lower to mid level engineers seem more open to adopting AI in their day to day workflows. As junior engineers, they’re still forming their engineering identities. They’re flexible. As senior engineers, they’re pragmatic and outcome-focused which aligns nicely with using AI to achieve greater outcomes. 

I’ve seen something different with staff engineers. The engineers most unsettled by AI aren’t the least capable. They are often the ones who have spent the longest learning how to be excellent. As staff engineers, identity tends to be anchored in how systems get built. Staff engineers often optimize around architecture clarity, technical taste, solution-path efficiency, and authorship depth. AI shifts the value surface away from those signals. A lot of staff engineers are initially reluctant because we trained them for years if not decades to find the most efficient path to a solution. Then we introduced AI as a new tool. Like any other new tool, there’s friction to learning to use it. 

We’ve seen transitions like this before. When search engines like Google first became widely available, people weren’t immediately sure how to use them well, and some environments even discouraged relying on them. Today it would be unthinkable to say you weren’t using search as part of your workflow. AI tools are starting to follow a similar pattern.

When that friction shows up, staff engineers often want to just write the code themselves because historically that was the most efficient solution. But as managers, we need them to get through the friction of adopting AI because the other side is actually faster. That’s destabilizing in a very specific way.

For these engineers, the hardest adjustment isn’t technical. It’s emotional. They didn’t fall in love with reviewing generated code. They fell in love with writing it. There’s a real, often unspoken, grief there because the way they’ve excelled at working is no longer what’s being asked of them. Part of the loss is stylistic too. What happens if the thing you fell in love with was writing code itself? Making dumb variable names. Refactoring. Trying to get code to compile. The dopamine hit when it finally does. When the test passes. When the div is centered on the page. Some of that is starting to go away now. So when we see that not all engineers are racing to adopt AI, maybe some of those engineers aren’t resisting AI. They’re adjusting to the realization that the work they spent years learning to do well is no longer the work being asked of them. 

That’s not resistance. That’s coherence.

It’s also organizational whiplash. And managers are the translators of that whiplash.

The hardest part of managing engineers through AI isn’t choosing tools. It’s helping people navigate the moment when the way they learned to be excellent stops being the way they’re asked to work. My job isn’t to convince engineers AI is good. My job is to help them move through the transition without losing their sense of competence along the way. And once they get through that transition, I’ve seen those same engineers become some of the strongest adopters. When they start using AI at the level of systems and architecture instead of just code generation, the hesitation usually disappears.

Transitions like this don’t just change workflows. They change how engineers measure themselves. Managers have a responsibility to recognize that shift, name it when it’s happening, and help people move through it without treating hesitation like failure. The engineers who learn to work this way won’t be the ones who abandon craft. They’ll be the ones who redefine it.

Promotions Aren’t a Scorecard

I’ve spent years thinking about promotions from both sides, working toward them myself and later supporting engineers through them as a manager. One thing that’s always surprised me is how little most people understand about how promotion decisions actually get made.

Don’t let anyone sell you the lie that titles don’t matter. Promotions matter. They affect compensation, responsibility, recognition, and sometimes access to rooms whose doors were previously closed to you. And yet most of us don’t understand how they work—not just inside our own companies, but as organizational decisions at all.

Promotions aren’t scorecards. They’re system decisions shaped by impact, business need, and available budget.

Impact is the piece you have the most control over. It’s also the piece most people are familiar with, though often not in the way organizations actually evaluate it. Impact is not simply the work you get done. Your work will not speak for itself. Instead, your work needs to make an impact - on people, on systems, on outcomes. If your work leaves no impression behind, it effectively didn’t happen. And that’s where I’ve seen a lot of talented people spin their wheels. People who are constantly busy or working so hard and don’t understand why it’s not enough. Maybe it is enough effort but misplaced. Your work needs to meaningfully connect to your career ladder. What is your org looking for in terms of impact? Are you delivering 1:1 results when your org is expecting you to scale your impact 1:N? 

Impact alone isn’t enough. Promotions only happen when the organization needs more people operating at the next level. Sometimes this is obvious. New scope appears, teams grow, or priorities shift. Sometimes it’s less visible. An organization may already have enough people operating at a given level for the work it needs to do right now. This can be one of the hardest parts of promotions to accept because it’s the least personal. You can be ready and still need to wait for alignment between your growth and the organization’s direction.

Budget is the third factor. Promotions change compensation, and compensation lives inside planning cycles whether we like it or not. That doesn’t mean promotions are arbitrary. But it does mean timing isn’t always fully flexible. Sometimes strong promotion cases wait for the next cycle simply because organizations make compensation decisions in batches rather than one at a time. I learned this lesson myself when I was working toward a Lead Engineer promotion. I had the impact and the support, but what I didn’t understand at the time was the role the budget played. Others were ahead of me in the promotion queue that cycle. So I kept expanding my scope and visibility. By the time I came up again for the next round, I had support from multiple senior engineers, architects, and even a VP from another pillar asking the same question: how is Liz not already recognized at this level?

This lack of understanding doesn’t just affect individuals. It also affects managers supporting someone through the promotion process. ​​Many managers are unprepared for how little control they actually have over the final promotion outcome. As a manager, you’re not responsible for driving someone else’s career. Managers create the conditions that make growth possible.

From the manager's side, promotion advocacy depends heavily on credibility. Over time, it becomes harder for a manager’s promotion recommendations to carry weight if they repeatedly put forward cases that aren’t aligned with organizational expectations.

If you only control one third of what makes a promotion possible, it’s dangerous to tie your professional identity entirely to achieving one. That can be infuriating and demoralizing. So you focus on what you can control. You can control opportunities, alignment with expectations, visibility of your work, and readiness for the next level. If you feel like you’re sprinting toward promotion and things will slow down afterward, think again. That pace becomes the new baseline.

Promotions aren’t scorecards. They’re decisions shaped by impact, business need, and budget. You control only one of those directly. So focus there.

Leading the Work You Didn’t Choose

A few years ago an engineer who was considering the path to management asked me if they could pick my brain about being a manager. I was flattered. It was the first of what would become many conversations I’d have on that topic. The conversation started off great with discussion about the usual early management ideals of servant leadership and wanting to pursue new and exciting challenges. But the part that got me, and the part I’ll never forget, is when this person said to me, “I just want to finally be able to say no.” I almost laughed. Honestly, I might have. “I never get to say no,” I said to the person staring at me in shock. I had to explain to them that saying “no” is rarely an option available to managers in the way people expect.

Here’s the thing this person didn’t yet understand, and it’s something that tends to shock a lot of people when they become managers: Managers don’t gain control. They inherit responsibility for decisions made elsewhere. Most management starts with decisions you didn’t make. 

You either learn this lesson quickly or spend a lot of time fighting decisions you have no control over. The harder part isn’t realizing that. It’s learning how to lead once the decision is already made. In the conversation I had that day, I believe I compared it to improv (thanks Tina Fey’s “Bossypants”!) where the one rule is never to say no. You can say “yes and” or “yes if” or “okay but.” If you had asked me then whether I understood what it meant to not say “no” as a manager, I would have said yes. What I didn’t understand yet was that leadership doesn’t stop when the decision is made. That’s when it starts.

A few months after that conversation, surprising for them, memorable for me, I had just come back to work after my first parental leave. I was adjusting to a whole new role in life, being a mom, and to a team that had changed in my absence. New people had joined the team, others had grown into new roles, features had shipped. Time had continued moving while I was out. I was determined to prove to everyone, including myself, that “I’ve got this.” I was back just in time to finalize the team’s annual roadmap and kick off the new fiscal year. Everything was going great. Look, I could do all the things. But we were only about one month into that roadmap when I got the news. Priorities in the org had changed, and everyone across engineering needed to support them, including my engineering team. Three major initiatives didn’t have a home yet. My team, which was considered more of a supporting team to the core product, would need to take one on. To his absolute credit, my director at the time asked me if I had a preference which one my team took. I asked for a day to bring it to the team.

When I spoke to my team, I didn’t try to sell the change as exciting. I told them the truth. This upheaval wasn’t what anybody asked for. We were all disappointed to see such a radical change to our plans, a major postponement to features we were excited to build and tech debt we were finally going to pay off. But one of three projects in particular had caught my eye. No one in the entire engineering organization had implemented it yet. It was new to everyone, which meant that if we pulled it off, not only would we have delivered an important feature but we’d have shown everyone that it didn’t matter if our team’s expertise lay outside the core product. We were great engineers. Period. If we succeeded, the org wouldn’t remember that we hadn’t chosen the project. They would remember that we delivered it.

That framing mattered more than I realized at the time. I wasn’t trying to convince the team the roadmap change was good news. I was trying to preserve agency inside a decision that had already been made.

And the team agreed. We chose that project, the one that was scary and full of unknowns but also full of opportunity. After nine months and many important lessons later we delivered it - on time! It was an incredible win: for the engineers, for myself, for the company. Handing the feature off to the team who would own it long term was actually incredibly bittersweet for all of us. Somewhere along the way it stopped being the initiative we were assigned and became our project. That was the real success for me as their manager. Not choosing the work. Helping the team make it theirs.

Back when I spoke to that engineer who thought management meant finally being able to say no, I wished they were a little bit right. When my director told me about the change to our roadmap I wished really desperately that I could just say no. But that isn’t the job. Management is not about authority. It’s about stewardship of decisions you didn’t make. Engineers often assume managers choose priorities, approve work, and control direction. Sometimes that’s true. But managers also translate decisions, align teams, absorb disappointment, and create momentum anyway. 

One of the hardest parts of management is enforcing decisions you didn’t make. One of the most important parts is helping your team succeed anyway.

I couldn’t change the decision to upend our roadmap. But I could change how we entered it.

From Servant Leader to Situational Leader

I used to describe myself as a servant leader, and at the time, it was true. This was early in my management journey when I was a new manager, and even before that when I was an engineer with aspirations toward management. Before becoming a manager, my influence on the team was purely without title. My goal was to elevate the engineers around me, to see the team succeed, to improve how we worked as much as what we were building in code each day. It was pure. The servant leader ethos fit. And I think that’s true for a lot of engineers who become managers. Servant leadership fits most engineers pre-management precisely because they experience influence without authority, credibility through contribution, helping teammates succeed, and aligning with engineering culture.

Over time, I evolved as a manager. As much as my goal was still to help the engineers on the team and enable them to be their most impactful selves, I suddenly had other goals too: deliver an incredible roadmap, structure the team to support their growth and my own, and show leadership I was capable of matching (or even exceeding) their expectations. Managers serve multiple stakeholders, not just our teams. We serve our team, our roadmap, and our organization, and those constraints shape nearly every decision we make.

And here’s the kicker: servant leadership alone doesn’t resolve conflicts between them. At some point, every engineering manager discovers this the hard way.

When I became a manager, the narrative I had told myself about being a servant leader started to create tension with the role I was now expected to embody. Often I couldn’t even define what that tension was at the time. I was naive and slightly moralistic. I assumed senior leadership didn’t care about my team as much as I did. What I didn’t yet understand was that their responsibility extended far beyond my team alone.

As I managed my first team, I only made changes by “nudging”. Nothing dramatic, nothing sudden. Everything had the support and full buy-in from the team. It’s the approach I had used as a team lead when I didn’t have authority to operate differently. I was playing it safe because it’s all that I knew at the time, and I prioritized the team’s immediate comfort over the deeper changes they actually needed.

With my second team, they were in a very different position when I took over. They had a lot of broken processes, zero trust, and change-fatigue. If I tried to nudge them in the right direction it could take years, and I’d lose the trust of my director in me that I was in fact capable of managing the situation. So I took a different approach. I made a series of sweeping changes. I called it a level set and explicitly told the team that they could (and should) iterate on each of those changes but we needed to start from a healthier baseline than the one we were currently operating at. 

I was terrified. I was a dictator! They would hate me. Instead, the only engineer who strongly resisted the reset was someone who ultimately wasn’t a fit for where the team needed to go. Everyone else adapted, the team did iterate, and by the end of the year we were the highest delivering team in the subdomain.

I didn’t stop being a servant leader. I stopped believing servant leadership alone was enough. 

It wasn’t until a few weeks ago that I could even properly articulate that I had made this evolution. I participated in a discussion where a group of engineering leaders were asked about their style of leadership. People gave various responses and the facilitator said something along the lines of, “I’m so glad no one said ‘servant leader.’ You wouldn’t believe how often we get that as the answer.” I realized servant leader had been the phrase floating in my own mind as the one I used to identify with, but I didn’t say it out loud because I knew it no longer fit. I just didn’t know what else to call myself. I also didn’t feel comfortable abandoning the principles of servant leadership which were a real guiding principle of why I got into management. 

The more I reflected on it after that conversation, the more I realized that servant leadership is incomplete as a default operating model for engineering managers. Servant leadership describes intent. Situational leadership describes execution under constraint.

The shift wasn’t about abandoning the values that brought me into management. It was about learning when those values needed structure, direction, and sometimes decisiveness to actually serve the team.

The goal never changed. The way I had to lead did.