How to Easily Set Quarterly Team Objectives with OKRs

We’ve previously spoken about the reasons for doing OKRs in our first post, and some tweaks we made to the structure in our second. In this post, we’ll talk about some of the techniques we use to get to those results, and how we do it. We’re not generally fans of meaningless meetings, so we prepare carefully to make the most of things.

Dedicate time to the process

All of our OKRs are set in the same “roadmap” week. This is scheduled in advance, and has 1 meeting per team, as well as a kick-off meeting and a product roadmap meeting. People who work remotely know in advance to come to the office, and any other projects have to be put on hold to allow people to participate.

Our kick-off meeting is first of all a chance to share my summary of how we measured up against our goals in the last quarter. Though the teams assess themselves against their goals, I try to paint a holistic picture of the company to set a shared context for the upcoming objectives. The kick off meeting also establishes a thematic goal for the quarter, which acts as the objective of the objectives.

We are lucky that we have a great meeting room for these kinds of discussions. We also prepare the materials we’ll need ahead of time to make things run smoothly (index cards, pens, magnetic whiteboards, projector & laptop).

Get the right people together & gather ideas

At Pusher, anyone is allowed to attend any other team’s OKR meeting, though we might be more picky as we get larger.

Attendees are invited to bring ideas for potential objectives on index cards. These cards are read out by their creator, and then magnetted onto a whiteboard. At this stage, the objectives vary, but could be things like:

• Marketing – “let’s make the blog work better for us”
• Engineering – “let’s reduce tech debt in this area X”
• Support – “let’s improve response times”

Objectives for us are things we’d like to achieve, without straying too far into implementation, or how we’re going to measure them.

Choosing objectives – grouping and voting

Often people will have similar ideas about what works well and what doesn’t in their team, and there will be overlap between the proposed objectives. In this case, we group the index cards together, and write the name of the “theme” next to them on the board.

Once this is done, everyone is given an opportunity to draw three dots on the board next to the objectives they believe we should focus on. This voting allows us to narrow our discussion to the areas we have most alignment on.

Making the selection

We start with the objective that has been voted the most, and work towards the less popular ones. We first agree on how we want to phrase it, and a “volunteer” writes it up into document we project on the wall.

In our first roadmap week, we used a Google spreadsheet (get yours now) for recording the objectives for each team. If you’re looking for a good place to start, this may serve you well for the purpose. It has sheets for the different teams, and space to describe the objectives. As we’ve discussed recently, the number of objectives you choose will probably be different for each team, so don’t take that too literally.

While that worked pretty well, but we ran into issues making it easily visible, or getting people to refer to it outside of the roadmap week. This meant that we actually made our own little app which we now use to manage our OKRs. We’ll probably talk about what it does when it is a bit more finished :)

Product Roadmap vs team objectives

One area that we only partially submit to the OKR process is our product roadmap discussion. This means that while the Engineering team may set themselves objectives that are linked to the backlog, we try to limit the discussion of implementation.

This highlights one of the limitations of the team-based approach. This is that making decisions in teams often leads to a silo effect, where the opposite of alignment can be the result. Creating a product roadmap is an activity that spans teams, and includes the input of many stakeholders. By making it part of a particular team’s plan, it limits both the ability of that team to set their own priorities, and for other people to contribute (since they feel like guests rather than doers).

Team-based OKRs in the way that we do them are great for improving to specific areas, but can result in incrementalism if not linked to other areas. Shaping a product that is used regularly and needs to be super-reliable is the kind of task that can be particularly vulnerable to this kind of danger (which we have been guilty of in the past), and we find that conscious effort is necessary to avoid it happening.

Gathering feedback

At the end of the week, we ask everyone how they think it went, and attempt to bring together that feedback for the next roadmap week. This is done via a simple survey, and is definitely worth including in the overall process. We’ve already identified a number of issues with what we currently do, and plan to make this better in future.

Overall, we continue to be pleased with the format, and will continue to improve it in future.