OKR – Objectives and Key Results

How do you adapt fast to an ever-changing market and build great products? Lots of companies like Intel, Google, and many others are faced with this question, and when going through their answers, a particular pattern appeared around the term of OKRs.

Focus and prioritization, alignment between team members, accountability, and goal awareness throughout the company are some of the reasons why it proved to be the right answer for many of them.

So what are OKRs?

The term comes from “Objectives and Key Results” and it appeared initially at Intel, where Andy Grove developed this concept during the time where the company was facing one of their biggest challenges in the battle with Motorola around microprocessors.

To explain the beauty and simplicity of the framework I will use an excerpt from the hands of their creator:

Andrew Grove – “The Father of OKR”

Now, the two key phrases . . . are objectives and the key result. And they match the two purposes. The objective is the direction: “We want to dominate the mid-range microcomputer component business.”That’s an objective. That’s where we’re going to go. Key results for this quarter: “Win ten new designs for the 8085” is one key result. It’s a milestone. The two are not the same. . . .The key result has to be measurable. But at the end you can look, and without any arguments: Did I do that or did I not do it? Yes? No? Simple. No judgments in it. Now, did we dominate the mid-range microcomputer business? That’s for us to argue in the years to come, but over the next quarter we’ll know whether we’ve won ten new designs or not.

If you want to find out the whole history around the creation of OKRs and the challenges that Intel was facing at that time, I recommend checking out the book “Measure What Matters” by John Doerr. You will also find many other success stories and examples of ambitious and inspiring objectives from companies like Google, Youtube, Adobe and many more.

Examples of OKRs

Objective: Develop the next generation client platform for web application
Key Result: Chrome reaches 20 million seven-day active users


Objective: We should make the web work as smoothly as flipping through a magazine
Key Result: Make javascript execute 10x faster


Objective: We own product delivery and we learn every time
Key Results:

  • 100% of releases have a retro
  • 0 customer-reported bugs
  • 0 repeat production bugs

Objective: Continue to build a world-class team
Key results:

  • Recruit 10 engineers
  • Hire a commercial sales leader
  • 100% of candidates feel they had a well-organized, professional experience even if we did not extend an offer

Objective: We attract, retain, and enable the best people to operate at their best

Key Results:

  • Every team has OKRs and achieves 85% of key results
  • 80% of people feel we value their growth and development
  • We achieve 90% of our hiring plan and all roles have a defined ramp plan
  • 100% of employees have 360 reviews

Now, coming back, let’s take a look at the main qualities of OKRs.

Objectives are:

  • Ambitious – Inspiring objectives help align the team around a common purpose.
  • Qualitative – Instead of being measurable or quantitative, qualitative objectives give freedom to interpret. Remember, they represent the direction, not the amount of results that your team had.
  • Time-bound – Objectives should take at least one month to complete; otherwise, they are not ambitious enough and relate more to daily or weekly tasks. The most common durations are a quarter, a half, or an entire year. My personal preference is quarterly for extra flexibility.
  • Actionable by the team – There is a high level of frustration when an objective cannot be completed, because the ball is in another team’s court and/ or out of their priorities. Tip: I recommend building cross-functional teams that have a mix of skills so you can always achieve the required progress and reduce the chances of getting blocked.

Objectives are always accompanied by key results that are:

  • Measurable and quantifiable
  • Make the objective achievable
  • Lead to objective grading
  • Difficult, but not impossible

MBO vs OKRs

A big difference from the classic MBOs (management by objectives) is that OKRs are driven bottom-up. Each team member is asked to define what in his opinion represents the right objective for his team. Managers will also have prepared one or two objectives, but in the end the whole team discusses and agrees on what will be the next OKRs that they will strive for.

When defining them, objectives must be “uncomfortable existing ones,” as a top manager at Google likes to call them. This means that by default, they are challenging goals, and from the beginning, the team should feel that they have a 50% chance of achievement. When they are ambitious and inspiring, they can put forth the best of themselves and think outside of the box to come up with smart and unique solutions.

When Intel moved away from MBOs

After creating and setting the OKRs, the next phase is the execution. Christina Wodtke in her book “Radical Focus” shares valuable advice along with a great execution framework. She explains that there must be a system where every week the team checks progress, prioritizes and does only the right things.

She talks about two main meetings: The planning meeting on Monday morning and the Weekly Wins Meeting on Friday evening. She recommends this routine to enforce focus only on work that has an impact on the quarterly OKRs. This prevents the team from chasing “golden apples.” She uses this term to define other useful ideas or actions that do not help in achieving the primary purpose of the company.

