Veepee has been engaged in a profound transformation for 3 years now. #1 Building a strong tech team, #2 rebuilding the entire information system to regain the ability to support businesses, #3 keep delivering business value and, on top of that, #4 become a group through the merger of the acquired companies. Such a transformation is full of pitfalls, of tests, of successes and learnings. One of the key lessons we have learned that I wanted to share through this article, is that it requires a solid framework to align all teams together and achieve objectives.

As part of our series of articles on “how to set good objectives”, we will deep dive here into the OKRs experience at Veepee. Trying to be as transparent as possible, with what we have tried, what we have done well and what we are trying to improve. You may feel frustrated at times as I cannot go into detail on all the topics developed here, but for sure, some of them will result in dedicated articles for further development.

Disclaimer: what is described here is my own view of the amazing work that has been done over the years by all of the Veepee teams.

Why OKRs

A bit of history first. Back several years ago, Veepee information system looked like a few big monoliths that drove all the flows. Big monoliths is not pejorative at all. It only means that there is a lot of history, a lot of strategy changes, a lot of shortcuts within these systems that it was starting to be hard to get past. To be honest, they are still there and they actually manage a huge part of Veepee turnover. However step-by-step, we have been able to decouple some flows from these monoliths to deliver business value faster.

To implement this transformation, we believed in some concepts that help us make the design.

#First, the distribution of the organization
The information system reflects the organization. If we wanted to design a decoupled system, we needed a highly distributed organization with a clear definition of scope and boundaries. That led to the creation of many small teams, each responsible for one part of the system.

#Then, ownership, autonomy and accountability
Each team is responsible to its own perimeter and has to make everything in its hand to meet the right need in the right way. From business point of view to tech point of view.
While this setup seemed promising, we quickly lacked a way to align the teams together, in the same direction, and measure the value delivered. To give a bit of context, we were about 40 product teams for almost 400 collaborators at the beginning of the transformation. Today, we are more than 70 product teams for 900 collaborators in the product organization.

Now, let’s dive in the OKRs journey at Veepee!

First iteration

The first iteration wasn’t going to be perfect, we knew that. The important thing was to start the process, to develop the habits. Challenging our objectives on a quarterly basis, learning to measure value, identifying our dependencies, and trying to align.

We started to implement the OKR methodology at tech level, not at group level. It was not by conviction, but rather a rational choice. Even with a lot of democratization, it was easier to move our own organization, the product organization, rather than trying to move the whole business at once. The rational was to start, to try, to show the benefits and then take each direction onboard.

Freedom was given to product teams to define, with their business counterparts, their OKRs for the upcoming quarter and to assess those of the previous one. The product governance helped the teams with the methodology, eased the relationship with the business and provide guidance to the product owners. At first, the purpose of the governance was not to challenge about the content of the OKRs, we basically trust the teams.

To give visibility, as a ceremony, we have defined the product boards to present the assessment and the OKRs for the next quarter to whoever may be involved. From direct counterparts to executive committee members. The main objectives of these boards being to ensure validation by the business of the value delivered by the product team.

The last point we defined for this first iteration, a bit later however, was to link the OKRs to the annual bonuses. We did it intentionally ; the idea behind this decision was to reward people based on the value they bring to the company. Without going into detail, the main ideas were as follows:

• At least half of the bonus linked to product OKRs. The other part being related to individual or organizational objectives.
• Have to reach 70% of the OKRs to be assessed 100%. This, to keep OKRs ambitious.

This topic in itself will give rise to a dedicated article, as, with hindsight, it is not certain that we would do it this way again.

Improvement over time

Our organization is our product. Based on this motto, we have tried to improve the way we apply OKRs, learning of our experiences.

#KRs, are you real KRs

First, on the OKR philosophy itself. We realized that most of the KRs were in fact: tasks. In itself, this is not an issue as it helps teams to go in a direction that has been validated with the business. So, why did we try to enforce KR, in the metric sense? Mainly because a task does not guarantee that we’ll bring business value. It only ensures that we have done the task. It’s commonly defined that a KR should:

• Be Measurable
• Be Traceable over time
• Define the starting value and the value we want to reach

Being measurable bring two main benefits. It ensures that there is no debate during the assessment as to whether or not the team has brought value to the company during the quarter. And this allows to ask the right question when preparing the next quarter, to really analyze what the impact of the team will be.

It takes effort to think this way, to define the value a team has an impact on. To define real KRs rather than tasks. But it is worth it when the analysis is done the right way. And it gives the team the autonomy to define the right action plan, to iterate during the quarter, to reach the KR. Today, our KRs are still a mix of measurable values and tasks. Mainly because:

• Some products struggle to identify the real value they bring. Their value being indirect
• Some products are linked to cross-functional initiatives
• We do not have the probes to measure the indicators

We are trying to improve the ratio, but, for sure, not to reach 100%.

#What about the company pace

What we have learned from our experimentation, is that it is not worth creating a cutting-edge product organization if the entire organization is not ready for it. I can admit it may sound harsh said like that. It is all a matter of pace, alignment and shared vision without which the results will not be as expected.

