Sharing OKR Confidence

OKRs are great for alignment, and improving delivery but they really shine as a learning framework. By encouraging teams to experiment and take risks in a structured, transparent, and supportive way, they help to develop greater organisational intelligence and expose powerful leverage in complex, changing environments.

Good OKR check-ins do this by providing a clear connection between actions and impact while building trust between team members and between teams and their stakeholders.

Eleanor Roosevelt famously said “Do one thing every day that scares you.” OKRs are well known for pushing teams outside of their comfort zone but what does this really mean and how do we really do this? It means boldly pushing into the unknown and doing it with the full support of your team and your entire organisation. We do it by establishing new levels of psychological safety and teaching senior leaders to react with curiosity and compassion rather than fear.

100 years of data, 10 year old infrastructure

In 2017, I was at a global media company in the UK, coaching a team that maintained a complex 15+ year old application, some of it still running on 10 year old hardware. It handled all of the commissioning, scheduling, and playback of millions of hours of audio from thousands of radio programmes on dozens of stations going back nearly 100 years from the world’s oldest and best loved media company.

When I joined the team, they mentioned that releases were difficult, slow, and high-risk. The application was complex, brittle, and filled with poorly understood dependencies that made simple upgrades challenging and potentially dangerous. Releases would happen about twice a year, rendering the application unusable for most of the day and it could take several weeks to stabilise and resolve inevitable post-release issues. We knew that we were accumulating unacceptable levels of debt, downtime, and risk, but we were too swept up in the whirlwind of day to day firefighting and minor platform improvements to make the major shifts that would really let us fly. In other words, the day job had eclipsed the really critical transformative stuff that we should’ve been excited about.

An audacious goal

The new quarter was approaching and, with it, the opportunity to set new OKRs. After two near-misses with our ageing servers in the span of about a month requiring our product owner to trek to the data centre armed with a screwdriver and replacement RAID controller batteries, we decided it was time to permanently and completely migrate this application onto a fresh set of virtual servers sitting atop brand new hardware that the organisation had recently set up. The network, hardware, and even OS-level patches would be supported by a dedicated operations team. We’d been talking about it for months. Our stakeholders were practically pleading with us to do it. We thought maybe we were getting closer but we weren’t sure. What work had we actually done for the migration? How much was really left to do? Could we do it in a single quarter? Could we do it at all?

These questions made our spines tingle with excitement, gave us a healthy dose of nerves, and inspired plenty more questions and ideas. We decided it was time to answer these questions by putting this goal front-and-centre as the primary OKR for this quarter and either definitively making it happen or truly understanding what was holding us back. We set some key results around data completeness, availability and percentage of requests served from new vs old hardware to make the OKR truly measurable and away we went.

An inconvenient truth

At our first couple of OKR check-ins we felt very confident. We couldn’t really point to any specific actions we’d taken towards that goal but in recent months our release cadence had improved to monthly, we’d begun building in quality using test automation with BDD and we’d made a few key hires into the team including a brilliant infrastructure engineer. Our confidence in achieving this OKR was about a 4 out of 5. The team was full of energy and optimism to reach this goal.

Around the third week, we were doing our usual fist-to-five vote and everyone, per usual, gave votes of 4 and 5 out of 5 (80-100% confidence). Everyone, that is, except our database administrator who held up a solitary finger indicating a confidence rating of 1 out of 5. We were shocked. My first instinct was to say “Oh, come on, why so negative?” I’ve since realised that a better comment would have been “Thank you. Thank you for providing a different perspective. Thank you for pointing out what we’re all ignoring but should be in passionate and constant dialogue about – scrutinising relentlessly and collaboratively until it’s resolved.”

My first instinct was to say “Oh, come on, why so negative?” I’ve since realised that a better comment would have been “Thank you.”

As the facilitator for that week’s check-in, I invited him to explain his thinking. He pointed out that we didn’t really have a migration plan, or a rollback plan, or a test plan, or a comms plan and we’d never done anything remotely like this in the past and so, no, he wasn’t feeling very confident. We all looked at each other and realised he was absolutely right. We’d been kidding ourselves because we had “plenty of time” but we hadn’t really dealt with the important questions and the real work at hand. We quickly took another vote and realised our true confidence was closer to 1 (25%) and not 4 (80%).

A moment of panic set in. Thank goodness it was only week three.

Now what?

The energy in the group immediately changed. What had been a relatively routine OKR check-in turned into an intense, heated, triage about what most needed to happen that week to improve our confidence in achieving this –  our most important OKR – by the end of the quarter. We talked about strategies for moving the data and minimising downtime, we discussed ways of monitoring traffic after the switch and identifying potential risk-areas in the current environment.

We talked about all the help we needed from outside the team. We needed to talk to some stakeholders about how they would help us test the system. We needed help from the cloud infrastructure team to configure our network routes in the new environment. We needed approval to buy some data migration software. We needed support from another team to automate testing of additional user journeys. There was a lot to do. Worse, we hadn’t really considered any of it before this moment.

We took this list and figured out what specific actions might be achievable before our next check-in and who, specifically, was willing to commit to doing them. Everything else, we would escalate to our product owner.

