Rethinking Performance Management: From Annual Reviews to Continuous Growth

After implementing agile performance management practices, I started noticing something uncomfortably familiar. We had replaced annual reviews with weekly check-ins, but the check-ins were becoming status updates. Continuous feedback became a stream of minor corrections. Recognition systems started looking like popularity contests. We had made performance management more frequent. I wasn't sure we had made it more useful.

It reminded me of : changing the calendar was easier than changing what we were paying attention to. We still spent much of our time asking how well someone was performing, and much less asking what would help them get better.

That distinction has shaped my approach since. But it has also left me with a tension I cannot resolve just by calling myself a coach. I still have responsibilities around expectations, promotion, compensation, and difficult employment decisions. A useful performance system has to make room for development while being honest about that authority.

What frequent conversations changed

The move toward regular conversations was useful. A problem could surface while there was still time to help. A contribution could be recognized while everyone remembered it. Goals could change as the work changed, instead of waiting for the next review cycle.

Weekly or biweekly one-on-ones remain the foundation of my approach. I want to understand what someone is trying to do, where they are stuck, and what help they need. The cadence creates an opportunity to talk; it does not guarantee that we will talk about anything important. If every meeting is a tour of the task board, development still gets postponed.

Adobe provides a useful example of how this can evolve. It replaced annual reviews and ratings with Check-in in 2012. Its current approach combines quarterly conversations, ongoing feedback, documented goals, and career discussions. Managers still make compensation decisions based on performance. Removing an annual rating did not remove the need to exercise judgment. ¹

I also want a view of work that extends beyond the reporting line. Someone may make their most useful contribution in a temporary project team, by helping another team, or through work their manager rarely sees. Peer feedback can reveal that contribution. It needs concrete examples, though: the number of people willing to give someone kudos is a poor substitute for understanding what they did.

Moving from a verdict to a development plan

The questions that changed things for me were practical: what capability is this person trying to develop? What can they already do? What is getting in their way? Where will they get a chance to practice?

I revisited because its combination of a current condition, a next target condition, and small experiments gave those conversations structure. Applied to people development, this is an adaptation of the practice. The person needs a say in the direction, and the manager needs to examine the conditions around them. A missing skill, an unclear brief, and a lack of authority call for different responses.

Each person I work with has an individual development plan built around a specific capability. The horizon is usually one to three months, with smaller steps along the way. That is a planning choice, not a deadline by which everyone must develop at the same speed.

Here is an illustrative example, rather than an account of a particular employee:

The manager's contribution matters here. They may need to make the decision owner explicit, provide commercial context, or protect time for practice. Giving someone a development target without making those conditions possible is just another way of assigning them a problem.

I use work patterns to guide these conversations: where someone repeatedly gets stuck, where knowledge is missing, or where a handoff becomes difficult. The point is to identify something we can investigate. A slow project does not, on its own, tell me that a person is slow or incapable.

Coaching questions, with direct feedback

I've moved toward asking more questions before offering my interpretation:

• What were you trying to achieve?
• What happened, and what surprised you?
• Which obstacle are you working on now?
• What would you try next, and what help do you need?

These questions give someone room to explain their reasoning and notice things for themselves. They also expose gaps in my understanding. I may be reacting to a decision without knowing the constraints under which it was made.

But questions cannot do every job. If I have observed a problem, know an expectation was missed, or hold information the person needs, I should say so clearly. Asking someone to guess the criticism in my head is not coaching. I try to describe the situation, the behavior, and its impact, then invite their account of what happened. We can be direct without turning an observation about work into a judgment about someone's character.

The research is a useful check on the assumption that more feedback is always better. Kluger and DeNisi's meta-analysis found that feedback improved performance on average, but some interventions reduced it. That does not mean we should stop giving feedback. It means the content and the attention it directs deserve more thought than the number of conversations we schedule. ²

For a practical companion, Michael Bungay Stanier's offers a small set of questions for staying curious before rushing to advice. I would use it alongside clear expectations and specific feedback, rather than as a script that every conversation must follow.

Separating conversations without pretending they are unrelated

One of the most important changes I've made is separating regular development conversations from less frequent compensation discussions. I want a person to be able to examine an unsuccessful experiment without having to turn it into a promotion argument halfway through the conversation.

There is a limit to that separation. The same manager may coach someone today and contribute to a promotion decision later. Business impact and scope of responsibility still matter to compensation. I cannot promise that everything learned in a coaching conversation is irrelevant to those responsibilities, or declare the conversation psychologically safe on the other person's behalf.

What I can do is make the purpose of each conversation clear. A development discussion should help us choose a capability to practice and support that practice. An evaluation should explain the expectations, evidence, context, and decision. When a performance concern has consequences, it needs to be stated directly, with a clear opportunity to respond and an explanation of what support and follow-up are available.

