Module 1 / Lesson 2

Where to start: organisational readiness and communicating the decision

Let's clear up a few myths first. They circulate widely, and they're exactly why so many performance review processes fail before they even get started.

Myth 1: "Just copy what works somewhere else – my friend runs a 250-person company, let's do what they do."

That won't work. A 250-person company operates in a completely different reality. Different decision-making speed, different structure, different process maturity. The review system that works there today took years to build and has been adjusted at every stage of the company's growth.

Trying to transplant that into a smaller organisation usually makes it more rigid without making it better. Instead of supporting management, it adds layers of formality that slow down decisions and pull managers away from actually working with their teams.

In practice, it ends with conversations being cut short, forms filled out "to tick the box," and action items pushed to a "later" that never comes. A process designed to bring order becomes a burden.

Small companies have speed and flexibility as real advantages. The wrong review system can strip both away fast.

Myth 2: "Let's brainstorm – what questions should we ask, what scale should we use?"

This is usually the first instinct. It's also the wrong place to start. When you jump straight to questions and formats, you skip the thing that actually matters: what the process is supposed to achieve, and what decisions it's supposed to inform.

What tends to happen: you end up with a generic set of questions. The scale is "something." The questions are "universal." Conversations drift toward opinions rather than facts.

After a few review cycles, you realise the data is hard to compare, harder to act on, and the whole process hasn't changed how the company is managed. You have a pile of scattered answers that don't lead anywhere useful.

That's why the right starting point is always: what is this process actually supposed to support?

Myth 3: "Performance reviews are an HR thing."

Common assumption. Wrong assumption. When this belief takes hold, reviews end up completely disconnected from company strategy. They become an empty formality that exhausts managers and stresses employees.

Here's what happens when HR runs the process without active support from leadership: the focus shifts to forms, deadlines, and whether the process ran correctly – instead of what the conversations are actually supposed to produce. The outcomes from reviews have no owner on the management side. They're not tied to team goals. And they lose priority almost immediately.

Everyone in the organisation has a meaningful role in this process – more on that shortly.

The minimum conditions for reviews to be worth doing

So where do you actually start if you want to introduce performance reviews in a way that sticks? Three things matter most.

1. Are your goals connected to everyday work?

Without this, you end up in situations like this:

The development team spends several months polishing new product features because "it'd be nice to have them" and "clients might use them someday." Everyone's busy, tasks are closing, and the team feels like they're doing something meaningful.

The problem: the company's actual priority right now is delivering existing client projects on time, because delays are creating real business tensions. These new features aren't part of any contract. Nobody agreed on them with clients. They don't address any of the current problems.

Then the review conversation happens. The employee says, "I worked hard, I put in extra hours, I built things that matter." The manager thinks, "None of that moved us closer to our delivery goals." Without clearly cascaded objectives, these two views never meet. What should be a useful conversation becomes frustrating for both sides.

How to actually cascade goals into daily work

Your company probably already has a strategy and annual objectives. The most common failure point in performance reviews is that those objectives stop at the top level and never get translated into what specific teams and individuals are actually responsible for.

Before you roll out reviews, check these five steps:

  • Step 1: Confirm the company has a defined strategy and goals that flow from it.
  • Step 2: Confirm every department manager knows and understands those goals.
  • Step 3: Confirm every manager has worked with their team to define department-level goals that support the company goals.
  • Step 4 (optional): Confirm that each employee has had a conversation with their manager about how their daily work contributes to the department goals. Not mandatory, but it helps people understand the actual connection.
  • Step 5: Confirm every goal at every level has measurable key results attached to it.

If this feels incomplete in your organisation – that's normal, especially for companies that grew quickly or are still structuring their processes. For small and mid-size teams, OKRs work well here. Measure What Matters by John Doerr and High Output Management by Andy Grove are both worth reading if you want to go deeper.

2. Does everyone know who's responsible for what?

Even with clear goals, you can still end up in a review conversation where you tell someone, "That was your responsibility," and they genuinely believed someone else was handling it.

Before introducing reviews, it's worth making sure roles and responsibilities are actually clear. Two tools help here – both simple enough for a smaller organisation:

Job descriptions

