Implementing OKRs in the middle of Merger — the SHARE NOW journey
SHARE NOW is a free floating car sharing provider which wants to redefine urban mobility. With the introduction of OKRs in our product department we became more focused on customer impact but are still one a learning journey one year into the process.
As one of my colleagues put it so fittingly “what other companies go through in their lifetime, we go for in a year”. Namely, we were merging car2go and DriveNow to become SHARE NOW while becoming independent of our mother companies and yet also started working with OKRs in our product department
In the meantime we moved from a growing strategy to a profitability one.
I will briefly describe why we started with OKRs, what challenges we had with it in different times, what we learned from it and what we want to try next. Let’s start with the WHY.
The WHY
The company (car2go) has existed since about 2009. In the product creation department we have about 16 teams and 150 people, which is about a third of the company, split over 3 different cities. We were coming from being more feature-driven, so our product owners struggled to align on dependencies. There were also challenges with workload balancing, and connecting one’s efforts to the big picture.
Motivator #1: Alignment
We saw that scaling the number of teams and aligning across them became a problem. We introduced OKRs to have more clarity and high level alignment.
Motivator #2: Team Autonomy
Another way to tackle this were end-to-end teams (“squads”) to be less blocked by other teams and align better on a lower level (and thereby be able to focus better) around e.g. OKRs. We also had the introduction of tribes, to cluster teams and create smaller alignment circles to reduce complexity.
There are still other reasons for introducing OKRs, but those were our reasons. (You should also try to limit the benefits you aim for in the beginning to be able to focus better during the implementation).
The Introduction
So we started actively driving the topic in Spring of 2019. Before that, one location had already been given the tool, but no real training, push or requirement to use it. It had therefore been more idling, given half-hearted attention and also by some deemed non-beneficial, since it did not really happen in a structured way and the conditions around it did not match.
So we then sent 2 Agile Coaches (one being me) to a 3-day training to get to know the ropes and come up with a concept of how to introduce it to the company. It is worth mentioning that we as Agile Coaches suggested it to tackle the points mentioned above, it was not primarily driven by Management.
We started with a training session of roughly 2 hours, which was split between an introduction to the concept, criteria for good OKRs, and a big chunk of practical exercise, where we brainstormed and refined OKRs for an example company. We used the example of Space X, since it is the mindset that counts — the framework itself is not rocket science! We later saw a big difference between people who had attended that meeting and those who did not! The former had way more fluency and were further in the mindset than those just getting introduced to this way of thinking.
As you know, OKRs are outcome oriented, and not based on a strict project plan. That was our next challenge, because we had a merger with fixed deadlines, where systems were being shut down.
From Humble Beginnings …
Due to the fixed deadlines, our initial department OKRs looked still more like a project plan. The merger timeline had initially been longer, but due to approvals from the government taking longer, was shortened significantly. Simply achieving the same results by doubling the efforts was also not really an option (this did not scale easily). Hard decisions about what to delay and what to cut had to be made. Hence, we had to look more critically at what outcome we were actually aiming for. We also had a project management office to help us achieve this biggest task in the history of the company (the merger), but their approach was not really aligned with the OKR approach. (By now we have them on board to standardize our OKR timeline and communicate expectations more clearly and consistently — yay!)
We had several phases in our recent past: the merger, the growth phase, the consolidation phase. The latter had the benefit of more clarity about the intended outcome focus — become the first profitable car sharing company!
This way we needed way more numbers to dig into our current reality. This is as good a place as any to state that OKRs do not cause you new problems, they merely show where you had some in the first place. We noticed that we still need more transparency between departments and adjust our collection of data to be even more purposeful to show the progress towards the outcome we are aiming for.
We have some internal tech-outcomes as well, such as moving to best-in-class technology and having an attractive technology stack for (new) developers. On this the numbers are way more clear and we can see great progress here!
… over the course of a year …
One thing we can clearly notice is the improved consistency of planning in our department and a trend towards being more outcome-oriented. (Maybe COVID is an exception to the consistent planning, but who just keeps doing business as usual in such a situation is also not really well equipped for the future (either ignoring the reality or leaving new opportunities untapped).
In the last quarter we also tried to close our biggest understanding gaps by having several POs diving into topics, which concern the whole department and bring them to a level where teams can hypothesize and connect their teams capabilities to. This was also a bigger step in living the part of the bottom up approach of OKRs, although we have the potential for even more.
Also the feedback has been heard to decrease the number of key results to keep the focus more. (In our understanding phase we also noticed that several Key Results actually lead to the same initiatives.)
In our driving for numbers we now also included other departments in our detail planning and hypothesizing and not just on a high level. We see the strong appreciation for being outcome driven and also the interest in working with OKRs in their own departments. Where before we only had an interest based on the more consistent planning we had, we now also see the shared interest to collaborate even deeper to drive a holistic approach.
Due to COVID we also had all our OKR meetings remotely — and see that it definitely works better than only a part of the participants being remote! Keys are to visualize a lot, keep sessions short, and not use more than half of a day since then the attention span keeps dropping and the strain increasing significantly.
… to what we are learning now!
In the last iterations we had significant changes, with focus changes (the merger, growth to consolidation, COVID incl. remote setup), focus on numbers, a deeper understanding phase up front and the learning phase is far from over!
The current challenges include spanning the OKR approach across more departments, since currently our planning modes are not fully aligned yet, which leads to occasional friction and misalignment.
Also are we continuing to close the gap between department goals and the team goals connecting to it.
We also introduced an anonymous feedback tool for the whole department (Office Vibe). It provides us with a weekly view of what is and what isn’t working for people, This has e.g. lead management to revamp our vision & mission to make it more connectable with our teams’ work.
The company keeps on experimenting and learning, which is what an Agile company is all about — and makes us better prepared to face the new challenges that lie ahead. We are excited to see how the journey will continue! :)
If I look back and wonder what I would have done differently ….
Only a few things:
- Probably make the first training mandatory
- Get the leadership to drive a more active role earlier on (although in a merger there are always priorities to juggle)
- Focus on learning questions earlier to more clearly show that it is not a reporting tool
- Focus on a few benefits that I want to achieve with OKRs and measure their success based on them — not too many at once (since then you get lost and it should actually be a focus tool — right? ;))
Although I might have approached some things differently, we also have some epiphanies this way, that we might not have had, if we had started the other way. So I am grateful for the journey we had and the learnings and perspectives we got. We are definitely in a better place than before! Rock on! :)
(Also feel free to check out a slide deck about the learnings until April this year)
