At SUPCONF this week, Mercer Smith-Looper gave a talk about becoming a leader. At some point during her presentation, she shared about how when we were working together at Trello in the summer of 2016, we adopted OKRs as a way to provide the support team direction for upcoming year. This post is a deep dive into how we brought OKRs to the support team at Trello.
What are OKRs?
Before we jump into the story, let's get a working definition together for OKRs. OKRs are Objectives and Key Results. The Objective is the big visionary thing that you want to accomplish—it's usually qualitative. The Key Results are the handful of things that tell you if you've achieved your objective—they're measurable and quantitative. We'll look at an example in a bit.
Put another way, OKRs give you the ability to put a sense of why behind your work and a way to measure success.
"Why are we doing this work?"
"To meet the objective."
"How will we know we've met the objective?"
"By measuring the key results."
Stuck in Ambiguity
When I utter the sentence, "we introduced OKRs to the support team at Trello", it seems like a done deal, obviously existent, almost as if it we had always had OKRs. The truth is that to arrive at that point, I (and the support team along with me) had to swim through a lot of ambiguity, not knowing at all the best way to move forward, not sure if we were doing the right thing.
As the support team was growing in 2016, I started to have the sense of "the support team should be able to do more for Trello." We had the support inbox mostly under control and provided a high level of email-based support to all of our customers—what else could we handle? So I presented lots of project ideas to my manager.
Have you ever gotten frustrated because you feel like you're not getting traction to move forward on a project? That was happening quite frequently. I had lots of ideas for projects, but had trouble getting traction when I discussed them with my manager. It wasn't clear why we didn't see eye to eye, but without alignment, it didn't make sense to move forward on the projects. That was frustrating.
At the time, he suggested I come up with a vision for where support should be in a year. This was a great idea (thanks Justin!), so to address that, I decided to use OKRs. OKRs weren't a magic bullet. They were mainly a way for us to indicate our direction and to rally behind where we were going.
Nobody was doing OKRs at Trello at the time. We were going to have to figure this out on our own without much in the way of an example from our current working environment.
Researching OKRs
My search for a magical OKR spreadsheet was in vain. It doesn't exist. That's because working from a firm sense of why isn't something that happens overnight. A "system" can't teach that to you. There's no perfect OKR implementation that's going to give you a sense of purpose and create alignment within your team or organization. If you have a strong sense of purpose and alignment, OKRs will help immensely, but they can't give you those things. You have to struggle to find your why, and—at least within an organization—align your why with the why of the entire company.
But you still need a place to start, so let's look at some resources.
This video of Rick Klau from Google Ventures explaining OKRs is one of the most widely shared resources on the topic. It's good, but I struggled on knowing what to do with it when I first watched it. Still, its worth watching if you're interested in OKRs.
Justin, my manager at the time, recommended reading Radical Focus, which in hindsight is probably the best longform introduction to OKRs that I can recommend. I was expecting to have a magical OKR scoring spreadsheet at the end of it, which it didn't have, so I still struggled a bit on exactly what steps I needed to take to get them implemented. The foundation it provided, however, was solid.
Finding our Why
As this was our first time trying this brand new process, we had lots of fits and starts. I stumbled a lot as I tried to figure out what OKRs we should choose and how they should be structured. I had lots and lots of meetings that spanned two different managers (we moved from being under product to being under marketing) to get things finalized.
It was ugly. There was a lot of banging my head against the desk trying to figure out what to put down on paper. And then, when I had something that I thought was clear, it might not be clear when I talked it over with my manager. Or, if it was clear, it might not have been aligned with company goals, so it didn't make sense to work on it. Back to square one.
We even had one meeting with just Mercer and me where we spent pretty much an entire day on a Zoom call hammering them out. (If you ever find yourself banging your head on your desk, I highly recommend getting in a room with someone smart that you trust and asking them to think through the problem with you—it works wonders at unblocking your brain). Shortly after this meeting, we had something that my manager gave a thumbs up to and we were able to move forward and present the OKRs to the team.
An OKR Example
Here's a real-world example we came up with on the support team at Trello. Around the time we were crafting OKRs, we had a rough period where we weren't very responsive during a product outage. It took too long to post a status post, we were way too slow to respond on social media, and we weren't very coordinated in tackling the email inbox. Yuck. This seemed like a good thing to put into our OKRs. I don't remember the exact KRs we chose, but this should give you an idea:
Objective: Slay outages
Key Results:
- Support Team is aware of an outage within 30 seconds of it occurring
- Status Post up within 5 minutes of an outage.
- Average response time to tweets during an outage is <1 minute.
Let's look at the Objective first: "Slay outages." Without even getting into the key results, you should already have an idea of the type of work you're going to be doing. While no business wants an outage, if it does happen, you want to be able to look at your responsiveness and say "we slayed it." Craft your objectives so that they're motivational and give you a deep sense of why you're doing what you're doing.
Notice how it doesn't say "99.94% or better uptime for our product." That's because that's not an objective. That's a key result. To illustrate my point, you could say: "If we achieve 99.94% or better uptime for our product, we'll know that we've moved the needle on slaying outages." (This actually would have been a great KR for this kind of Objective, but as the KRs were focused on just the support team, it didn't quite fit since we didn't have control over product uptime). We'll dive into a KR example in a bit.
Divvying up the Work
When Mercer and I shared the OKRs with the Trello support team, we tried not to be too prescriptive in what people should work on. For the most part, we let individual team members choose what objective(s) they wanted to focus on and what work they would do which would lead to achieving the key results, which in turn would signify whether or not the objective was achieved.
Notice how none of the key results tell you what to do. They only tell you what to measure. They're also bold and challenging. When compared to the status quo, your KRs should be slightly scary. This forces you to be creative when thinking of how to achieve the key results.
OKRs leave a ton of freedom in how to solve a problem. By only defining the results, you leave it up to the people actually doing the work to figure out the best way to achieve those results. (Arguably—and this is the approach FullStory takes—you might also leave the defining of the Key Results up to the individual team members since they're closer to understanding what measurable results they may be able to achieve. Regardless of whether your leadership defines KRs or individual contributors define them, the actual work to achieve the KRs should be left up to the actual people doing the work).
Exploring How to Achieve a Key Result
Let's look at just one of the Key Results in depth: "Status Post up within 5 minutes of an outage". This one is tricky. During downtime, the engineers are focused on getting this back up and aren't focused on updating the status blog.
What if we had defined our "KR" as "Work with engineers to improve process for updating the status page"? That might have led to some shiny new Google docs, but how would we have known if we had achieved the objective of slaying outages? Just having docs doesn't mean people are following them.
Rather than iterate on how to interrupt the engineers to tell them to update the status page, we focused on creative ways the status blog could be updated. By switching from Tumblr to Statuspage, we were able to take advantage of an integration that automatically posted to the status page if Trello went down. Since that integration ran every minute, we were virtually guaranteed to hit our 5 minute goal if Trello went down. And we crafted a handful of common status page templates so the support team could update the status page with minimal help from the engineers. Win!
This is the magic of KRs. By defining what to measure and not what to do, we could get creative in our solution, ultimately leading to a better solution.
Scoring OKRs
Here's where my story with Trello diverges a little bit. Because I left Trello in September of 2016, I wasn't around to see the OKRs through, which means I wasn't around to be a part of their scoring. So for this part, I'll offer one perspective of how you might approach scoring OKRs.
Don't just do the work to achieve OKRs. Score them! It doesn't need to be complicated. Score it from 0 to 1 where 0 is total failure and 1 is "totally crushed it." A .7 should feel like you really moved the needle forward on a big, challenging problem. If you get all 1s, you're sandbagging.
One quick point about scoring: scoring OKRs is usually not about measuring individual performance, so be careful in trying to use it as a personal performance proxy.
A Satisfying End
Earlier this summer, Mercer messaged me to let me know they had scored the OKRs and reviewed them internally with her manager. (Remember, we had defined them for an entire year. Most companies implementing OKRs pick a much shorter time frame). Having been away from Trello for ~9 months, I had completely forgotten about them! I was blown away by how much Mercer and the support team had accomplished in that time period.
Think about how much had changed with the Trello support team: they changed managers when I left, changed companies when they were acquired, and their manager went on maternity leave at the end of the calendar year. Would they have been able to ratchet forward so much with so much change if they hadn't had a clear sense of why laid out in the OKRs for the year? It's possible, but it's much less likely. Having clearly defined OKRs provided structure for the team to know they were doing meaningful work that would move the business forward. (At least, I assume that's what happened—I wasn't around to witness it. I only heard about the amazing results when they were done!)
Pushing Through Ambiguity
I can't stress enough that so much of the work in getting started with OKRs was working through the discomfort of not having the slightest clue what I was doing. I leaned heavily on my managers, Mercer, and conversations with others on the Trello support team to try to find clarity and a path forward. It was messy, sometimes stressful, and a ton of hard work. But it was worth it.
If you're trying to implement OKRs for your team or organization for the first time, push through the ambiguity. Keep iterating until you're comfortable with the process. It's worth it.