I also need to distinguish a person's contribution from the outcome around it. A sensible decision can produce a disappointing result. Someone can do excellent work on a project whose premise was wrong. Conversely, a successful launch can conceal unsustainable practices or work other people had to repair. Reviewing the reasoning, collaboration, and constraints alongside the result gives us more to discuss than a success label.

This is why I no longer find “coach, not judge” a complete description of management. Coaching is a substantial part of the role. Fair, transparent judgment remains part of it too. The responsibility is to prevent the second from swallowing the first, and to make neither a surprise.

Making expectations visible

Another problem I encountered was the assumption that everyone already knew what good performance meant. In knowledge work, expectations can stay implicit until someone fails to meet them.

I invest time in defining useful examples of work, sharing exemplars with permission, making decision responsibilities explicit, and discussing the trade-offs a role is expected to handle. Those examples need room for different working styles. They should help someone understand the expectation without requiring them to imitate the most visible person on the team.

Peer learning helps with this. I facilitate sessions where people share what they are working to improve, an experiment they tried, and what they learned. This is related to : an artifact gives other people something concrete to question and build on. Inside a team, the audience can be small, and people should have a choice about sharing sensitive developmental work.

Opportunity also belongs in the discussion. Before concluding that someone lacks influence or scope, I need to ask whether they have been given access to the relevant work, decisions, and relationships. A framework that recognizes only highly visible projects will miss maintenance, mentoring, and problems prevented before they became incidents.

The framework I used, and its limits

In teams I managed, I used a framework connecting contribution, scope, development, and compensation. The policy language from that period emphasized strong market pay, challenging work, capable colleagues, context for independent decisions, and promotion when someone was already handling broader responsibility. It also said that people who were no longer effective would leave.

That is a description of a past framework, not a current compensation promise. Similar principles are set out in Netflix's culture memo, including personal top-of-market pay, context for decision-making, and its keeper test. Netflix's account also describes considering someone's whole record and supporting people through short-term setbacks. These are choices about running an organization, not evidence that every organization should make the same choices. ³

The part I still find useful is the link between development opportunities and real responsibility. The part that needs care is how easily “impact” becomes a confident-sounding replacement for a rating. Who decides what counts? Which outcomes could the person influence? Did the business change around them? A compensation philosophy does not answer those questions for us.

One scale, different contributions

The six-level model below is adapted from Elliot Graebert's impact-based level system. It moves from well-defined tasks toward responsibility spanning teams and the company. The useful idea is that technical and people leadership can contribute at comparable scopes. The level names are local shorthand, not universal job titles or a validated measure of someone's value. ⁴

The illustration pairs each scope with examples of contribution, evidence to discuss, support, and a small development experiment. These are starting points for a conversation. Staying and deepening your contribution at a suitable scope is a valid career choice. Broader responsibility needs an opportunity and a desire to take it on; it is not the only form of growth.

Will Larson's is a useful companion here. Its show several ways to contribute through technical leadership: coordinating a team, shaping architecture, solving a difficult problem, or working across an organization. That is a better starting point for discussing an IC's growth than treating their personal code output as the whole contribution.

The model also needs a business context. A small company may not have a distinct role at every scope. If the organization changes, expectations should be reviewed and explained; a headcount threshold does not automatically justify changing someone's level. Scope can inform a compensation band, while market conditions and the organization's stated pay policy also matter. None of that makes a level an objective score.

Using it in a real conversation

In the framework I ran, we discussed the ladder in one-on-ones and used peer committees for progression decisions. Peer review broadened the perspective, but a committee still exercises judgment. It needs shared criteria and concrete evidence, including the person's own account and feedback from people who saw the work.

I would use the illustration to start a conversation about the contribution someone is making now, which parts they want to deepen, and whether they want broader scope. From there, we can identify an opportunity to practice and agree how we will review it. It should also be possible to discuss an equivalent contribution the examples missed.

When there is a gap against expectations, the next question is what explains it: skill, context, workload, authority, support, or a mismatch with the role. Clarify that before deciding on a response. Coaching does not remove difficult decisions, but an unsuccessful experiment should not silently become a verdict on the person who tried it.

Where that leaves me

My thinking has followed a similar path to my experience with agile practices. I started by questioning annual reviews, introduced more frequent conversations, then found that frequency had left some of the old problems intact.

I still want performance management to be an ongoing conversation about learning and work that matters. I am less comfortable claiming that a framework can make that happen for us. It depends on what we notice, what we make explicit, the opportunities we provide, and how we use the authority we hold. Those are the things I want to keep improving, one conversation at a time.