How Amplify connected OKR and Agile

Amplify is an education technology company that is transforming the classroom experience for their clients in the K-12 sector (primary and secondary education). Providing an innovative and purposeful work environment for their employees is something the company cares deeply about, which is why they implemented OKR (Objectives & Key Results) along with agile. We talked to Amplify’s Agile Coach, Matthieu, about his learnings from working with OKR for several years, how OKR and Agile work together, and how the OKR framework changed the way they work at Amplify.

Perdoo:

Tell me about your role at Amplify and how you first discovered OKR.

Matthieu:

I am an Agile Coach at Amplify, a Brooklyn-based education technology company founded in 2000. Amplify works as a partner to school systems across the country, on everything from early literacy assessment and intervention to next-generation digital curriculum. My particular division, the Center for Early Reading, is focused on tackling the ongoing problem of illiteracy. My role at Amplify is to help improve the performance of individuals, teams, and the organization at large, through a combination of coaching, mentoring, and direct action. This broad mandate allows me the flexibility to pursue the most pressing needs.

I first used OKRs when the Agile Coaching department adopted them a couple of years ago. We already had a strong practice of using goals, so the transition was relatively smooth, but we still went through the typical growing pains (having too many Objectives, writing Key Results as outputs rather than outcomes, picking poor measurements, etc.). I had long believed in the paramount importance of having a clear sense of direction, and OKRs seemed an excellent way to summarize that direction. I had experienced problems with other ways of stating goals: they either were too detailed and lost the bigger picture, or too high-level and gave you no idea how to start. The big advantage I see with OKRs is the forced pairing between these two extremes: the aspirational Objective and the nuts-and-bolts Key Results.

Perdoo:

You led the OKR implementation at Amplify. What problems were you trying to solve with the goal management framework?

Matthieu:

A couple of years ago, a group of about 25 engineers and executives met to discuss some legacy technical risks we were facing. Management showed great trust, essentially handing the car keys to the engineering team. However, before breaking, we all agreed we needed some way to check in with each other. No one wanted complicated structure, but we needed some lightweight mechanism for basic communication and alignment. After a bit of discussion, we decided to set high-level two-month goals, all shake hands on it, and then get to work. We made some great progress, so we went for another two-month cycle, this time replacing generic goals with OKRs.

That was the spark, but the lightweight communication and alignment also allowed us to make progress on problems we'd been fighting for a while: cutting away distractions; reducing the overhead of tracking mechanisms; clarifying the true cost of decisions; enabling management to grant much deeper autonomy to teams; and increasing contextual understanding amongst teams, thereby allowing broader engagement and innovation.

Perdoo:

Now that you have used OKR for a year, what are the biggest changes you have seen? How is Amplify different now you use OKR?

Matthieu:

Usually, the best praise a bit of process can hope for is the absence of complaint. But with OKRs, I often hear people talking about them the way a plumber might mention a wrench: as a basic tool central to their work. And some people go further. In the early days of our adoption, someone volunteered to their team that “with OKRs, it feels like the first time since being at the company that all the teams are actually pulling in the same direction.” She'd been with the company 11 years at the time, so this was high praise!

Our offshore teams have said that OKRs made a night-and-day difference for their understanding of how day-to-day work fits into the bigger picture. Their lightweight nature makes OKRs particularly powerful in such cases, where distance and time differences undermine communication.

In terms of culture and process, I have seen a couple of other significant changes:

Teams use OKRs to maintain focus. At first, it seemed alien to focus on a short list of things: “But what about all that other work we need to do?” Now, teams have made a habit of using OKRs as a blade with which to carve out focus: “If it's not in our OKRs, why are we spending time on it?”

Before adopting OKRs, even at our best, we collectively spent tons of time on tracking and worrying and calming the nerves of anxious stakeholders. My sense is that there is just so much less of that now. The teams set their OKRs and get to work, and stakeholders can check in by looking at the OKRs and following up if necessary.

Perdoo:

How did leaders and employees react to the new methodology?

Matthieu:

The CEO was the one to push for OKRs. I ran with it, but because he had spurred it and we were so in sync, I think we avoided a lot of pushback we might otherwise have seen. But that’s not to say we just forced this on people because of his positional authority: we had lots of folks at all levels interested in trying them. I’d say the top-level support was most critical in getting folks to just give it a go in the face of doubts. Once we were running and people saw the values mentioned above, pressure was less necessary.

That’s not to say everyone loves OKRs. There was some objection, and there continues to be some skepticism. But that’s ok, it keeps everyone sharp.

Perdoo:

When it comes to skeptics within the team, what’s the top reason that usually makes them see the value of OKR?

Matthieu:

There is some general suspicion of any additional process. It falls a little into the “Green Eggs and Ham” trap: if you don’t try it, you don’t know the value, so you don’t want to try it. In this case, it’s even trickier, because even if you do try it, doubting the value may undermine how faithfully you do so, thereby undercutting the value delivered. But there are also a couple of more specific objections.

There was some strenuous objection to the idea of limiting focus to OKRs. The “what about all the other work?” voice loomed large. It’s a reasonable position: if you have five urgent things, it is very hard to ignore four of them while focusing on one. Our strong belief, though, was that faced with the choice of focusing on one at a time or focusing on all at once, that focusing on one would ultimately get us through all items more efficiently and effectively. I think people have largely come around to this.

A more pervasive objection is in the value added by putting things in OKR form. Again, this is a reasonably intuitive position: if I know my plan, why do I have to reword it in this particular format? There are a couple of counterintuitive leaps here.

