Thrive as a manager: build your own scoreboard

What I learned going from senior engineer to Head of Technology

This post was originally written for Thriving In Engineering. Thriving In Engineering is a publication by Alex Ponomarev, who has spent a long career in software engineering, leading teams and organizations. Alex writes weekly about management, technology, career growth, and AI. If you are not a subscriber yet, go and check out Alex’s work.

I felt uneasy. The CEO just offered me the team manager position. I had joined the company a few months ago as a senior software engineer, planning to decompress after leading too many projects at my previous place. Just write some code for a while.

Now what? Not only projects, but people?

I hesitated, but agreed anyway. What followed was the steepest learning curve of my career. Here is what I learned about what “good” looks like when you become a manager.

Today, I manage a team of teams — working as CTO.

I write High-Impact Engineering — a weekly newsletter for engineering managers, directors, and CTOs. In today’s issue, we will talk about the manager’s definition of success.

We don’t solve tasks, we provide value

A software engineer’s scoreboard is relatively simple. It is mostly about building and fixing things: complete a task, deliver a feature, fix a production incident. For more senior engineers, it may also include helping more junior colleagues. It is clear, visible, and everyone — including you — knows how to measure it.

When a developer moves to management, as I did, they step into a much more complex world. Yes, the manager can have OKRs and KPIs, but that is only a part of the story.

We are not building things anymore. We are delivering value.

The more senior you become, the more the balance shifts from deliverables to value.

The tricky part is that sometimes there is no clear definition of the value, or it is obscured.

Your business stakeholders ask you for faster feature delivery, but what they really want is to sell more and happier clients who will not churn.

You are asked for velocity metrics, but what they really want to know is if they can trust me to deliver.

They ask for a feature, but what they really want is to put their foot in the door for a new customer segment.

Sometimes the value is as simple as the delivered feature. For example, your main stakeholder is a technical manager who is held accountable to deliver a certain functionality by a certain date.

But sometimes the real value you should optimize for is not a feature or a number. It is a large B2B contract, or the client’s trust.

To be effective, we need to understand what value actually means in our context — and then find a way to deliver it. Otherwise, we can burn ourselves and our team out and still not move the needle on what matters.

I made these mistakes many times. I focused on shipping instead of solving the actual problem. I took long, complicated routes when I just needed to step back and understand what value I actually needed to create.

A few questions to ask yourself:

• Do I know what I am measured against?

• Am I optimizing for metrics or impact? Is there a difference?

• How am I tracking towards creating the value I expect?

You are not one of them anymore

When you become a manager, your primary team changes.

It was an essential shift for me, the one that was difficult to wrap my head around. As a senior engineer, my peers were the developers I worked with every day. I continued working with the same team, but the perspective has flipped.

As a manager, my primary team became the other managers and cross-functional leaders. When I say “my team” now, I mean that group — not my direct reports. Together, we create value using the combined strength of our teams.

This might feel strange at first. The engineers are the people you know best, the people whose respect you earned through technical skill. But your job is no longer to be one of them. It is to represent them to the organization and bring the organization’s context back to them.

Your job is to make them effective and productive, not to make friends or be liked.

It sounds harsh. But optimizing for the team’s “well-being” — and I put that in quotation marks deliberately — does not serve you or your team. A high-performing, happy team does not require artificial harmony, office perks, or being “a family.” It requires psychological safety, fairness, an appropriate level of challenge, and a feeling of being on a mission.

Sometimes that means having hard conversations. Giving uncomfortable feedback. And sometimes, firing people who are dragging the team down.

None of these is pleasant. But avoiding them has consequences. Team performance drops, delivery suffers, good people lose motivation and leave. The team is silently expecting you to do your job — even when your job is the uncomfortable thing. Not everyone will like your decisions. They don’t have to. You are not a buddy, you are a leader.

Questions to ask yourself:

• What is my main team, honestly?

• If choosing between being liked and being effective, what would I choose?

• Am I avoiding something that needs to be done because I fear the conflict?

Stop chasing instant gratification — it is a long game

Be honest. Are you the smartest person in the room who always has the final say on all technical questions?

If the answer is yes, you are the bottleneck.

