In Module 2, I talked about how a meaningful performance review starts with well-defined goals and how those goals cascade down – from strategy, through company and team objectives, right into the daily work of individuals.

This module is about the practice. Goal problems usually surface at two specific moments: when you first set them, and when you sit down for a review several months later and realise they've completely stopped reflecting reality.

Projects shift. Clients change their minds. Priorities move. Suddenly you're trying to run a review with nothing solid to refer back to.

This module covers three things: how to write goals you can actually evaluate after three or six months, how to assess them fairly when circumstances have changed, and how to avoid reviews that run entirely on memory and gut feeling.

Let's start with the obvious question: why do goals fall apart even when they seemed perfectly sensible when you set them?

Why goals go stale before the review cycle ends

In a fast-growing company, it's completely normal for reality to look different three months after you set goals.

A new client appears and half the team is suddenly working on something else. A project that was supposed to be strategic starts slipping. Someone key leaves. Or the exact opposite – a market opportunity shows up that wasn't in the plan and you have to move fast.

None of that is the problem. Change is a sign of growth.

Goals usually become misaligned for two reasons.

The first: goals have a shorter shelf life than the review cycle. In fast-moving companies, priorities can shift in four to eight weeks, while the review system operates as though the world stays constant for six months. The result is a review process that becomes a fiction. It assumes that goals set in January still reflect the job in June, with no mechanism for updating them in between.

The second: goals are written at too high a level, or they depend on things the employee doesn't control. When a goal says "improve quality" or "grow results" with no baseline and no clear measure, the first change in context makes it impossible to know what was actually expected. And if the goal depends on factors outside that person's control – client decisions, budget, leadership calls – you end up assessing circumstances rather than accountability.

The result: the company moves one way, the recorded goals move another. Not because people aren't working, but because the context shifted and the goals didn't.

How to write goals you can actually evaluate

Most problems with evaluating goal delivery start months earlier, with goals that were never precise enough to assess fairly.

A goal you can evaluate is one you can return to after several months and say, without debating interpretations: we're here.

This is what SMART is supposed to do. The problem is that in many companies, knowing the acronym doesn't change how goals actually get written. So instead of the acronym, here's what it looks like in practice.

Connect the goal to a real business outcome, not just activity. Activity tells you very little. "Worked on improving code quality" or "improved project communication" doesn't tell you whether anything actually changed. Compare that to:

• Reduced the number of bugs in the production environment by 40%
• Cut deployment time from three weeks to two
• Reduced post-sprint rework from 15 items to 6
• Increased team velocity from 28 to 35 story points

Those are concrete effects, not impressions.

Include a starting point. You can't talk about progress without knowing where you started. "Shorten project delivery time" sounds fine, but "bring it down from 14 weeks to 10" gives you something real to work with. Without a baseline, there's always room for "I think it's a bit faster."

Make sure the goal is within the person's control. A badly set goal for a salesperson: "Grow company revenue by 20% this year." Sounds ambitious. But if that person doesn't set pricing, doesn't influence marketing strategy, and doesn't choose which market segments to go after – you're effectively holding them accountable for leadership decisions and market conditions.

The same intent, set properly: "Increase average contract value from PLN 80k to PLN 95k by expanding services with existing clients." Or: "Improve conversion from 18% to 25% at the proposal stage."

Write it down. This sounds obvious, but in many companies goals live in conversations rather than documents. Six months later, everyone remembers them slightly differently. If something isn't written down, it's very hard to treat it as a solid reference point.

A goal that can be evaluated doesn't need to be complicated. It needs to be clear, measurable in a reasonable way, grounded in the business, and owned by one person. When those conditions are met, the review conversation stops being a debate about interpretation and becomes a conversation about facts.

And here's the thing: even a well-written goal can become irrelevant in a growing company. That's the next problem.

How to update goals when circumstances change

As I said at the start, in a growing company, change is normal. The problem isn't that a goal becomes outdated. The problem starts when you pretend it hasn't.

Goals aren't fixed contracts. They're tools. And tools can – and sometimes need to – be adjusted.

