Most managers set goals at the start of the year, file them away, and rediscover them during performance review season. They’re written in isolation: personal development targets that float in space, disconnected from anything the company actually cares about.
Then review time comes. A manager sits across from their skip-level and tries to make the case for someone’s promotion. And the question they can’t answer is: what did this person actually contribute? What problem did they solve that the organization felt?
The managers who can answer that question don’t get lucky. They built the answer throughout the year: one goal, one accomplishment, one aligned opportunity at a time.
Start with the company’s goals, not the individual’s
Most managers make the mistake of starting goal-setting with the person in front of them. What do you want to work on this year? Where do you want to grow? Those are fine questions, but they’re the second questions, not the first.
The first question is: what is this company trying to accomplish this quarter? What are the OKRs? What has the product org committed to? What does the broader engineering organization need?
When you start there, you create a map. And on that map, you can find the places where your team member’s growth and the company’s goals overlap. That overlap is where the most powerful goals live.
“The best goals don’t just grow your person; they show the organization exactly what your person is worth.”
I’m always looking at our quarterly goals. Most companies run on quarterly cycles, and my team is usually working alongside a product manager or a larger engineering organization that has their own commitments. Finding ways to tie individual contributions into those commitments isn’t just good for the company; it’s good for your person. It makes their work visible at a level that individual task completion never will.
Two categories of accomplishments: track both
Throughout the week, I’m constantly taking notes on what my people are doing. Not just the deliverables: the texture of how they’re showing up. Over time, I’ve learned to track two distinct categories.
The first is job-specific accomplishments: the things someone is expected to do as part of their role. Features shipped. Bugs resolved. Code reviewed. These matter, and they need to be documented, but they’re the baseline. They don’t by themselves make a case for promotion.
The second category is above-and-beyond: the things someone did that weren’t in their job description, that created value outside their immediate lane, that showed they were already operating at the next level. This is the category that wins promotion conversations.
Most managers keep no record of either. Come review season, they’re working from memory, which means they’re working from recent memory: the last few weeks, not the last twelve months. The manager who has been tracking both categories all year walks into that conversation with receipts.
“If you can’t describe what your person accomplished this quarter in one sentence that connects to a company goal, you haven’t been paying close enough attention.”
Create visibility, don’t wait for it
One of the most underutilized moves in engineering management is the visibility play. Your team member is doing good work. But good work that no one outside your team sees doesn’t build a reputation. And in most organizations, promotion decisions are made by people who have never directly observed your team member’s work.
So you create the visibility for them.
I’ve seen this work in a simple, practical way. Across most engineering organizations, there are shared resources that are perpetually under-maintained: shared UI libraries, common utilities, internal tooling that multiple teams depend on but no single team owns. These are opportunities.
I’ll tell one of my engineers: go work on that shared UI library. The one that three other teams are using. Find the gaps, make the improvements, open the PRs. Get your name in that GitHub repo so that when other engineers and engineering managers look at who’s contributing, they see you. Start reviewing PRs from other teams. Show up in the places where visibility happens.
This isn’t politics. It’s professional presence. The engineers who get promoted aren’t always the best coders in the room; they’re the ones whose work is seen and whose names are known. You can help your people get there.
Understanding the 9-box: selling your people when it counts
Most companies use some version of the 9-box framework when evaluating talent. The grid plots Performance on one axis and Potential on the other. Where someone lands in that grid shapes how leadership thinks about them: whether they’re promotion-ready, flight risk, or someone who needs development before the next step.
As a manager, your job isn’t just to develop your people. It’s to be able to make the case for where they belong in that grid, and to do it with evidence, not just enthusiasm.
Good goals and documented accomplishments are how you build that case. When you’ve been tracking contributions throughout the year (job-specific work and above-and-beyond moments, individual achievements and contributions to company priorities), you can walk into a calibration session and tell a story. Not just “she’s been doing great” but “here’s what she shipped, here’s the cross-team impact, here’s where she operated above her current level.”
The standard bar in any good engineering organization is always rising. What counted as senior-level work two years ago may be mid-level work today. Knowing where that bar is, and being able to show that your person is meeting or exceeding it, is a core part of your job as their advocate.
“Your job isn’t just to develop your people. It’s to make sure the organization sees what they’re worth.”
Constructive feedback: the first step after a setback
Constructive feedback has a bad reputation because most managers deliver it wrong. They frame it as correction: here’s what you did wrong, here’s what you need to fix. The person on the receiving end hears: you failed, and I’m here to tell you about it.
That’s not constructive feedback. That’s just feedback with a polite label.
Real constructive feedback isn’t about the failure. It’s about the next move. It starts from the assumption that this person is capable of growth, that the setback is a data point not a verdict, and that the right question isn’t “what went wrong” but “what would you do differently?”
It sounds like: “Was that the outcome you were looking for?” Let them answer. Let them sit with it. Then: “What would you try differently?” You’re not pointing to the problem; you’re pointing to the growth.
This is where the growth mindset shows up in practice. A growth mindset isn’t a platitude you put on a slide. It’s the belief, modeled by you in these conversations, that the first move after a failure is always a positive one. That you roll with the punches. That you don’t stay on the ground.
“Constructive feedback isn’t about what someone is doing wrong. It’s about where the growth is.”
When that becomes the culture of your 1-on-1s, when your team member knows that coming to you with a failure won’t end in a lecture but in a forward-looking conversation, they’ll start bringing you their failures earlier. And that’s when you can actually help.
Key takeaways
- Start goal-setting with the company’s quarterly priorities, then find where your person’s growth aligns. That overlap is where the best goals live.
- Track two categories of accomplishments weekly: job-specific contributions and above-and-beyond moments. Both are essential for the promotion conversation.
- Create visibility for your people. Shared libraries, cross-team PRs, and active GitHub contributions build the professional presence that promotion decisions are made on.
- Understand the 9-box framework. Your job is to build the case for where your person belongs, with evidence, not just enthusiasm.
- The engineering bar is always rising. Know what “good” looks like at the next level, and help your person get there visibly.
- Constructive feedback points forward, not backward. Ask “what would you do differently?” not “what went wrong?”
- Model a growth mindset in every feedback conversation. The first move after a setback should always be a positive one.