Scaling Autonomy at Zalando

Autonomy isn't something you can just give to a team, it’s something that teams learn and earn over time. It has to come with accountability to amplify working towards a purpose. At Zalando, creating the right architecture and organizational structure reduced the amount of alignment needed and freed up the energy to be more thorough where alignment is needed.

Eric Bowman, VP Digital Foundation at Zalando SE, gave a talk titled “Organized Autonomy: Cracking the Paradox” at Agile Summit Greece 2018. InfoQ is covering this event with summaries, articles, and Q&As.

InfoQ interviewed Bowman about how they scaled autonomy at Zalando.

InfoQ: What makes team autonomy so important?

Eric Bowman: Autonomy is essential for getting the best out of great people. Dan Pink is right that autonomy is a crucial ingredient for sustained intrinsic motivation. When we can create a context where autonomy works, it is a powerful force for engagement and creativity. Autonomy is also essential for scaling a large organization that continues to innovate. Centralized decision-making doesn’t work beyond a particular scale, and so for a modern company to continue to grow, it has to figure out how to distribute decision-making to get stronger over time through the right feedback loops. We want autonomous teams that can move in parallel since that is the most efficient and powerful application of all the resources we have to bear. Once parallelism is unlocked with the right feedback loops in place, an organization can move fast and adapt quickly and feels like the most enjoyably efficient way to provide massive value to both customers and the business.

In the InfoQ article Don't Copy the Spotify Model, Marcin Floryan mentioned that “Autonomy is futile without alignment”. Achieving autonomy is very hard, there are lots of challenges. He gave examples of things Spotify does, like giving trust to people, providing them the right information, and giving purpose: “You have to have a purpose in your autonomy to make people do the right thing”.

InfoQ: What challenges did you face when working to create a culture that provides autonomy to teams?

Bowman: Our biggest challenge was that we treated autonomy like an input to teams: we needed their help to move fast, so overnight we increased the autonomy of all our software teams, and we expected good things to happen as a result. What we learned is that autonomy is more like an output of the team -- it is something that teams learn and earn over time. We see autonomy as an aspiration and a reward, not a gift, which is a change from where we started in 2015. I agree with Marcin’s point -- the analogy I use is that unaligned teams are like the air molecules in a balloon: moving fast but not running together as a group. Where I disagree is around alignment -- obviously, autonomous teams and leaders have to align, but solving the alignment problem for us was more like a side-effect of solving what we see as the core challenge of enabling and scaling autonomous teams. The solution, for us, is an effective accountability mechanism to amplify our work toward a purpose, not just purpose alone. 

Kent Beck tweeted in April 2017, “Autonomy without accountability is just vacation.” This tweet resonated because it reflected what we saw as the core learning from our initial approach to agility (which we called Radical Agility): that accountability is like the mathematical dual, or the other side of the coin, of autonomy. Almost like good vs. evil, each requires the other to have meaning. By not implementing an accountability model as the currency for earning autonomy and trust, we denied teams the chance to learn how to become more autonomous. We didn’t fully realize the opportunity to take innovation to the next level by unlocking all these amazingly smart people we hired to work toward a common purpose.

This is a departure from Dan Pink and Drive, where he wrote, “Motivation 3.0 begins with a different assumption. It presumes that people want to be accountable -- and that making sure they have control over their task, their time, their technique, and their team is the most effective pathway to that destination.” We don’t agree. Our job as leaders is to make accountability something to which people aspire. Accountability has different implementations, some empowering and some horrible. We strive to implement a humanist form of accountability consistent with our values and a culture we wish to work in every day.

Accountability has somehow a lousy name in agile. People tend to associate it with counting coins. However, for us, accountability is more like, “to give an account of.” When we talk about accountability, we mean the following: energy, transparency, and commitment around a set of goals, their achievability, the plan to get there, and progress to date. Being accountable requires an openness to being evaluated on whether you achieved your goals. When you have all these components in place, alignment is a natural byproduct: you can’t state ambitious goals you honestly expect to complete, and report progress against them, without having aligned. Finally, you need experienced tech leaders who understand that software delivery is hard and rife with essential ambiguity, that you uncover many unknowns along the way, and that there’s a reason for agile methodologies, even if they are not the whole solution.

InfoQ: How do teams align at Zalando?

Bowman: We started using OKRs in 2015, and we introduced a couple of conventions around the OKR process to help alignment. First, we considered a 0.3 scoring as a form of commitment. Each team committed implicitly to complete the work to achieve a 0.3 score.  Second, we held company-wide OKR alignment weeks as part of the OKR planning phase. And it went ok -- something is a lot better than nothing.

As we’ve continued to scale, we’ve learned that it’s vital to structure (and restructure) an organization (of nearly any size) in a way that optimizes for end-to-end ownership of customer experiences and business outcomes, and to service the needs of a single customer group. We found teams with lots of different customer groups end up with impossibly hard alignment and prioritization challenges, unable to benefit from this profound simplification heuristic: there are many things we coulddo, but why don’t we start with what our customers want? 

A simple case could be a team building software for, say, both our fashion customers and our fashion buyers. We see this as an anti-pattern -- better to have two teams, in this case; one for each group, and two leaders as well. Probably they belong in entirely different parts of our organization, even if long ago these systems were created by a single team intent on creating an end-to-end solution.

The leverage achievable through using organizational structures to simplify and optimize alignment and prioritization ultimately drove us away from a single, monolithic Tech organization -- it had too many customers for us to prioritize and align well. Instead, we embedded engineering teams across the company to form self-contained units capable of solving customer problems end-to-end. One symptom of an organization with too many customers to efficiently align and prioritize is an overly-internal focus as it tries to diagnose what’s going wrong, which further exacerbates the problem.

