Tips from an ex-Googler: Aligning Teams with Shared OKRs
Lack of alignment hurts
Shared OKRs are a crucial technique to create alignment among different teams. But few companies use them well. Years ago, when I started working with OKR, former Googler Marcelo Quintella was the first person to highlight the importance of shared OKRs. While most authors (Google included) don't even mention it, Marcelo told me that sharing was the most important trait about OKR That is why I’m delighted to announce Marcelo's guest post. An MSc in Engineering from MIT, Marcelo is a Software Engineer turned Product Manager with broad experience in companies like Google and Autodesk. He is currently the 'Head of Data Analytics' at Zwift, a startup that is redefining indoor exercise, focused on cycling. Enter Marcelo.
The Importance of Shared OKRs
If you got interested in the topic of this post, it means that, at the very least, you already heard of OKR. Although not invented by Google, it became known for its importance for Google's Product Management practices.
OKR is a light and powerful tool to align software development and business teams. It can both a) maintain the focus for a period and b) give flexibility about how to achieve such goals.
The secret of modern, agile companies is the balance between focus and flexibility. The ability to make quick decisions (flexibility) while retaining the strategic course (focus). This is true both for startups (agile, but not always focused) and traditional companies (usually not flexible).
A common mistake in teams that start to use OKR is to treat it as a task management tool. Software teams trying to align the Product and Engineering areas often list the features in the roadmap as if they were OKRs.
This approach goes against the primary purpose of well-written OKRs. When done correctly, OKRs don’t mention specific tasks precisely to protect the team’s (and the company’s) flexibility. If during the defined period someone figures out a new task that will achieve the same objective with less effort, why not pursue it?
A Communication Tool
The greatest value of OKRs is not in managing the day-to-day operations of a given team. It relies on acting as a strategic communication tool about the team’s focus in the short and medium term. OKRs are, above all, a communication mechanism.
The idea is that not only the members of that particular team members know their priorities. But also that other teams in the company know about such priorities. They know when they can ask for a new feature or task (do they help in the OKR?). They know when to trust that something will get done or if it is not on the list of priorities.
And this is where Shared OKRs come into play. When a company uses OKRs in all its areas, it makes the alignment between different teams much easier. Be it between two software engineering teams that have interdependencies, be it between the marketing and the product teams (or the sales and customer support teams, etc.). If there is an objective that is important for the company as a whole, such an objective probably needs more than one team to work on it. And when this happens, Shared OKRs are extremely important.
Lack of Alignment Hurts
I’ll illustrate with a story from my time at Google. It used to be (I don’t know if this is true anymore) that Google licensed third-party data to display businesses in Google Maps (hotels, stores, etc.). A Product Manager that I met had his Objective at the time described as “Improve the Business Search Experience in Country X.” He had two Key Results:
X% of the searches should display the correct business in the first slot of the results.
X% of the searches should satisfy the user in his first search (the user should not need to keep refining the search terms to try again, and again).
Great: we have an Objective and very measurable Key Results. The Product Manager was following OKR to the letter.
There was some software engineering work needed to achieve such objective. But above that, the team needed to make sure that the business information was available in Google’s database, to begin with. Otherwise, how can the search find something it does not know about?
But this Product Manager forgot to align his objective with the Partnerships team at Google. The person responsible for finding data providers and sign contracts for the data did not share this OKR. Country X was not on his list of priorities. He did some research, identified potential providers, but never signed the contracts to make the data available. He was not planning to launch Google Maps in that country for the next three months.
My Turn Sharing OKRs
I was lucky enough to learn from someone else’s mistakes. So when it was my time to be the Product Manager for Google Maps Latin America I knew better. I knew that the Product was highly dependent on the Partnerships team. So every time that we had new functionalities in our roadmap, I’d first align the OKRs with them. If the Partnerships team were not ready to commit to such goals, we would go back to the drawing board. I’d work with the Product and Engineering teams to think about other OKRs for that quarter. There was no point in dedicating engineering resources if the data itself was not going to be available.
This story brings me back to my point about communication: it is not enough to write your OKRs and have only your team use them. It is critical that the entire company knows your OKRs. And, maybe even more important, if your OKR depends on some other team’s work, you need to write it together. And you need to make sure that you share the OKR among the teams.
And I’ll insist one more time: more than a tool to manage a particular team, OKR is a powerful and essential tool for COMMUNICATION between teams. It is an easy way to manage expectations (could you implement this extra functionality for me?) and more importantly to align (share) the effort among teams, what should be their focus, and how they will measure success.