This part 2 of a series of posts about better ways to run OKRs. Check out part 1 for an intro if you haven’t already.
Our workplace culture also created a lack of transparency internally, which has resulted in siloed teams that lack coordination and knowledge sharing, causing misalignment and inefficiencies in operational and strategic objectives. — Uber, Uber IPO filing
The issues in the above quote should be familiar to you if you’ve tried to scale up your company.
Avoiding siloing and inefficiencies requires more than broadcasting an ambitious goal like “Become a key player in the US market” to all teams.
Cross-Functional Key Results
The first thing you need to avoid are Team-Level Key Results, and instead promote Cross-Functional Key Results.
The reason for this is that in any company, a single team is unlikely to be completely self-sufficient and self-serving. Organisations exist to fill in skill gaps, and lower transactional costs1 (think information and incentive differences, procurement overhead, availability).
Cross-Functional Key Results are not the elimination of functional teams, they’re about improving efficiency and decision quality by preventing complete team siloing.
The way you go about it is by sharing information between teams during these OKR cycle phases:
Understand: when you’re looking to understanding what’s working and the existing gaps, E.g.: “Are we meeting our projected revenue? Why not? Do we need to improve operational costs or increase our market?”.
In this stage it’s important avoid making quick but poor decisions due to lack of information2.
Assuming the OKR Objective is appropriate (an article for another time3), teams should be given enough time to contribute with information on the barriers and assets influencing the success of that Objective.
Define: when you understand the outcome, barriers, assets, and need to define key results to reach that outcome.
In this stage it’s OK and probably more manageable for individual teams to come up with their Key Result ideas. But to prevent duplicated and competing Key Results, all team members must read all ideas names, and team leads must work to create the smallest set of key results, that make the best use of people, and deliver the most value for the company.
Progress: when you’re working to achieve Key Results.
During the define step, team members and leads will have been exposed to the complete set of key result ideas. This information shouldn’t be lost as it expresses values and priorities of individuals and teams. Key Result working teams should be formed based on this.
Here’s an example, imagine you’ve got a platform that a managed services team uses to deliver client projects. It turns out that platform theming needs to be streamlined to cut costs.
The most efficient team would include platform team members, but also one or more external members form the managed services team at the very least. These external team members wouldn’t hate to work on this key result full time, but would be instrumental to understanding the most common theming use-cases, current effort baseline, and validate progress. The understanding of use cases, effort, should help scope and prioritise lower-level initiatives such as specific features.
Through collaboration, you can replace key results such as “Reduce theming effort by 50%” with “Reduce theming effort of top use-cases from 1 week (current) to 1 day”. The difference is that the latter is grounded on real use-cases, and absolute instead of relative measures.
Setting the right Key Results requires investing into your organisation’s research and workshopping skills, I’d say that’s a good investment considering it saves you from spending 3 months worth of budget on less impactful work.
Review: when you perform your mid and post-completion status checks, adjusting as necessary.
I’ll dedicate a few more words to reviews later on in the Measurement section of this article. The gist is that collaboration requires trust between teams, and trust is broken when expectations are broken.
Roadmaps, estimates and plans very rarely play out exactly how you intended 3 months down the line, this shouldn’t be news to anyone involved in complex work.
You only break expectations if you reject this reality.
I often see teams falling victim to the Sunk Cost Bias4, where instead of discarding 1 month of wasted work, they keep putting more money into it until the end of the quarter.
OKRs are hard work with hard decisions. Not all hard decisions will be about cancelling 1 month worth of work, most will just be scope and timeline changes.
Performing reviews, adjusting work, and keeping the dependant teams informed is crucial to establishing and maintaining trust, essential to collaboration.
Have you ever heard or had to say this to someone else:
If only we had this two months ago!
This is not what we expected, why didn’t you tell us?
We were counting on this, what happened?
My guess is that you probably have, in some form or another. It’s frustrating and a clear sign people aren’t communicating properly among themselves.
To fix this and ensure team outputs create the most value, there’s three tactics you can follow:
- Preempt needs
- Set expectations
1. Preempt needs
When a team with the ability to improve work efficiency for themselves or someone else, doesn’t do so, that’s failure to preempt needs.
This is usually caused by a lack of visibility over where the company will focus next, deals being pursued by sales, upcoming work, or existing struggles in somewhere else inside the business.
Preempting needs requires teams to seek to gain visibility over the above factors, through research, before prioritising or committing to work.
Sometimes needs can be addressed with really low effort, high value work, as simple as a crude internal-only tool or document.
Other times it’s simply about prioritising what and how much gets delivered first because you know, rather than assume, what gaps are causing pain in the business.
2. Set expectations
When something doesn’t happen when it should, or happens differently than it should, you’re breaking expectations, which I’ll remind you, harms future collaboration.
As much as possible, outputs must be delivered following the agreed schedule and format. This doesn’t mean the agreement can’t change over time.
Even when you MVP, reduce batch size, release often, the reality is that work changes, and has to change in order to be remain relevant, efficient. We learn things along the way, staff members leave or join, we do things for the first time, and not even commoditised work is invulnerable to changes.
You can’t predict the future but as it becomes your present, you must share it with others, especially dependant teams.
The last tactic is about synchronising output delivery.
Outcomes that require combining multiple outputs, perhaps from multiple teams, inevitably increase work complexity and require more control.
But we know that as complexity increases, control decreases. We also know that outputs are perishable, in the sense their value diminishes over time5.
So how do we synchronise outputs so they can be combined to generate value as soon as they’re made available?
You actually have more visibility and control when you deliver a series of small incremental and iterative steps. – Experience Report – Maersk Line, Black Swan Farming
You guessed it, we break down outputs so they can be integrated more often, in smaller batches. In The Fuzzy Front End, Joshua Arnold expands on how to prioritisation, ownership, and limits enable small batch sizes.
This is a long section on collaboration, to summarise:
- Efficiency requires Collaboration
- Cross-Functional Key Results better support Collaboration
- Slow down, look outside your team and Understand, Define, Progress, and Review work to avoid siloing
- Sustain Collaboration with Trust and Output Scheduling
In the next post, on February 3rd 2020, we will look at how OKRs can do better at motivation.
- Collaboration (this post)
- Motivation (February 3rd 2020)
- Measurement (February 10th 2020)
- Risk (February 17th 2020)
I’ll expand on setting the right Objectives in an upcoming article around the North Star Framework. Objectives are not the top-level strategic goals of your company, they should for example link to higher-level predictors of success for your organisation. ↩
Also known as the Sunk Cost or Concorde Fallacy due to the UK and French governments resistance to cancel the Concorde project, when they knew it had failed, due to how much they had already spent on it. ↩
“In general, we can say that the longer the time-frame between cause and effect, the less we can reliably predict the outcome of our actions – making detailed planning highly perishable.” – Perishable strategy ↩