OKRs must not be connected to performance evaluations, bonuses or other kinds of financial compensation. This is one of the most common mistakes that companies fall into, and it has negative consequences on their people and their results. We want all team members to “reach for the stars.” When people have their OKRs connected to bonuses, some of them will start “sandbagging” them or playing defensively or negotiating with their managers to make them “more realistic” to a level that the results are nothing out of the ordinary. Intrinsic motivation becomes extrinsic motivation, and the pursuit and the drive to achieve incredibly great things quickly fades away.

For more on common hurdles when implementing OKRs check out this Quora answer here.

OKRs adoption trend in the industry continues to rise. More and more companies are adopting and applying them across departments, components, and levels.

They are a great tool to fulfill a company vision or strategic mission and must be part of the toolbox of every successful executive or manager.

If you want to learn more, I collected a list of resources that helped me understand the concept, and I can gladly recommend:

Resources

Note: Some of the book links below are affiliate links, which means that if you choose to make a purchase, I will earn a commission. This commission comes at no additional cost to you.


Also published on Medium and LinkedIn.

Event Storming – How to deal with complexity and improve your domain design

Were you faced with implementing a new complex feature, just to discover edge case after edge case? Or did you work on a specific component, without understanding how the changes impact the overall system?

In this article, you will discover a technique that will prevent headaches and frustration when dealing with hidden dependencies, complexity or unclear requirements.

Alberto Brandolini invented Event Storming to align people in a common understanding of the business procedures, user flows, and the value creation process.

Before starting any implementation, we expect that requirements are given by domain experts (product owners, business analysts, game designers, etc).

The fundamental assumption that this technique challenges is that a single person knows the whole business domain.

That might be true in certain companies or smaller businesses, however, the reality is that we are dealing with knowledge silos and complex system, where the so-called domain experts know a certain part of the big picture and not all dependencies.

The goal of the event storming technique is to create a shared understanding of the value creation flow. Key stakeholders must participate, be in the same room and map out all domain events that are part of the system. Only through collaborative work, weaknesses are discovered and can be acted upon.

I used this method for improving our continuous delivery process. I used it in aligning understanding of our assets pipeline. When I was part of a cross-functional team, I used it before starting to implement bigger features to reduce risks and discovering all the possible flows that can influence the user flow. Over and over it brought the results that we expected and it saved many hours of building the wrong thing.

So let’s take a look at the actual steps involved in organizing an Event Storming session.

Step 1. Schedule a workshop and invite the right people.

You will need a mix of people who can ask questions (usually developers, qa engineers) and people who can answer them (usually the domain experts). The number of participants should be at least 4 persons but not more than 8, otherwise, the logistics and moderation effort would be too high.

You need a dedicated moderator as he will have a key role in the workshop. Bring posits with various colors (especially orange ones) Bring a long big plotter paper that you tape onto the entire length of the main wall. Push all chairs and tables to the corner as the workshop will be quite interactive and you need all participants to be engaged as much as possible. Draw an arrow from left to right on the plotter paper, reprising a timeline.

The room should look something like this:

Step 2. Ask the participants to write down the key events in their domain as an orange sticky note, in a verb at past tense and to place them along the timeline.

This phase marks the start of modeling the whole business line with domain events. Most participants might be a bit confused at start, but as the first event is added to the board, people start getting in a state of flow.

The moderator should keep an eye on all inserted stickers. If there are some that don’t follow the rules (e.g. not a verb at past tense) he should not interrupt the process but rotate a bit the sticker to mark that something is not right.

Some participants will make remarks on certain events, like this is always causing trouble, or I have no idea what is going on here. The moderator should capture these warnings on a purple sticker and place them close to the corresponding events.

Constraints, issues or ambiguities will be soon exposed. Key terms definitions should be captured by the moderator on a special yellow stick note and placed below the normal flow. This will help build a terminology that is commonly understood.

After this phase, your wall should look something like this.

Step 3. Start getting deeper into the mechanics and core components of the domain.

After having all the events visualized and ordered chronologically start adding blue stickers that represent user actions/intentions/decisions. For example: “cancel subscription” or “order pizza”. Alongside add a small yellow sticker that represents the actor performing the interaction.

Discussions will soon go into the direction why should user “X” perform this action? This forces people to think one layer deeper, since commands are ultimately the results of some decision.

By challenging assumptions and bringing alternative options you will make the first step in improving the overall design. That is why is important to have key stakeholders participating so that constraints can be updated or policies adjusted.

After the workshop, I usually take pictures of the entire wall and also bring the paper role in the team space so that it is always visible. When team members encounter any difficulties, they just come back to it as it represents a source of knowledge that is understood by all technical or nontechnical parties.

You can go further and build aggregates so that you can start building a domain model, but for simplicity’s sake, I will stop here and provide you bellow links towards Alberto Brandolini’s website, the inventor of this technique.

I recommend checking out his videos, presentation and grab his book where he goes in a lot more details on the thoughts behind the methods.

If you want to see the video version of this article check it out on my youtube channel.

Extreme Ownership – How military leadership principles can be applied to business context?