First, the question is whether you and your team truly know the plan. Humans simply can’t hold the entirety of a plan in their heads and come to shared agreement on it; OKRs are a great tool to condense and visualize the shared goal to ensure that everyone is truly envisioning the same thing.

Second, even if you have shared agreement, the plan is only valid at the outset. It could be perfectly in sync with the true outcome you seek, but as soon as you start, the plan starts diverging from all-too-unpredictable reality. Every revision requires resetting shared understanding, abandoning attachment to the plan, and ensuring that the sum of the parts of the plan comprehensively covers the whole. Compare this to OKRs, which remain constant while your plan and all the other details change as necessary. I did a conference presentation a couple of years ago called “The Myth of Fixed Scope”. Those who continue to believe in this myth struggle to see the value of OKRs, because they continue to believe it is possible to set fully detailed scope that is accurately understood by all parties and does not bend in reaction to reality.

Perdoo:

Can you walk me through how you set up your OKR program? What were the steps and who was involved?

Matthieu:

For team OKRs, we used a phased approach, optimizing specific aspects with each iteration. After each of the first few iterations, we discussed what we could improve, and that often drove the focus on the next iteration. For example, in the first iteration, we didn’t expect everyone to have perfectly formed OKRs; we focused only on building the new habit of using a set of OKRs to guide day-to-day work. Teams learned quickly about problems like overcommitment, failing to check in, and poorly written OKRs. So, in the second iteration, we switched focus to writing OKRs as a team and routine check-ins. In the third iteration, once people had the basics down, we started stressing the quality of the OKRs. This phased approach ensured that those of us minding the adoption of OKRs weren’t trying to solve every problem at once.

Teams have set OKRs throughout the adoption, but in our latest iteration, we put major stress on the idea of team ownership. Rather than setting up formal review meetings with management, we simply made clear to teams that it’s their responsibility to seek the advice (not the permission) of those affected by their decisions and those expert in the area of their decisions.

Of course, almost two years in, we are also starting to need some maintenance on basic habits (check-ins, quality of OKRs). You can’t just expect to set things up and walk away!

We’ve also implemented OKRs for individuals, largely those who are not on teams. That case followed a similar pattern, with one exception: we rolled them out top-down, layer-by-layer, because of our feeling that a manager that didn’t have experience writing their own OKRs was ill-suited to guide their reports through doing it. Over the first few iterations, we set aside time each quarter to reflect on our experiences and share techniques we’d learned for executing better against OKRs.

Perdoo:

Tell me about how you approached OKR and Agile. How did you link the two together?

Matthieu:

Around the time of our first iteration, a senior engineering manager asked me, “If OKRs are about setting goals for what you are going to do, isn’t that against Agile?” I said it depended on how you set the goals. If you write output-based OKRs that focus on specific deliverables, they will tend to inhibit agility. But if you write outcome-based OKRs that focus on the problems you are trying to solve, you give yourself room to maneuver in response to every day’s new information while simultaneously having a clear sense of what you are trying to accomplish overall.

When I answered his question, it felt a bit like a way to make OKR and Agile begrudgingly coexist. Since then, though, I have truly come to believe that OKRs actually enhance Agile. Before, teams who operated sprint-to-sprint with no further visibility often felt lost without greater context to inform their decisions. Company missions were too long-term, roadmaps too general, and anything nearer term (release plans, projects, etc.) were usually constraining due to their heavy focus on outputs. Good outcome-focused OKRs provide excellent medium-term visibility without inhibiting the flexibility of Agile. As (if not more) importantly, our CEO often pointed out that OKRs make clear what you are not doing, protecting the focus of the team. Finally, OKRs help those looking to enhance team autonomy: the increased alignment you get through OKRs makes it easier to let teams strike off on their own.

Perdoo:

Did you face any stumbling blocks when implementing OKR and Agile? If so, how did you overcome them?

Matthieu:

Honestly, I felt very little of this. There were the skeptics I mentioned above, but little of that was about the relationship of OKR and Agile. I think I had an easier time shepherding this aspect because I had spent over a year prior thinking and talking about the differences between goals and the laundry list of tasks we do to achieve them. If you are planning to roll out OKR to Agile teams, I strongly recommend being fluent in your understanding of outcomes vs. outputs, to ensure you can handle the questions teams will raise.

Perdoo:

What your best piece of advice for agile teams that want to use OKR?

Matthieu:

I close every OKR training with these words: Make them your own. The danger is in thinking that you follow a few OKR “rules” and you get great results. OKRs are a sophisticated tool that takes practice to master. If you haven’t bought into working hard to make them work for you, I can pretty much guarantee that they won’t. Understand how they can be useful, and keep practicing and tweaking until you are getting that value.

About Matthieu
Matthieu Cornillon is an Agile Coach at The Center for Early Reading at Amplify, a Brooklyn-based education technology company tackling the problem of illiteracy. Through most of his career, Matthieu has worked on trying to make people's work easier, whether through building tools or tweaking processes. Over the last decade, he has shifted his focus from directly creating products to helping coach others in doing so. He values a strong theoretical understanding of Agile, Lean, systems thinking, and other ideas, but believes it important to marry that with lessons learned through hands-on experience in getting things done. For Matthieu, that experience has spanned film and theater, software development, project management, political activism, and renovating his 150-year-old house. Although currently on hiatus to bring up his two young daughters, Matthieu is also a professional actor. He blogs at engineering.amplify.com, and growingtruffles.wordpress.com, and you can follow him on Twitter @growingtruffles.