Pulling in the same direction with autonomous teams

Why would you want to have autonomous teams in the first place? As I see it, they have two main benefits.

1. In complex contexts, they out-perform organizations of functional silos, because they can make faster and better decisions where the work is happening.
2. They are more rewarding and motivating for the individuals working within them, because they offer them more autonomy. And as we know from Daniel Pink that is a major driver for motivation.

The question then is: If teams operate independently from each other, how do you get them to pull in the same direction? I think, we are doing pretty well in this regard. And I think, I identified the 3 core ingredients that make this work well for us.

This post is about how we get from a company strategy that is set by about 10 people to an executable plan that is carried out by about 200 people in 13 teams.

Imagine you sit in a room with the rest of your colleagues while the CEO is presenting the company strategy for the upcoming year. The natural question you would ask yourself is: “What does that mean for me?. What am I supposed to do? And how is that different from what I was doing yesterday?”

There are three main components that turn the vagueness of the strategy into certainty of an executable plan. This certainty is a basic human need. When we don’t have enough of it, we feel insecure and uncomfortable. But when we do, we feel at ease and confident and we can perform at our best.

We don’t manage to do what I am about to describe perfectly every single time with every single team. But this is what we strive to do. I am also assuming that the strategy is derived from some grander shared purpose. Without that any strategy is going to be pretty shallow and uninspiring.

Once a year, sometime in January the leadership group of the company (in a magical process I won’t go into) comes up with the strategy for the upcoming year. And then we all meet in the atrium and we talk about it. This sets the direction and boundaries for everything that follows. We try to keep this strategy front and center by looking at how we are doing once a month in a town hall meeting called strategy monthly. Plus there is a quick reminder slide in our weekly town hall. Trust me, by the end of February everyone knows the current strategy slide inside out.

Objectives and Key Results (OKRs)

The first piece of the puzzle to break this strategy down into digestible pieces are OKRs (link). When I started at Stylight in the beginning of last year, I think it is fair to say that I was sceptic of this whole OKR thing. I didn’t really understand how they were supposed to be different to quarterly targets that are set by people up in the hierarchy, which I am pretty sure, don’t fit in my ideal model of an organization. By now I’ve come to terms with them and here is how I understand them now. OKRs consist of two parts:

• A set of inspirational, qualitative Objectives, for instance “Value and improve employee satisfaction”
• 1–3 accompanying Key Results per objective that make it measurable, for instance “Improve 1 employee satisfaction score by 5% compared to the June baseline by end of Q3”

We do OKRs quarterly on a team level and anyone within the company can open the OKRs folder and check out any current or past OKRs of any team.

I think, OKRs have one major benefit. They help us get to a shared understanding of the objectives of each team and how they relate to the company goals. They make it comprehensible what success looks like for each team.

It feels like having a grasp on (at least on a high level) what everyone within the company is doing.

I think, the key to successful OKRs is letting teams own their OKRs (process and content) within the boundaries set by the strategy. Our process goes something like this:

• Teams have one or several facilitated sessions where they come up with OKRs they think would be most valuable for the company’s strategy.
• Afterwards those OKRs are challenged by other teams.
• And finally, teams may then adjust their OKRs given that feedback.

What I find interesting and what I didn’t foresee: This allows us to have a discussion about to what degree we are focussing on customer or company problems — which are not always the same things. It’s usually the teams that push for more user focus whereas management is more focussed on business KPIs like revenue.

To keep OKRs alive and useful, it’s not enough to define them at the beginning of a quarter and then check in the end if we reached our key results. We continuously talk about them. Every week a representative of each team presents their progress (or lack thereof) of one or several KR at our weekly town hall meeting.

There is a few things to keep in mind that we need to remind ourselves regularly of:

• OKRs exist to set clear priorities and to align the organization towards the same goals.
• We need to talk about outcomes, not outputs, not roadmaps at this stage. That comes later.
• We cannot use OKRs for employee evaluation. If we do, people will sandbag their forecasts and game the system.
• There is a real danger of only being driven by quarterly numbers and losing sight of long-term success.

Sprint planning

The second piece of the puzzle is sprint planning. What is it? In one phrase: regular planning sessions to build a product incrementally. Our sprints are two weeks long and they help us focus our efforts on a team level. Two weeks is a timespan people can actually fit in their heads and are able to reason about.

If OKRs define what we want to achieve as a company this quarter, sprints are telling us what step towards that, we as a team, can take today.

All our teams get away with about 1h of planning per 2-week-sprint. They achieve this by keeping planning focused on shared understanding on a high level.

“Complex” tickets — which we try to avoid — have a separate kick-off session during the sprint right before someone starts working on it with only those people that are actually going to work on it. Ironically, this requires our teams to be comfortable with some uncertainty on a ticket level. In order to get to that shared understanding and enable anyone on the team to work on any ticket, planning must involve the entire team. The actual plan is not even important and it might be altered throughout the sprint. It’s really the activity of planning together and the resulting shared understanding that are the essential outcomes.

The prioritisation of work in our sprints is informed by the team’s OKRs and the results of a sprint are supposed to pay into those OKRs. Most tickets describe what key result they are supposed to improve. And then we measure if it does. We A/B test a lot. The sprints split the work into chunks that everyone can keep in their head, which consequently makes them actionable.

UX research

The last piece of the puzzle is UX research. Its role is to bring the perspective of our users to everyone within our teams. And then as a team, to provide the best possible experience for our users. We build a commodity product. There are plenty of others that provide a similar service as we do. We need to build a product and a brand people love. Building a product people love is the only way we will stay in business. If we fail to evoke emotions in our users they will go and use one of our competitors to shop.

We have UX research specialists within our website and mobile teams. They set up a UX lab, which is basically a living room in our office.

We have people come in on a regular basis and we “perform tests” on them. Each session is assisted by a random team member, which is very powerful. There is nothing more humbling than observing someone aimlessly tapping at a screen and “not getting it”. For all team members that don’t attend, the session is streamed on a private channel to watch live or sometime later.

What makes life a little harder for our UX specialists (and designers) is that we ask them to do this incrementally in sync with our iterative development process. I assume, this only actually works well, if they are deeply embedded in the teams. But this is an ongoing debate.

The UX researcher role is a support role to help teams understand our users. It is explicitly not only her responsibility, it’s a team discipline. She shouldn’t be the only one talking to users. It’s all about shorter feedback cycles from users to developers. Making a UX researcher an intermediary step in this feedback loop would be counter-productive.

Each quarter, once we are done with defining our OKRs, teams do an ideation day that focusses on how they can reach their objectives. UX research guides the work in our sprints by having a regular cadence for user tests — just in time to influence the next sprint planning.

What I think we are not very good at — and what I would really like to see more of — is that UX research steers our strategy. Our strategy at the moment is very much driven by revenue numbers.

And that is — in broad strokes — how we get from a yearly company strategy to executable plans for 13 teams. I think, these three puzzle pieces are the most important ones to turn the vagueness of the strategy into a concrete plan that people can act on. They do so by providing certainty on an organizational, team and market level.

If culture eats strategy for breakfast than these practices are probably just a side dish.

• If your teams’ OKRs are actually targets that are set from above, it won’t matter that you called them OKRs, you won’t get alignment.
• If your planning sessions are lifeless and people play on their phones while a “product owner” tells them what to do the next two weeks, you won’t arrive at a shared understanding.
• If your UX researchers are actually making the feedback cycle longer instead of shorter, you won’t build a great product people love.

If these practices will really help you to empower your teams to be more autonomous, depends on how and in what context you apply them.