Have you ever imagined that military leadership principles could apply in a business context? Two Navy SEALs leaders, Jocko Willink and Leif Babin, show in their book, “Extreme Ownership” exactly how this is possible.

After reading it and reflecting on my own experiences, I decided to apply some of these principles to the context of agile scrum and cross-feature teams and share some of my thoughts below:

The leadership mindset

The first principle I would like to start with is the leadership mindset. Jocko states that all responsibilities for success or failure lie with the leader. Take ownership of them, acknowledge mistakes, and admit failures. I couldn’t agree more.

One of the first stepping stones to good leadership is owning up and taking responsibility. This is the key to earning the trust of your directs, your supervisor, or any peer you work with.

Your actions or inactions play a crucial role in the results and happiness of your directs. If they fail, it might be because you haven’t explained clearly enough the value or importance of a project. Alternatively, it can be that you haven’t protected them from repeated interruptions. Sometimes, it can be because you accepted a mediocre performance, and now it became the new team standard. Whatever the reason might be, it is the responsibility of the leader to bring the team to success and develop his people.

Effective Leadership

Next, the author explains what his expectations of leaders on the battlefield are. He states that it is their role to figure out what needs to be done and do it, to tell higher authority what they plan to do, rather than ask what they want to do. Leaders must be proactive, rather than reactive.

“To be effectively empowered to make decisions is it imperative that frontline leaders execute with confidence. Tactical leaders must be confident that they understand the strategic mission and Commander’s Intent, they must have implicit trust that their senior leaders will back their decisions.”

I love this previous quote from Jacko as it reflects a culture that in my opinion, should be nurtured in all organisations. Clear, open communication alongside trust from both directions is a must. That is why no matter if you are a tech lead, engineer manager, head, director, or C level as a leader, you need to be trustworthy, accountable, and precise about the objective.

The book presents the story of how multiple teams of six members are racing on a specialised track having to carry an inflatable boat with them at all times. When one team was failing over and over, the instructors decided to switch the leaders. The results were fascinating since nothing else changed in the team structure, the performance of the team increased, and they were now competing for the first place.

The book mentions how effective leaders focus the team on the most immediate physical goal that lies ahead: the benchmark, the landmark, the road sign, etc. and not the finish line or the days to come.

In scrum teams, the most common duration of a sprint is two weeks. There is value in checking our progress on the yearly roadmap, but good leaders bring focus on the sprint goals, the landmarks from the story. It makes it easier to connect if the goal is clear, visible, and attainable. Pay special attention to planning meetings to set and communicate goals, as this can make the difference between success or failure.

Prioritise and execute

The next principle that I like is related to prioritisation. It is mentioned that Navy SEALs have this saying:

Relax, look around, make a call.

Contrary to my previous section where the team must focus on the immediate goal, a leader must not get lost in the details. Instead, he should look at the strategic picture. Make sure not to get overwhelmed with reactive tasks. Stop and challenge the next thing you plan to do, by asking is this the most important or the most valuable task my team or I should focus on.

Additionally, in scrum teams, this means having two or three sprints prepared ahead, have an overview of critical projects that need to be initiated or delivered in the next quarter. Try to know as much data as possible, like roadmaps of external departments, market trends, competitors, etc. so you are not caught off guard and can make the right strategic decisions.

Discipline

The next principle and one of my personal favourites is having discipline.

It starts from small wins like not hitting the snooze button for 30 minutes more of sleep, working out, practicing your craft, learning and growing every day. With repetition, habits are formed, and with habits comes freedom.

Teams and team members must develop their own habits, so the health and morale of the team are as good as possible. Sprint retrospectives are essential alongside the culture that each leader is responsible for. Pay attention that positive habits are created and bad ones are stopped as early as possible.

Keep things simple

The last principle that I would like to mention here is “Keeping things simple.” Jocko explains how in the military complicating instructions and orders can have extreme consequences. When an important message needs to be passed from person to person or down the chain of command, simplicity is key.

To be honest, making things simple is something I need to improve on and grow. Many times, in my career, I discovered that a message was understood differently by various people. Clear and straightforward statements from leaders can make the information flow much better in all organisations.

Simplicity doesn’t refer only to the communication aspect, but also to the solutions we implement. Is your approach to solving this problem or implementing this next feature a simple one, so even 5-year-olds understand it? If not, challenge it and find a way to reduce complexity. It is hard to keep things simple, but it is definitely worth it.

Summary

Overall, I really enjoyed the Extreme Ownership book and found many cases that I could relate to, even if I never stepped foot in the military. It gives me even more respect for the men and women leading in this organisation. If all leaders have in the back of their mind these principles, and they treat their actions and behaviours as if they had life and death consequences, I feel that it would set a new standard in many organisations and change our industry for the better.


Also published on Medium and LinkedIn.