Part of our business, sometimes, was not ready to rethink processes and had other focus. Sometimes the relationship between business and tech was unnatural and they wondered how to improve the performance of daily operations. Or perhaps the mandate we had to make Veepee a tech company was not carefully defined and shared beyond the tech department. This led to situations of non-alignment where the product organization sometimes tended to try to guess what the company needed. This can work. When the product owner and the business create the right relationship. But not on complete flows, involving several products or business lines.

That’s where we introduced the Business Process Owner role (BPO). A position responsible for a global process on business side, aligning our different entities on a common process during our convergence phase, helping to measure the overall process performance and defining improvements that have to be made, whether supported by tech or not. When this role was introduced, without solving the issue at its root, it was a great help in defining the right OKRs and aligning with business expectations.

#Is the whole company aligned?

Setting up the OKR methodology at tech level was a first major step to move the organization forward. But we quickly noticed some drawbacks. Each team defined its OKRs according to what their direct business was thinking. Nice, right? But what about company main objectives? Why, even though each product worked with its direct counterpart, we felt lots of frustration at company level. As if the product organization was not delivering the right expectations.

It seems obvious, but not easy to implement in such a large organization. We needed OKRs at company level. Exco OKRs, then department OKRs and so on. And that’s what was done. We have now been able to link product OKRs to company OKRs.

Did it solve the issue? We will see that later in the article!

#Autonomy & governance

Autonomy is, and has always been, the motto of our organization. Each product team defines and evaluates its own OKRs. That’s fine to work this way as it develops accountability and empowers teams. But, as the organization grew, along with autonomy, we needed a layer of control to assess the product teams OKRs. Whether it’s about format compliance, overall alignment, ambition, or KR assessment. This allows to steer the organization knowing that we all go in the same direction, in the right direction.

This is the purpose of the product governance, to ensure this mission. To show where the organization is going. An internal tool has been defined to categorize OKRs and get an overview of the company strategy. The SIZE matrix … but let’s have a full dedicated article later on this topic.

What are we trying now?

Trying, understanding, learning and improving. As stated previously, our organization is our product, and we have not yet reached a point where the result is satisfactory. We have identified new points of contention and continue to try to address them. Let’s explain what we are changing at the moment, why, but without yet being able to say whether the expected results will be there or not.

#Company OKRs, yes, but less

Being able to define OKRs at company level has really been a great achievement. We thought we would be able to align teams through them. Well, the result in 2019 was not fully satisfactory. One of the reasons we analyzed was the number of the objectives we had defined at the company level. We agreed on 10 objectives and 29 KRs that covered the global activity.

In retrospect, it was way too much to help the teams to align. And some were too loosely defined to be truly structuring. Each team was able to link its own OKRs to a group OKRs and argue, quite rightly, that it was a priority. We learned that group OKRs have to be limited and strongly defined to be fully efficient. They have to be limited, to be top of mind for everyone in the company. For 2020, we agreed on 4 objectives and 17 KRs. Almost half as many! Let’s see the result in the coming months.

#O + KR + Task

As stated previously, moving from action plans (meaning Tasks) to real KRs is a long way and a big change of mind. On top of that, for some products that are not public-facing, aka technical products, the real value is even harder to identify. What we are trying, is to let teams define tasks instead of measurable KRs, but … but … by asking them to identify the flow they will create value in, and link their Tasks to the final KR of this flow. In short, to link their tasks to the OKR of the public-facing product. That’s where we introduce the concept of direct value and indirect value. Let’s take the time later to write a full article on this concept.

#Alignment in a large organization

In 2019, the product organization was composed of 13 tribes (between 40 and 100 team members and 5 to 8 product teams in each). While this tribe concept brings lots of benefits, such as ownership, structure around product teams, and synergy, we still see a lot of alignment and focus issues.

The question on how to clearly align teams on priority and keep them focused on it, was becoming increasingly important. We believe that focusing more the top management on delivery and shorten the decision path are keys to improve the alignment issue. That’s why we introduced the Domain concept. A grouping of tribes, with a single IT and Product leader closer to the tribes to drive the whole. Objectives given: a better alignment, faster decisions, and a better focus on main objectives. This would deserve a whole post as for now, it bring lots of benefits.

The learning curve is not over. We are convinced that our latest adaptations will bring more and more value. Let’s write an update in some months to analyze the result, and go into more detail on some key topics in further articles.

TL;DR

Why OKRs?

• To align the teams together, in the same direction
• To measure the value delivered

Learning

• OKRs have to be deployed throughout the whole company
• It’s necessary to find the right pace of transformation and the right level of maturity for the entire organization
• Company OKRs need to be top of mind
• Businesses must share, challenge and assess teams OKRs to well define what they want to achieve
• Product Governance is necessary to define a common way of working, to capitalize on learning, and to ensure the sustainability of the products

Current experiments

• KR is related to added value. Direct or indirect value
• Shorten the decision path. Bringing Technical and Product leadership closer together