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 architectural change, the numbers looked identical. Output has never been a great signal — AI just made that harder to pretend otherwise.

You can have two engineers shipping similar amounts of work and operating at completely different levels.

One uses AI to move faster but validates decisions and simplifies the design. The work holds up. The other 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.

The hardest part isn’t even the obviously bad code. It’s the work that looks reasonable - clean PRs, passing tests, sensible structure - but work that’s built on shallow understanding.

I’ve seen this show up in moments of discovery where an engineer will use AI to explore a problem space and come back with a long list of possible issues and directions. It looks thorough and it sounds informed. But without deeper judgment, that list can turn into rabbit holes that don’t actually matter.

I’ve even felt this myself. 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. I use these tools too, but as a manager, I’m often in situations where I have to rely not on my own ability to use them but on my engineers’. I’m one degree removed, which puts a lot of trust in a skill we’re all still figuring out.

With AI, you can have similar output and very different depth. 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 seen the opposite too.

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.

For a long time, managers have used output as a rough proxy for capability. It was never perfect, but it mostly worked.

It works a lot less reliably now, which means the job of being a manager changes.

Now managers have to evaluate the things that are harder to see: 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.

Testing, observability, and guardrails matter more but as system support, not as a replacement for judgment.

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, you have to get better at seeing what actually matters.

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.

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.