Around 2015 HolidayCheck introduced OKRs - Objectives and Key Results - to steer the company. OKRs are basically a “framework for defining and tracking objectives and their outcomes”. I’ll try to summarize how our OKR process was supposed to work back then:
Our OKR process in theory
(You can skip to Our current OKR process in practice, from the perspective of a developer if you’re only interested in how it currently works)
We come up with OKRs each quarter. To do that teams (they usually consist of several developers, UX/Design-folks, a PO, ScrumMaster, and Stakeholders) come up with a proposal for their own team objectives for the next quarter. Before that our management is giving us some guidance what might be the most important topics in the next quarter. Usually, someone from each team is then attending “OKR-Workshop I”. In that workshop, the management and the other attendees talk about all proposed objectives and try to already filter a bit what we can and can’t do.
After that workshop, the teams then can do their own workshops to improve and sharpen their OKR proposals. After 2 weeks the “OKR-Workshop II” takes place. The result of this workshop is a final list of objectives that will be tackled in the next quarter. All teams will then be informed on what exactly they will work in the coming quarter.
After that, we do frequent Retrospectives and CheckIns to figure out what we can and should improve.
Our current OKR process in practice, from the perspective of a developer
Since we introduced OKRs a lot has changed and we optimized our OKR process quite a bit - I think HolidayCheck has kind of a unique take at working with OKRs and especially in setting up teams. So how does it currently work from the perspective of an employee that is working in one of our scrum/product teams? I can at least give you my subjective perspective as a developer.
Let’s get a quick overview of how our current OKR process works before we go into the details:
- at the end of a quarter every team does internal workshops to come up with good OKRs for the existing team
- we get an email from our C-Level with guidance of what will be important next quarter
- in OKR-Workshop I, a selected round of people presents all the OKRs and initiatives. Some already end up on a list of things we will not do
- in the 2 weeks until OKR-Workshop II, teams talk to each other to find a way to get their OKRs approved or to keep their team stable
- in OKR-Workshop II a final list of approved OKRs and initiatives is created. This might require new teams.
- after/in OKR-Workshop II, employees are assigned to those initiatives by our management
- everyone is informed with an email that contains a list of names and what they’ll be working on
- at some point in the next quarter we start working with this new team setup
Everything starts with guidance
Our management (that is the so-called “C-Level”, CEO, CPO, CFO, …) come up with what we call “guidance”: A list of things HolidayCheck wants to tackle in a given quarter or in a given year. So - for example - at the end of 2017 we did get a list of initiatives and things that the management thinks is important for 2018. That could be improving existing things (making them faster or improving UX), starting new things and products like cruises and so on. Each of those topics is supposed to get some employees or team working on it. This guidance should be sent a few weeks before the first OKR workshop.
Because it is very hard to come up with that list and the management has to do some hard decisions usually it is in the inboxes of everyone only a few days before the workshops. But this also helps teams to come up with their own set of OKRs without already being boxed in, in their thinking and brainstorming.
OKR Workshop I
We do 2 OKR-Workshops every iteration - the most interesting is the first of the year. Why? Because it is already influenced by the yearly guidance we get. Teams can prepare OKRs for that workshop - finding things that they would like to work on as a team. Normally that happens in team internal meetings where we do brainstormings and try to plan the next quarter. We also come up with Objectives and Key Results for our own team. They are not final but they will be presented in the OKR-Workshop - either by someone who is part of the team or by another attendee of that OKR-Workshop. In the OKR-Workshop the attendees have to then take very hard decisions: Often OKRs end up on a list of things we will not work on in the next quarter.
Sometimes the OKR-Workshop people think that the current team setup does not fit together with what we got as guidance. In this case, they also talk about forming new teams, who could be part of such teams and how many employees they might need.
To not demotivate the existing teams this guidance is only communicated after most teams have done their internal workshops and have come up with their own set of OKRs. At this point the guidance is also not yet a decision - it’s just a proposal by the management that will work as a basis in the discussions of the first ORK-Workshop.
So before the first big OKR-Workshop nobody can exactly know what he or she will work on and if all the effort that went into creating team-OKRs will pay off or not.
After the first OKR-Workshop people who attended the workshop start informing all teams about the temporary results of that workshop: What ended up on the list of things we’ll do? What might a team work on? How many people are needed for that new Initiative? At this point, nothing is set in stone and no final decision was taken.
It is still 2 weeks until OKR-Workshop II will take place. And the teams are supposed to use that time to talk with other teams about dependencies, joining forces, broadening or sharpening their scope, reformulating their OKRs and so on.
The second OKR-Workshop is the more important one: All attendees agree on a list of objectives and they also come up with a team setup in or after this workshop. This is a full day workshop and if you’re not part of this workshop you just sit and wait for results because that workshop is not public.
And “results” in that case could mean anything: It could mean that you can just continue working on your current project in your current team. It could mean that your team gets a new project or it could mean that you have to switch teams. We had those cases quite often but now HolidayCheck tries to keep most teams stable for a year.
After OKR-Workshop II everyone is waiting for the official communication. The attendees of the OKR workshop are encouraged not to talk about the results because this could lead to rumours and anger. To ensure that everyone IS getting the needed information HolidayCheck uses several ways to communicate the results and changes:
- for some teams, a team member (like the PO) was part of the workshop and can inform the team
- for others, the line manager directly informs his employees in 1 to 1 talks
- and to ensure really everyone is informed there is an email that contains a list of names and the initiatives that they will work on. Usually, this email is the way most people learn about their assignment. This email also includes an explanation of why certain decisions had to be taken.
There are no conversations with individual people (developers, UX-folks, POs, designers…) what they want to work on or what options they would like most - probably because that would be a lot of effort and would cause a lot of turmoil. And HolidayCheck wants employees to be able to fully focus on their current tasks without disturbing them with such discussions.
So, in the end, you can look up your name in a big list of employees to see what you’ll be working on. Especially in the OKR-Workshops for a new year, this list is quite interesting.
There are often big changes on the company level but also for individual employees for the next year. People often react reluctant to changes at first - but now they have time to reflect on those changes in their vacation. Or they can relax in their vacation and learn about the changes in the new year: So, in the end, everyone has fresh energy for those changes.
Deciding on a new team setup and dealing with the changes
When we create the list of assignments we try to give every person focus: usually every employee is assigned with 100% to one initiative, sometimes we have a person that is assigned with a 50/50 or 25/75 split to 2 projects. But we aim to give everyone focus.
Sometimes in this process old teams are removed because they are no longer a priority and hence some topics, services, and half-finished projects are abandoned and we need a clear process to tackle this:
The way we usually do that is that we always try to launch little MVPs as fast as possible. This is to avoid working on something that is never launched because your team no longer exists or switches what you’re working on. It also means that sometimes those MVPs stay live for months and years - but since the V in MVP stands for viable that shouldn’t be a big problem.
For code, projects and services that no longer have an owner, because the team that created and maintained it no longer exists, HolidayCheck has another process: We have a list of every “abandoned” service that notes down who will be responsible to maintain it.
This also means that on paper all our employees are working 100% or 50/50 or 75/25 on maximum 2 things - and additionally on a number of “legacy” things that still need to be maintained.
So how exactly do the people in those workshops come up with this list of names and assignments? One factor is how many people an initiative, that made the cut in the OKR-workshop, requested. Another source for this decision is what our management thinks helps individual people to grow. It is important for HolidayCheck to offer everyone the possibility to grow. So we collect Peer Feedback about every employee and also talk about each and every employee (without them being present) in a meeting to assess their performance and growth.
As already said previously: managers and workshop attendees try to not discuss these new assignments with the people, who will be affected by those changes, beforehand. This will only be a lot of work and since people are always reluctant to change it is better to ignore (or not ask for) their wishes - usually some people tend to be “pissed off” for the first months - but later they tend to get more happy again. The expectation is that everybody will get used to this kind of decision process over time and will learn that change is a good thing and that people managers often know best what is good for the growth of an employee or a team.
But they also give people a chance to speak up after they received “the list”. Feedback is always valued - on the other hand, it is important to us that nobody just says: “I don’t want to work on that project” or “I would like to work with person XY” - instead they have to find someone else, that is a fit skill-wise, in the company that likes to switch places with them. HolidayCheck thinks this is a fair way of handling this since managers and workshop attendees already put in a lot of effort by assigning people. With offering this possibility to switch positions with others they show everyone that HolidayCheck is open to feedback and better ideas - this is important in a transparent and open company.
As already stated: I think we have a very unique way of handling all of this. But maybe I’m wrong and YOUR company is doing it in the same way? I’d like to know how this works in other companies - so why don’t you give us a little summary on twitter? Just mention @holidaychecklab.
Usually you’ll only hear about how awesome some process is or read a case study of how much a company improved after applying a new process. You’ll less often will read about the problems that said processes have - about the things that we don’t have figured out yet. But I think it is important to also talk about the problems and shortcomings of processes and companies publicly.
As you might have noticed, in my opinion our current process has lots of flaws. Splitting up teams is problematic, the way we communicate and treat changes is imho just not ok and makes people like me feel like “just a resource”.
So what would I prefer? I don’t have a perfect solution and it is also not an easy problem to solve. But I still think there are many things we could improve:
- the “guidance” needs to come earlier. This would avoid that teams invest time into planning or implementing something that never will go live
- the OKR-Workshops should be earlier so that there is enough time to talk about results and change them
- the OKR-Workshops itself should be public
- instead of assigning individual people to projects and initiatives, only teams should be reassigned (if absolutely necessary)
- ideally a team is deciding itself what it wants to work on
- no one is assigned to a new topic or team without being asked first. If there are teams that have too few people working on it we could make that issue public and wait for volunteers willing to step up
- we should prefer keeping teams stable over adhering strictly to a short-term resource/initiative plan
- the OKR process should not be mixed up with any kind of career or growth plans of individual people
I've also removed some internal names, products and details that don't matter to the story and changed some wordings to be more neutral (e.g. resource vs employee).
The illustrations in this post are from Katerina Limpitsouni’s https://undraw.co/.