Zalando—founded in 2008, publicly listed, and Berlin-based—is Europe’s leading online fashion platform. It is one of the platforms around which the online fashion sector has coalesced. Part of the Zalando strategy is to digitize fashion, moving the organization from a digital store to an online platform. From 2015 to 2017, it increased its digital infrastructure to 1,700 employees, up from 800, and the digital effort now represents one in seven (14 percent) of its staff.
Here, Eric Bowman, Zalando’s VP Engineering, talks to McKinsey’s Stephanie Cadieux and Miriam Heyn about his experience of the digital expansion and how it carries over to agile working at the front line.
McKinsey: First, what is your definition of agility?
Eric Bowman: Agility is just being able to respond quickly to changing business contexts. Beneath that, it’s being able to work well in parallel and to minimize the number of decision or alignment choke points. Imagine walking through a thicket of brambles. Agility is about cutting off the thorns of the brambles so that we can change direction quickly (Exhibit 1). There are so many ways that teams can get snagged: on technology, on organizational structure, on culture, on mind-sets. In a thicket, agility is about removing thorns!
McKinsey: What are the main benefits you have seen from agility at Zalando?
Eric Bowman: As a company, the benefit of agility is that almost everything that you do has the potential to start a flywheel: once it gets spinning, it can spin faster, and it’s harder to slow down. It becomes possible to grow teams and their impact, to compete in new industries, and to get more comfortable starting from scratch on new problems. In general, agility makes it much easier to compete.
Agility at Zalando enabled us to keep scaling our product vision, our platform vision, the scope of our business, and the extent to which we deliver value, impact, and satisfaction to our customers. And agility is not just great for the company. It’s also great for the company’s customers and for our employees. Customers get new features faster and experience dynamism in the business. Employees are generally much more engaged because they spend less time aligning and more time solving problems.
McKinsey: What was the situation at Zalando when you arrived in 2014?
Eric Bowman: Zalando developed in stages. Like every start-up, it was all about moving fast. The rate of growth was so enormous that we’d hit almost every scaling pain sooner than most. In technology, teams had embraced scrum-style agile methodologies, the standard way to work in the tech community in Europe, a best practice. I was Zalando’s first VP Engineering, focused just on the tech side. As we scaled the tech team, in particular, what we found was that both innovation and delivery slowed. Suddenly, we were paying more to move slower. And that’s about the time that I entered. I ended up doing a thorough analysis of how the whole development was working, of all the different things that I thought were hurting us (Exhibit 2). And the answers were a combination of how we were organized, how teams were working, but also how the systems were architected.
McKinsey: Can you describe Zalando’s journey?
Eric Bowman: Our first phase was using agile methodologies within engineering teams to allow them to manage their work in progress and to plan their work. The second big phase was scaling our tech team. And for this, we created radical agility, embracing purpose, autonomy, and mastery, and sacrificing our architecture [IT infrastructure and processes] in order to build for the future and a much larger team. The third transition was rolling these ideas out to the entire company, which involved embedding engineering teams all over the company (“tech everywhere”) and establishing the principle of dedicated ownership (Exhibit 3).
McKinsey: Can you explain radical agility?
Eric Bowman: We tried to pull together what we saw as all the best practices across our sector. We embraced Dan Pink’s ideas around purpose, autonomy, and mastery as a way to organize and to motivate teams. When we pushed purpose, autonomy, and mastery, what we found is that technical people in particular really resonated with the autonomy part because they were expert in such an important interdisciplinary area. These became guiding principles for keeping teams engaged and motivated and for attracting and retaining good talent (Exhibit 4). In fact a lot of this effort was about unlocking parallelism—concurrent activity: the ability for different parts of the organization to make decisions and then deliver impact without having to block on other teams, and without having lots of centralized alignment overhead. The overall system has to be amenable to people working in parallel.
McKinsey: This strategy requires the right structures; what were the lessons there?
Eric Bowman: Most company structures are set up to optimize consensus or the decision-making process. But agility really requires flexibility around how decisions are made. And so, people who become comfortable maybe making decisions in one way often have to change their thinking to make decisions in a different way. Finding the right organizational structure where people have real end-to-end ownership can be counterintuitive. But once that’s in place and people are comfortable with frequent restructuring to solve real problems that come up, it’s a necessary ingredient to being agile as a company.
McKinsey: What are those structures for end-to-end ownership?
Eric Bowman: There are three: first is what we call dedicated ownership, a holistic leadership role where one person is accountable for the work of a team or a group of teams that have been assembled to achieve some kind of end-to-end ownership. It usually combines business, product, and technology oversight. So, it’s really pulling lots of strands together: dedicated ownership can then lead a multidisciplinary team toward a common goal.
Here is an example: in online clothing retail, sizing is one of the main drivers of any return rate for us, [and that’s] a very important problem to solve. We want to make sure that what people order will fit them. One of our first senior and specialized dedicated owners was in clothes sizing. She was able to have people in the warehouse, data scientists, and commercial website people working for her; we were able to scoop together into an org all the people who needed to solve this problem.
The second is prioritization, a big part of traditional agility but even more important for agility at scale. Actually, at Zalando, we started by prioritizing everything as highest priority. And this very quickly led to a situation where we had too much work in progress. The projects that were most likely to fail were not necessarily projects that were complex but projects that touched many teams. We evolved a simple prioritization model to focus on the customer, on company priorities, and on local priorities; this was an incredible unlocking mechanism, allowing people to make decisions without needing to align. Simultaneously through that, we managed to significantly reduce work in progress.
And the third is the right scope of work (rightsizing) for employees. Here we were pushing against the idea that the only way to succeed is by having a large organization or having broad scope. We knew that depth is also extremely important, and we had to make people comfortable with the idea that sometimes their scope (but not their rewards) needs to be reduced in order to allow them go deeper. It’s extremely important as you scale, because every topic becomes increasingly more complex.
McKinsey: How did you remove structures that no longer work? What was your experience at Zalando?
Eric Bowman: Well, in general, changing your IT architecture is horrible. This is very often about decisions that are hard to change, so people are resistant to sacrifice it. But it’s often necessary periodically to basically start again with a new approach for a new scale. It’s a necessary part of growth, particularly to unlock that parallelism I mentioned. When you have a small number of people, work in parallel slows you down. But not in a larger organization. Very often what works at a small scale works against you at a larger scale. We think of these soon-to-go structures as sacrificial architectures. We must not be afraid to abandon what has worked well in the past, in terms of the architecture of a business or a technology stack.
McKinsey: OK, what were or are the effects on people that go along with these structures? Are any unique to agile operations?
Eric Bowman: We found that as we scaled, there was what we call the first-time leader problem, where people who were not necessarily on a leadership track were suddenly put in leadership positions. We had leaders who could not say no to the business or could not say no to their team. So we introduced a shared leadership model at the team level: one leader for about every 12 people, which was my goal. Shifting to agile means that leaders really have to change their mind-set, typically away from a purely functional view to that much more holistic view. Very often, this kind of transformation means that many leaders have less scope as you scale. And this can be quite uncomfortable at first. But very often, less scope is actually a sign of success.
Another impact was how we ran performance management, an incredibly important facet of radical agility. Making sure that people are fairly compensated and that they are hearing the feedback that they really need to hear are both really important dimensions of how we build trust.
And here is the key: high levels of trust. Trust is a friction area: if it’s missing, almost everyone is wasting time trying to understand what people really meant, what they’re trying to say. But establishing trust is a great simplifier, in terms of all of the interactions that people have day to day. If people are known to be straightforward and authentic, then you can communicate simply and clearly. And alignment becomes much, much easier and cheaper. With the right level of trust, a problem becomes like a cry for support, not an opportunity for emotion.
McKinsey: What else do high levels of trust enable you to do in terms of managing responsibilities and accountabilities?
Eric Bowman: At the heart of all this is a trinity of trust, accountability, and autonomy. Here’s how I think of them: we achieve accountability and autonomy through the dedicated ownership model, and both rest on trust. Accountability is something that cannot be shared (unlike responsibility). We want people to make decisions. But we need them to be accountable for the outcome of those decisions in a very nonblaming way; that is where trust fits in. We also want them to be autonomous. But autonomy without accountability is called vacation. And when things go wrong and people have made questionable decisions, we have a process of review: “Well, how did you get there, really?” So autonomy is learned and earned. [That’s] all on the basis that good judgment comes from experience and experience comes from poor judgment.
McKinsey: What are the processes that serve both your structure and your people?
Eric Bowman: First comes unblocking, essential for achieving parallelism. In a large organization, there are many things which cause people to block. And going through them bit by bit, structuring the organization, looking at individual workflows, how alignment happens, how meetings happen, truly unblocking, this requires looking at every part of what we do, finding every thorn (as it were) and removing it, so that people can move quickly to make decisions and have impact.
Second is deciding what processes to keep, improve, and standardize. For us, this meant standardizing the rituals in what is expected from a team or from a dedicated owner, and in how we measure success consistently, and so that people can, for example, move to different parts of the company. By rituals I mean the cadence of meeting, reporting, and assessing. Rituals provide this constant source of energy into teams—very useful for setting expectations. And they allow teams both to talk about their failures and how they’ve learned from them, and also to celebrate their successes.
But these rituals are also important for scaling leadership. Giving people a regular forum to demonstrate leadership, show leadership, and to show their growing mastery of different topics is one of the most important factors for scaling leadership at a large organization.
We have rituals for product reviews and around operational performance and around project steering. Bringing people together on a regular cycle in a positive and constructive atmosphere exposes people to different ways of thinking and different parts of the business. It also makes people very comfortable, because it’s almost like clockwork. And what’s expected of them becomes increasingly clear over time. So they get better at satisfying what are the key expectations and how can they get better.
McKinsey: How about that process of setting the expectations?
Eric Bowman: We use KPIs [key performance indicators] because they are one of the most important aspects for achieving agility at scale. But here is where this differs from other approaches. The agile way is to map the work that people do to an ROI [return on investment] model and to grow the concept of KPIs to make sure that those KPIs are proving or disproving that ROI model. The ROI model is incredibly important for helping teams prioritize what are the most important things to do and what has the biggest impact on our customers and the business.
The five trademarks of agile organizations
McKinsey: Let’s return to technology; how does radical agility work in your part of Zalando?
Eric Bowman: One of the challenges in enabling the parallel working I mentioned is finding what are the right things for us to standardize on. And this comes down to how we standardize on technology, how we standardize on process, and how we standardize on rituals. Finding the right balance so that we can continue, for example, to advance our technology stack, while still having the right standard so that the system keeps working in the presence of change, is extremely difficult and takes time and a lot of alignment.
Essentially in tech we’ve tried to get away from the traditional matrix model. Almost every start-up that has a tech team grows that tech team separately. There comes this point where the alignment becomes too difficult and you have to integrate all relative concerns under a single leader. And then that leader has to learn how to lead those teams. This is not a new idea, basically. We all know you have to have multidisciplinary teams. But each team must be able to decide for itself. This is multidisciplinary teams at scale.
McKinsey: So how do you impose and maintain technical standards and compliance?
Eric Bowman: Part of enabling agility for us is getting everybody used to choosing the best tech tool for the job. Whether it’s an internal tool or not, we’re well set up to be very flexible in that regard. We can tolerate duplication and overlap. It’s more important that we succeed as a business than that we say, “Don’t duplicate certain parts of our tech stack.”
We have plenty of autonomy built into our tech organization. For example, teams don’t necessarily have to use the infrastructure that we provide. We would like them to. We think that will save them money, it will make them go faster, and all these different things. But, for example, we can acquire a company and find that they’ve opted out of everything. It’s fairly common for them to pick and choose what they will opt into in terms of our existing tech stack, which processes matter. So we use “inner source,” the internal company version of open source, where we prepare teams to expect that other people will come along and make changes to their systems. It also raises the bar for some of the hygiene factors around how they work. They have to have good documentation. They have to have good automated testing. And, in general, they have to be more comfortable with more people reading their code.
McKinsey: And what are the lessons you can draw from this journey into agility?
Eric Bowman: What scales is principles. At Zalando, our principles are enabling parallelism and unblocking or minimizing the frictions, finding the right size of work for each person.
Actually, we’re less prescriptive about which agile methodology works. We are interested in creating these end-to-end organizations within the company that have the right accountability and autonomy models and the right incentive alignment to really make sure that we can move in parallel.
