The journey to an agile organization at Zalando
Europe’s
leading online fashion platform embraced purpose, autonomy, and mastery to
build agility, explains VP Engineering Eric Bowman.
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?
Play Video
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. 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. 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.
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. 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.
Play Video
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.
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.
By Stephanie Cadieux and Miriam Heyn
https://www.mckinsey.com/business-functions/organization/our-insights/the-journey-to-an-agile-organization-at-zalando?cid=other-eml-alt-mip-mck-oth-1804&hlkid=a71b7ecde4de42d88e0f8fe621a70b50&hctky=1627601&hdpid=f84e8fae-4e89-4b4a-84a1-39b17653d791
No comments:
Post a Comment