14
.
11
.
2023
16
.
11
.
2020
Visuality
HR

What does the 360 review process in Visuality look like? Part 1

Zuzanna Wodyk
Wellbeing Manager

The challenge of feedbacking

When I joined Visuality in June 2020 as Wellbeing Manager, one of the first challenges Michał (CEO) put on the table was “New 360 review process”. As a psychologist and former researcher I asked a standard, but golden question you’ve probably already guessed: “Why, Michał?”. And we started talking. This story is going to be written in two parts (2nd part is already here) — in order to tell you about our current 360 review process, I’d like to tell you how it looked in the past and what challenges Visuality was facing. Thanks to that, you’ll see — or at least it’s my intention — how some obstacles might be solved and what’s the rationale behind the current solution.

At start, let’s describe shortly, what 360 review is. It’s a process to gather feedback about each employee in order to support his/her development. It can have different shapes (i.e. areas and types of questions and answers), but for the purpose of that post, the most important aspect is the main principle behind that process. It’s called “360 degree”, because it’s about getting feedback from many different “angles”, which, while talking about work, means all the people you’ve collaborated with.

The History of reviews in Visuality

Let’s go back to my conversation with Michał about that challenge:

  • Why, Michał? Why do you need a new 360 review process?
  • The one we have is not deep enough. It’s hard for people to gather thoughts and even if they do — the feedback is not really actionable, it barely touches the surface.

To understand the current shape of the process, we started talking about the motivation and history behind it: Visuality always cared about the self-development of its people. It was important to make a place in which people would like to learn new things and feel that they belong. Because loyalty and growth were valued, a pretty obvious rule for Michał was to schedule annual meetings with each employee — meetings that will be focused on employee growth and a raise related to that will be discussed. A few such meetings were conducted — some of them felt really effective, touching important experiences from the previous months and the conversation about the growth “went with the flow”. But some of them weren’t like that. There were conversations that felt for Michał or current CTO (also responsible for a part of those meetings) almost fruitless. Sometimes feedback applied to things that happened so long ago (that feedback was expired). Even worse, sometimes when feedback was given, it turns out it was the first time it popped up — that should never happen and it might be a sign of avoidance or non-transparent communication within the team; annual meetings should be a summary of previous experiences, not unpleasant surprises.

Having all troubles in mind, our CEO & CTO started analyzing why some meetings felt so fruitful and why some of them were really hard. And they came to a very important conclusion: it was more natural (therefore easier) to discuss the growth with people who they have collaborated closely with; it was unnatural to talk about personal experiences they have no clue about. Last, but not least: if they have collaborated with someone on a daily basis, they were able to regularly reflect on that collaboration and in the effect — that annual conversation was a sum-up of reflections that have already been made. If they didn’t get the opportunity to work with someone closely, the conversation was mostly about the perspective of the employee — it could be “enriched” with something the CEO/CTO may only have heard (which is not really valuable, nor reliable or simply fair). What’s more, when they didn’t have broadened perspective on people's strengths and challenges, it was hard for them to help employees with preparing a valuable plan for growth. Those conclusions were a trigger to find a solution that will make the annual meetings more natural and impactful for both sides.

First version of 360 review process

The expectations for that solution were:

  • let the employee reflect on self-development
  • let the CEO/CTO sum-up the growth of the employee
  • provide the feedback that will be reliable — from people who actually have worked with that person
  • have a low-intro level, so people will know how to prepare that feedback (they didn’t get used to it back then)

With clear expectations, the idea to try 360 review process came by. It looked like a proper solution, because it provides feedback from different angles (all of your teammates), including self-reflection. The only thing that was the barrier needing some adjustments was the form of 360 review. That process has been used in HR departments for a long time now (https://en.wikipedia.org/wiki/360-degree_feedback). People usually associate it with “performance management” in large companies, where often it has a form of very long survey teammates have to answer and provide feedback for their colleagues. Because Visuality is a small software house and its processes are quite far from big corporations, Michał wanted to modify that form and make it more natural for his team. He also wanted not to scare people and make that process as simple as it can be — because the most important aspect was to make people used to giving feedback. You know — baby steps. He was thinking about using something people are already familiar with. That’s why the first version of 360 review in Visuality was “Start/Stop/Continue” framework — one that teams have known from their Retrospectives. Another adjustment was made for the frequency of the feedback — because it felt for everybody that one year is too long period of time to sum-up the reflections, it was decided to do the 360 review every 6 months (so two times a year, instead of once).

That process worked for more than a year. People have been learning to prepare feedback for their colleagues and do self-reflection — think about what one person should continue, what start and what stop doing in order to grow. Thanks to that, when it came to the annual meeting, the CEO or CTO was prepared better — had a broadened perspective on someone's behavior and skills. Employee got her/his head straight and ready for conversation. That process has done its job — people got used to preparing feedback, it was one of the most important steps to build a feedback culture Visuality cares about so much. But after some time — there came a need to make that process better. And that’s what I’m going to tell you about in the next post (I know, cliff hanger — promise to be soon :)).

EDIT: And here it is, you can already check PART II

Disclaimer: my blog posts are going to include giphs and memes only from Parks and Recreation, because it’s simply the best TV show in the entire history 💁🏼‍♀️

Zuzanna Wodyk
Wellbeing Manager

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql

A look back at Friendly.rb 2023

14
.
11
.
2023
Cezary Kłos
Conferences
Ruby

Debugging Rails - Ruby Junior Chronicles

14
.
11
.
2023
Piotr Witek
Ruby on Rails
Backend
Tutorial

GraphQL in Ruby on Rails: How to Extend Connections

14
.
11
.
2023
Cezary Kłos
Ruby on Rails
GraphQL
Backend
Tutorial

Tetris on Rails

17
.
03
.
2024
Paweł Strzałkowski
Ruby on Rails
Backend
Frontend
Hotwire

EURUKO 2023 - here's what you've missed

14
.
11
.
2023
Michał Łęcicki
Ruby
Conferences

Easy introduction to Connection Pool in ruby

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

When crazy ideas bring great time or how we organized our first Conference!

04
.
12
.
2023
Alexander Repnikov
Ruby on Rails
Conferences
Visuality

Stacey Matrix & Takeaways - why does your IT project suck?

14
.
11
.
2023
Wiktor De Witte
Project Management
Business

A simple guide to pessimistic locking in Rails

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Backend
Ruby
Tutorial

Poltrax design - story of POLTRAX (part 3)

04
.
12
.
2023
Mateusz Wodyk
Startups
Business
Design