Applying these constraints at scale requires an accommodating architecture. We have an architecture for a microservice approach to front-end development -- the open source Mosaic project. Mosaic enabled us to break apart a monolithic front-end and distribute it through the business to allow more end-to-end ownership for different parts of our customer-facing businesses. This architecture and the organizational structure it enables leads to teams with fewer business-related points of alignment; instead, the alignment happens more locally, and at a lower frequency around technical contracts. By reducing the amount of alignment needed, we freed up the energy to be more thorough where alignment isneeded. Many companies underestimate the extent to which some pernicious combination of Conway’s Law and legacy prevents them from building true end-to-end ownership into the organization. Not being able to do so increases complexity almost exponentially which massively slows down product development. The right architecture is essential if you want to see these principles work in a large organization.

We’ve also improved the mechanisms we use to prioritize at a company level, which helps reduce the amount of overall alignment needed by injecting prioritization rules simultaneously across the company. We do this by layering a prioritization for company-wide initiatives on top of the OKR process. This gives most teams the tools and context to make good decisions on behalf of the company, autonomously. For example, we used this mechanism to implement GDPR: we had one team do a lot of work to figure out what had to be done by all our teams, and once that work was complete, we activated a company-wide Global Project to get it done, requiring the attention of many teams for a short amount of time. This approach drove us toward an efficient plan: the standards to become a Global Project meant that a lot of legwork was completed early to understand the scope of the work, and once the project phase kicked in, it was crystal clear to everyone across the company that GDPR took priority over everything except customer-facing operational issues.

Finally, we found that a set of principles and systems scales better than a set of prescriptions. While it is important to have practices like, “this is how we align”, our best practices necessarily change over time. Principles and systems have more staying power by allowing for evolving practices, and even encouraging them. Principles lead to higher-order mechanisms and feedback loops that lead to rapid “eventual alignment.” Alignment becomes an indirect consequence of the principle-driven decisions by leaders and teams striving to earn autonomy. An accountability model and growth mindset around “the account” and its evaluation can be structured into mechanisms, feedback loops, and especially review rituals that help unlock the value trapped in a growing organization.

InfoQ: What did you do to keep the strengths of a startup when the organization started to grow?

Bowman: I think we’ve kept the strengths of a startup through the uncompromising mindset of the founders and early employees, captured in what we call our founding mindset: customer focus, entrepreneurialism, speed, external focus, awareness of opportunities, learning fast, playing offense, acting decisively despite risks, simplifying for speed and focus, and making it happen. It sounds like a lot, but these ideas weave together into how our business thinks and acts, and is a core strength. Years ago, the idea that we could build our warehouses and the technology to operate them -- and make it all profitable -- was almost inconceivably bold. But we succeeded precisely due to this mindset. More recently, we’ve rolled out new countries (Ireland and the Czech Republic), a new category (Beauty), and entered whole new businesses that leverage our platform (e.g., Zalando Fulfillment Solutions) by fostering and growing this founding mindset in our people. And we’ve had tremendous success hiring great people across the company, who bring more strengths and diversity of approaches into the mix, and even as we reach ten years as a company, it still feels young and endlessly creative.

InfoQ: What’s your advice for leading autonomous teams?

Bowman: The most solid advice I have for leading autonomous teams is that autonomy is an aspiration, not an input. One can’t just give autonomy to a team and expect great things magically to happen without remarkable fortune and a remarkable team. Rather, leaders must help teams learn and earn trust by incorporating a simple accountability model and a gentle assessment feedback loop to establish a currency for acquiring autonomy.

When it works, it provides the mechanism for a team to get better continuously and to start playing from strength to strength through a sequence of accounts: the story of the team over time. For every setback or misstep, the leader has to help the team see it as an opportunity to learn and improve, help them seize that opportunity, and then help everyone learn from it. She needs to be comfortable being accountable for the output of her teams and to be a role model for accountability. As the team learns and earns autonomy, so too must the leader, and doing so at scale is a magic ingredient for how to grow a large organization that continues to deliver and innovate at a growing pace. Leaders play a foundational role in reducing complexity as connectors and simplifiers, and as a consequence of there being fewer of them. Alignment and communication, when done with skill and care, is more natural, more powerful, and more human than any leaderless self-organizing system. Don’t believe the hype!

Finally, what we see is a tendency in struggling tech organizations toward overly internal focus that must be deliberately avoided. This phenomenon can manifest as too much emphasis on tools and methodology, or culture, or organizational philosophy. Our founding mindset has been useful to keep us focused on our customers’ problems and how we can solve them. There is no known -- let alone perfect -- solution to the hardest challenges of a growing business. They still require energy, flexibility, creativity, and good situational instincts to solve, plus a little luck -- precisely the core of what it means to be agile.

About the Interviewee

Eric Bowman is VP Digital Foundation at Zalando, Europe’s leading online fashion platform. Bowman leads a team of 500 focused on leveraging Zalando’s scale to help every part of the company’s digital business to innovate faster for less and disrupt how the world connects to fashion. As Zalando's first VP Engineering, he led the engineering team through the architectural transformation to microservices, cloud, and SaaS, and was one of the founders of Radical Agility, Zalando’s unique tech culture.  A 20-year industry veteran, Bowman has been a technical leader at multiple startups as well as global companies including Gilt Groupe, TomTom, Three, Electronic Arts, and Maxis, where a lifetime ago he was one of the original three amigos who built The Sims 1.0.