I know how it feels. You spend a day in meetings, one-on-ones, and status updates, and by the end of it, you have nothing to show. No code written, no bug fixed, no pull request merged. It doesn’t feel like work.

So you stay late and write code. There is always a challenging project that would benefit from an additional couple of hands. In reality, you’re chasing the instant gratification that the new job doesn’t provide.

The most impactful part of the manager’s job is growing people and developing the team culture. Both are slow. You plant seeds, water them. It takes months, sometimes years.

A junior engineer who couldn’t own anything six months ago now runs a feature end-to-end. A senior engineer who used to escalate every cross-team conflict now handles it themselves. That is your work. You just don’t see the results for a long time.

I struggled with this. On the days I wrote code, it instantly felt good. On the days I spent enabling others, I felt I didn’t achieve anything. It took time to accept that the “useless” days created more impact than any resolved ticket or fixed bug.

The shift is this: instead of “what did I build today”, ask “what did I enable today”? A decision that was stuck for a week that you resolved in one conversation. A blocker you removed before the team even noticed it. A person who grew because you gave them the space to.

If you still have time after doing everything only you can do, then code. But be honest about the priority.

Questions to ask yourself:

• Am I doing things only I can do, or am I playing the hero?

• What would happen to the team if I stopped coding entirely for a month?

• Am I measuring my day by what I built, or by what I enabled?

See the system beyond tasks

When things were on fire — production issues, missed deadlines, pressure from all sides — I jumped in. Fixed bugs myself. Helped with code reviews. Unblocked tasks by doing them.

It felt productive. But I was solving individual problems instead of stepping back and looking at the bigger picture.

The manager’s job is not to know every technical detail. It is to see where work gets stuck.

Look at the board. Not at individual tasks — at the flow. Where do things pile up? Where do they wait? Is it waiting for a decision from product? Waiting for a code review? Waiting for another team’s input? That is where your attention belongs.

One thing I noticed when I shifted my focus from the details to the flow was that some of the “technical” problems disappeared. They were never technical to begin with.

My failure to proactively communicate project status almost cost me my position. The project I was leading was late. I knew it, but I was confident we could recover. What I didn’t do was make sure the right people knew where things stood. When the delay surfaced, it came as a complete surprise to leadership. I looked like I had been concealing the problem. I hadn’t — but the effect was the same.

The failure went deeper. The team was working without the full picture. I was passing down tasks without sharing why they mattered, who they were for, or what was at stake. I thought I was keeping things simple. I was leaving the team without the context they needed to make good decisions.

I was failing in both directions at once — and I didn’t see it until the damage was done.

The fix was deliberate. I started gathering context from above and across the organization and making it visible to the team. I made sure stakeholders knew where we stood and what was coming before they had to ask. When the team had the full picture, the solutions they came up with got better. The pressure to deliver subsided.

I wrote about this communication framework — what I call pull, push, and translate — in more detail here.

Questions to ask yourself:

• Do I read all the tickets for details, or do I look at the board to see where work gets stuck?

• Does my team have all the information it needs to do its work well?

• Do stakeholders understand where the team is and what happens next?

Manager’s scoreboard

When you become a manager, you need to build a new scoreboard for yourself. It has four components: value, leading beyond your team, team development, and team enablement. The weight of each will be different in your context, but all are necessary.

Without it, it is easy to fall into traps that feel like doing the job but aren’t:

Delivering all the features on time, but the product is closed, and the team is made redundant.

Being afraid to challenge bad behavior in the team, keeping the artificial harmony, until no one cares, and people start leaving.

Staying all night fixing bugs, but failing to move the unrealistic deadline that created these bugs in the first place.

The good news — now you know what the scoreboard includes. You know what to optimize for. You know which questions to ask yourself. And unlike the engineer’s scoreboard, nobody will hand this one to you. You have to build it yourself.

Go back to the questions in each section. Pick the one that resonates most. Start there.

If this was useful, subscribe to get one practical lesson on engineering leadership every week — plus my free Process Experiment Template the moment you sign up.

Share this with a colleague who just stepped into a leadership role. This is the stuff nobody teaches you.