Following a series of articles on “how to set good objectives”, I wanted to share a reflection on the toolbox we are setting up at the moment to manage alignment at scale.
Disclaimer: more than a suite of tooling, it’s rather a sharing of the core concept we are developing.

As stated in a previous post, at Veepee, we are experimenting the OKR journey for several years now and we are still learning from it. This toolbox, in its case, is in addition to the OKRs. Hum… a first question could be (should be) asked: why do we need a complement to the OKR framework?

The main reason is the context! We have defined the product teams’ organization to handle the large Veepee information system by developing ownership, accountability, specialization and autonomy of the teams. But, on top of this, we are managing some huge company transformation programs that need a lot of alignment, a lot of synchronization, and create a lot of dependencies. Yes … put another way: in one hand we wanted to decouple the organization, and in the other, we created strong coupling with the transformation program. In retrospect, this is the life of many companies, having several rhythms depending on the period. And without breaking the whole organization to get through this time, we have to adapt.

Adaptation

The needs in adaptation can be classify as follow:

# limited scope
That’s probably the main issue to fix. Having several teams specialized and focused on their scope, with a lot of autonomy can bring to silos where the “whole” is not seen anymore. That’s our role as management and leadership to put all our effort in bringing the global system vision inside every team so that they can make the right choices.

# many priorities & stakeholders
It’s easy to be lost in priorities. Every topic is important for the one who brings it. And, as a product team, there are a lot of inputs that need to be prioritized. Even when the OKRs are defined, to reach the goal and deliver the right value in the right timing, we felt the need to assist in the prioritization process.

# lot of frustration
This one is the result of the two previous ones. The focus on a defined scope, the difficulty in the prioritization, and the dependencies due to the transformation programs bring a lot of frustration as we felt we were not delivering the right value to the company.

That’s where we analyzed that we needed, in addition to the vertical organization (product teams), a horizontal organization. An organization where we think flow rather than only perimeter. Where we see the global process rather than part of a process. Developing a stronger focus on the value to deliver, on the global outcome of the organization rather than outputs. While keeping the values we believe in: Accountability and Ownership.

Toolbox

Now let’s try to describe the philosophy we are trying to adopt. Again, I will not describe here a proper set of tools, but rather, the philosophy we are developing.

It all starts from the yearly group OKRs. What the company wants to achieve this year and how we will measure these results. As we are in a huge transformation phase, these KRs are both, related to the company usual business and related to the company convergence. That second part taking an important percentage of the OKRs. That’s probably the root cause of our adaptation need. By trying to summarize:

• Business OKRs fit pretty well with the product organization in itself, as every team can improve part of the KRs on its own perimeter
• Convergence OKRs need way more alignment, as they are by definition, cross to the organization

That’s where we introduce the notion of flow. A subdivision of an OKR which will allow to reach the objective. The main characteristics being:

• To be a transversal initiative, through several product teams
• To be linked to a main OKRs

In a nutshell, a flow is composed of:

• A unique ID to be able to link road-map items to a flow
• A clear & a self-sufficient definition
• An owner
• The criteria of success A list of products that have an impact on the flows The size of a flow really depends on the organization and the objectives you have to reach. As an indication, some of our flows can be handled in a quarter, and some need more time to be fully managed.

Example - Taking the following Objective
Objective: Optimize financial processes lead times
KR: Reduce monthly financial closing lead time from X days to Y days
Some flows example could be:

• Trading procure to pay
• Inventory valuation accuracy
• B2C orders to cash

Then, comes perhaps the more interesting part of the exercise. The one that allows to really think about the impact of a flow, its dependencies and its weight. That’s what we call the HeatMap. A simple but effective tool to measure teams contention and the weight of a flow. As simple as a spreadsheet, having in lines the products of the organization, in columns the flows. And as value, a weight, going from 0 (no impact) to 4 (100% of the team workload), that represents the impact of the flow on the team. Heatmap example

Where are we now? We have a list of main objectives for the company for the coming year, their decomposition into flows, and the pressure of these flows in the whole organization.
It’s now the time to think shorter term: at a quarter level, and prioritize the flows in the order we want to tackle them during the quarter. That’s where the heatmap brings all its strength. Thanks to the impact of the flows on the different teams, we are able to analyze if the priorities that has been set put too much contention on some teams and so, review them.

This list of prioritized flows is now a major input for the teams to define their own OKRs. Depending on their scope, they can have more or less freedom. The only rule: their OKRs must answer first to the heatmap flows, and then, to their direct stakeholders. That can be seen as a lost of freedom and ownership, and it’s partially true. True because the global organization defines the main flows that have to be tackled. Partially as product teams have the complete freedom on the way to achieve it. The heatmap is only a way to assure alignment between products, and then, remove frustration due to not aligned dependencies.

Last but not least, once the product teams OKRs are defined, we can map them in a matrix with all flows and every products impacted. That provide an understandable view on how the organization will handle the main priorities. And, by the way, it also allows to check that there are no holes in the racket…

This, has to be built with the business AND for the business. In addition to helping align the organization, it allows the business to fully understand the impact of decisions and the potential impact of new priorities!

TL;DR: Think flows!