If the situation changed in March and the original goal no longer reflects reality, the sensible move is to update it. Openly, not quietly. Change the goal, clarify the scope, and record the new version.

A simple rule worth adopting: every quarter, go back to the goals and check whether they're still current. If the conditions have shifted, update them and record the new version. This keeps goals tracking the business rather than living their own separate life.

Many companies use OKRs for exactly this – quarterly reviews of objectives and key results that prompt teams to regularly check whether the direction still makes sense.

In the review conversation, you can then simply say: "We originally agreed on X. In March, when the project changed, we updated that to Y. Let's evaluate against the current version."

How to evaluate goals when the business conditions changed mid-period

Suppose everything shifted halfway through. The project got cut back, the budget shrank, the client changed the scope. The final result doesn't look like what you planned at the start. So what exactly are you evaluating?

You can't look only at the original outcome. You need to look wider.

First: did the person deliver what was actually achievable in the new conditions? If the scope shrank or the budget was cut, the end result will naturally differ from the original plan. The question is whether they did the maximum possible given those realities.

Second: how did they respond to the change? Could they reorganise, reset priorities, and propose solutions? The result is one thing. How someone operates under uncertainty says a lot about their maturity.

Third: communication. Did they flag risks early? Did they raise problems before they became crises? Did they take responsibility for the difficult conversations?

Consider this: at the start of a quarter, the team commits to delivering module X by the end of June. In April, everything unravels. The client changes the scope, the budget is cut, and a key developer leaves. The project wraps up in August, not June.

You have two ways to read that. Option one: "You missed the deadline – goal not delivered." Option two: look at what actually happened. Did this person replan the work quickly? Did they warn the client the deadline was at risk? Did they limit the delay? Did they protect the team from burning out?

It might turn out that the original deadline was already unrealistic given the scope change. Because of good decisions, the delay was six weeks rather than three months. The client stayed. The team held together.

Is that a failure? I don't think so.

In IT, project-based work, and production environments especially, this matters. Change isn't the exception there – it's the norm. The ability to navigate that changeability often says more about someone than a result stripped of its context.

Results goals and development goals: why you need both

A review that only looks at one type of goal is missing half the picture.

Results goals are hard data: revenue, margin, delivery timelines, error rates. They show whether the business is delivering.

Development goals are about building capability: implementing a new process, learning a specific skill, taking ownership of a new area, improving how the team communicates. They build the foundation for future results.

Most companies focus almost entirely on the numbers. Then they're surprised when someone is hitting their targets but leaving a trail of damaged relationships and operational chaos behind them.

A performance review is the moment to hold both together. Look at the numbers, but also look at how those numbers were achieved.

Three habits that keep reviews out of gut-feel territory

If you want to avoid reviews that start with "I get the impression" or "it feels like," you don't need a big transformation. You need a few consistent habits.

1. Short, regular check-ins. You don't need monthly deep-dives. Once a quarter, spend 15 to 30 minutes on three questions: what's going well, what needs correcting, and are the goals still current? That changes the quality of the later review conversation significantly, because you're not reconstructing six months from memory. You have continuity.
2. Write down key updates. Every time something changes – project scope, priorities, how a result is being measured – record it. What changed, why, and how you're now measuring progress. It takes a few minutes and saves hours of misunderstanding later.
3. Talk about facts, not labels. Instead of "I felt like you weren't very engaged," ask: what were the actual results? What do the numbers show? Which projects ran late, and by how much? The difference between "he's not engaged" and "three out of five projects missed the deadline by more than two weeks" is significant. The first is a judgement of the person. The second is a description of a situation and data.

To close

Goal-setting isn't about process tidiness. It's about how your strategy actually reaches the daily work of your teams.

When goals are poorly set, tension follows quickly. Employees feel they're being assessed unfairly because they're not sure what they're actually accountable for. Everything becomes "shared" – which in practice means nobody owns it.

And for a CEO, there's a third consequence: no data for decisions. Without solid reference points, calls about pay, promotions, and people development start resting on intuition. Intuition matters – but in a growing company, it can't be the only compass.