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.