, in their basic form, define four things: the purpose of the role, areas of responsibility, specific tasks, and key results.

  • The role purpose should be one clear sentence that gives the person a direction for decisions and priorities.
    • Bad: "Active support of sales activities and building client relationships."
    • Good: "Generate new revenue by acquiring clients and growing existing accounts, while maintaining high service quality."
  • Areas of responsibility define exactly what the person owns day-to-day and where they make decisions. They're what prevents "I didn't think that was mine."
    • Bad: "Supporting the company's sales activities."
    • Good: "Delivering against quarterly and annual sales targets as defined in the Sales Plan 2025 document."
  • Key results answer the question: how will we know the role purpose is being achieved? These should connect directly to the objectives you defined earlier. The whole thing should work as one coherent system.
    • Bad: "Active selling."
    • Good: "Average monthly transaction value: minimum PLN 25,000 net."
  • Job tasks are the one area worth handing to the employee to fill in themselves. They know best how to apply their knowledge and strengths to actually deliver on the role's purpose.

What matters most is the conversation that follows – making sure both sides understand the goal, the scope, the expected results, and the day-to-day work in the same way.

The RACI matrix (optional, but useful)

RACI is worth knowing about as a complementary tool for clarifying responsibility on projects or in recurring processes. It assigns four roles:

  • R – Responsible: the person doing the work and making sure it gets done.
  • A – Accountable: the person answerable for the outcome.
  • C – Consulted: people whose input improves the work.
  • I – Informed: people who need to know it's happening.

Take a simplified IT delivery process. List what actually needs to happen – preparing a project plan, gathering requirements, development, testing, client handover. Then list who's involved. Then fill in the matrix.

Task PM Dev QA CEO
Prepare project plan A, R I I I
Gather requirements A, R C I I
Development I R C I
Testing and QA R A I I
Client status updates A I I I
Project handover A, R C I I

The goal isn't to assign a letter to every task in the company. It's to make sure that at the moments that matter, nobody's asking "whose job is this?" When disputes come up – and they do – RACI shows clearly where one person's responsibility ends and another's begins. That's exactly why it supports performance reviews so well.

3. Can people actually say difficult things here?

If you usually find out about problems when someone hands in their notice, or when a client files a complaint, that's not a coincidence. It means there was no safe space to raise the issue earlier.

People see problems long before they're visible to leadership. They notice project risks, overloads, and bad decisions. They just don't say anything, because they've learned that honesty doesn't always pay off. Better to stay quiet than to get judged, cause tension, or get blamed.

For an organisation, that's one of the most expensive patterns there is. No honesty means no data. And without data, decisions get made on instinct.

Performance reviews won't work in an environment where people are afraid to tell the truth. In that kind of culture, review conversations will be safe, vague, and close to useless. Problems won't go away – they'll just keep getting buried.

So before you implement reviews, ask yourself one honest question: can someone in my company say "this isn't working" without getting hit for it?

Psychological safety doesn't mean everything is pleasant. It means mistakes and doubts are treated as information rather than threats. When leaders respond to problems calmly and practically, people raise them earlier. And the earlier a problem surfaces, the easier it is to deal with.

If this is an area you want to work on first, two books are genuinely useful here: The Fearless Organization by Amy Edmondson, which shows how psychological safety affects team performance, and Radical Candor by Kim Scott, which shows how to be direct without damaging relationships.

When candid conversation is the norm, performance reviews stop feeling like stressful events. They become a natural moment to look at what's already happening in the company every day.

Who's actually responsible for performance reviews? The roles of CEO, managers, and HR

In a lot of organisations, it plays out like this: the CEO assumes it's an HR topic. HR is waiting for managers to engage. Managers run the conversations because someone told them to.

For performance reviews to have any business value, roles need to be clearly divided.

Here's a simple breakdown you can adapt to your organisation:

  • CEO / Founder – owns the business rationale. Decides what the process is for and what decisions it should produce. Gives reviews weight, communicates their purpose, and makes sure the outcomes actually translate into action.
  • Team manager – owns the quality of the conversations. Runs reviews, gives clear feedback, connects company goals to the team's day-to-day work, and draws concrete conclusions for the next period.
  • HR – owns the process. Designs the tools, maintains standards, keeps things on schedule, and supports the CEO and managers. HR doesn't take ownership of business decisions, and doesn't run reviews for teams they don't directly work with.
  • Employee – owns their participation. Prepares for the conversation, brings their own perspective, speaks openly about challenges, and takes responsibility for the outcomes.

To close

Performance reviews don't start with a form or a conversation. They start with an honest look at whether the organisation is actually ready for them.

When goals are clear, roles are defined, and honest conversation is possible – reviews become a real business asset. When those conditions aren't in place, they turn into a source of frustration and resistance pretty quickly.

Don't have time to implement the performance review process yourself, but want it to truly support achieving business goals?

Contact Martyna — martyna.lempert@teamboost.pl

Martyna Lempert
Performance Review Module

Automate the review process

Don't do everything on your own, use the support of a dedicated HR tech tool.

Contract left Contract Right