As we did every week, we captured the results in our OKR tracking sheet and posted a brief summary and link to the sheet in our stakeholder slack channel. I posted the link and waited for my phone to ring.

A call from the boss

As I expected, in less than 5 minutes, I got a call from my boss – our product owner and the person who decided whether to spend his budget on my contract. I felt a slight knot forming in my stomach as I picked up. After thanking me for posting the results of our check-in, he nonchalantly remarked that our confidence had taken “a bit of a nose dive” this week and asked “How can I help?” – not “what’s the matter with you bozos?”, not “I knew I should’ve outsourced this work”, not “I’m so disappointed, don’t let me down” but “How can I help?”

“I see that confidence took a nosedive this week. How can I help?” – The Boss

Fortunately, I was ready. We both were. Our team had shown real progress in the past few months. We had expressed a growing willingness to push our boundaries by tackling this goal and our product owner had defended our occasional growing pains and the decision to take this on with senior managers when they thought it was too risky and should be outsourced.

I knew his question represented a genuine offer to help. Furthermore, because we’d had such a passionate and honest conversation as a team, we held a robust, well vetted, and highly specific list of truly valuable actions that he could take right now to help us make significant progress.

I quickly walked him through each item on our list. I explained what it was, why it was important to do now, who we needed to involve, and how we would verify if it had been completed correctly. He asked a few clarifying questions, took some notes, and told me to leave it with him.

A few hours later, he called back. Not only had he completed every item on our list, he’d even found a few extra people to help with testing and identified a new edge case that we hadn’t yet considered. I was blown away.

A different kind of check-in

Next week’s check-in was a very different conversation. We reviewed the actions we had taken and the actions that our product owner had taken on our behalf. We could feel the difference these actions made in our confidence. We still weren’t back at the “hollow” 80% confidence we’d given ourselves in those first few weeks but our confidence was increasing and, most critically, we knew why our confidence was increasing and we knew we had increasing control over the outcomes. We now had a system that would help us understand how things were going and tell us exactly how to have the greatest impact.

We now had a system that would help us understand exactly what was happening and tell us exactly what actions would give us the greatest impact.

This goal, and our current ability to impact it, were now firmly on our daily radar. We knew we couldn’t just let it slide or assume that it would work out. From that moment, every week, we were holding each other accountable, we were holding our product owner accountable for the things he continued to offer to help with, and he was holding us accountable for telling him what was happening and using his position of influence and product knowledge to help us succeed in a structured, transparent, and methodical way.

Building trust and engagement

I’ve worked on so many projects where the team reported that everything was just fine – “nothing to see here” – until weeks or even days before some major deadline when they announced that it was suddenly way off track by which point, it was nearly impossible to recover. I’ve also been that person either consciously or unconsciously burying important facts, trying to avoid scrutiny when I didn’t feel safe or trust that my stakeholders would or could genuinely help.

We were in a fortunate situation to already have a great deal of trust with our product owner. Still, this experience really solidified that trust, enabled much wider more open communication across our entire group of stakeholders and built multi-directional confidence that the team could deliver and that our stakeholders really were committed to helping us in whatever way they could.

It proved to the team that we could be honest and forthright with our stakeholders and that they would offer genuine help that made a difference to our team. It proved to our stakeholders that the team could be trusted to share a true picture of both what was happening and what conclusions we were drawing from those events, and finally exactly what plans we had to respond to our observations.

Safety and trust are not created through words but by actions over a sustained period of time. – Oli Lovell

Trust gets built over the course of dozens, hundreds, maybe thousands of individual interactions where one party makes a commitment and then delivers on it. This is the core of the OKR check-in process as I use it. It’s not simply to “check progress” it’s to understand how well we’ve met our commitments, what the impact of delivering those commitments has been, and what we’ll commit to doing next.

Every check-in is an opportunity to strengthen this trust and get better at understanding what we’re capable of as individuals and as a team.

By inviting stakeholders into the process, we give them an equal opportunity to trust our commitments as well as the opportunity to make their own commitments to us.

The somewhat naïve – even guileless – passion and energy that we had brought into the quarter had been completely transformed into deep engagement, intense urgency and relentless focus. All our senses were sharpened and every conversation became an exciting opportunity to figure out if our recent actions had made us more confident, what we needed to do next, and what we should stop doing. It was as if the entire team was pulled into a state of deep flow that lasted for months.

It was as if the entire team was pulled into a state of deep flow that lasted for months.

The final stretch

We continued in this way and over time, more stakeholders and outside observers started to get involved, observing our check-in reports and cheering us on, offering unexpected help along the way, and getting excited with us when it looked like the prize was within reach.

The day when we finally disconnected the legacy servers was a great celebration. Not only because we’d achieved a goal that had eluded us for years, but because we had achieved it by building deeper transparency, greater trust, and more robust relationships with each other and our stakeholders than ever before.

Transparency for the win

Working in the open is almost always the best way to do things. Careful OKR check-ins can provide a truly structured and transparent way to understand what’s happening and share this information with those who can help. Try sharing your weekly check-in results with stakeholders or even invite them into the conversation and you may be shocked by the quality of conversations you start to have and the surprising ways outsiders can help a team to deliver!

Thanks to Shilpa Danwe and Oli Lovell for their help with this article!

---