Secrets of design leadership—from Stanley Wood of Spotify

Designers are frequently finding themselves in leadership roles as their craft holds greater sway on product performance.

But too few designers are prepared for the transition. Management and scaling a team just aren’t taught in most design curricula. To level up, many designers pour over management best sellers looking for the insights they need, but exceptional design leaders—like Stanley Wood of Spotify—go further.

Curious to learn how he might both improve his skills as a leader and optimize his team’s processes, Stanley hopped on a plane from Stockholm to California and visited 20 top companies in the software industry—Dropbox, Google, Facebook, LinkedIn, Airbnb, and more—in search of the secrets of design leadership. Stanley filled 2 notebooks with insights and patterns that are reshaping the way he and his colleagues work at Spotify.

I sat down with him for a chat about the lessons he’s learned from his investigative journey.

The intro

Aarron Walter: Hi, Stanley. Let’s start from the beginning. At what point as the Design Director at Spotify did you start to feel like you needed to learn more about design leadership and how to structure the team?

Stanley Wood: Over the past 4 years we’ve been building the design foundation at Spotify. And I’m super proud of the progress we’ve made establishing this discipline in the company. But a lot has changed since I joined. Back then we were 6 designers, and today we’re a much bigger team, spread across multiple locations around the world.

When the challenges of our new size really started to show, I sent a survey to our team to understand how we were doing. Just a simple Google form. What we heard back helped us to quantify where we were in relation to our expectations and helped us identify where our opportunities lay.

Aarron: What did you do with that information, and who did you have to convince?

Stanley: This was an important lesson for me. I learned to sell the problem before the solution to activate change. I’d always sold change by selling solutions and then finding myself stuck debating and defending why it was so much better than what existed. The curse of being a designer is you often jump into problem-solving mode. I now try my best to always ensure there’s a demand for the problem before supplying any solutions.

Up until this point I’d soaked-up a lot from design and leadership books, but more and more I was struggling to find answers there. The challenges we were now running into were getting more and more nuanced, like how do you organize designers relative to tech and product? What if the team is large and distributed globally? How do you balance speed vs quality when shipping? Or how do you map an holistic experience to autonomous teams? We’d come far with our design principles and design language (GLUE), but there was still more to be done.

Around this time I was put in touch with Mike Davidson, former VP of Design at Twitter. We talked on Skype for a good hour or so, exchanging notes on similar challenges and conclusions. It was sobering, and inspiring, to hear how others had gone through similar struggles and had worked their way through them. It was also a great predictor on what challenges might be waiting for us up ahead. This conversation was more relevant and impactful than any book I was reading on the same subjects. I was hooked immediately.

Shortly after that call, I wrote down a list of companies whose design leaders I wanted to speak with. I was thinking about people who I could learn from, who had or were dealing with similar challenges, and who were turning things around in different ways. I knew we’d learn a lot from an active and honest exchange with each other. I was also certain I didn’t want to have the internet or comic version of how they worked. That first conversation had taught me details mattered.

So I decided to visit them in person. And last summer, I flew, Ubered, and trained my way across the United States, visiting roughly 20 companies to meet their design leaders.

The tour

Aarron: How were you received as you visited all these companies? Did you find that people were willing and open to share?

Stanley: To be honest, I wasn’t sure how I’d be received as we hadn’t met before, but they couldn’t have been nicer. I found that as design leaders, we often have a shared perspective or experience even when we come from different companies or different countries (Spotify is based in Sweden). Sometimes it just takes someone to reach out and get the conversation flowing and all of a sudden we recognize what a strong and supportive community we have with each other.

Things normally kicked off with me reaching out to them via Twitter, LinkedIn, or email, then arranging a time that normally meant coffee or lunch (their calendars, similar to mine, required some mad Tetris skills). From there, we’d begin with a tour of their office. It is fascinating how much of the culture you can soak up just entering the reception and walking around. Each time I remember being glad I’d followed through on visiting them in person. After that, we’d grab a meeting room and begin the conversation.

The conversations lasted 1-2 hours. I’d begin by sharing the challenges I was facing then they’d share what they had learned. It didn’t ever really follow a common structure and we often both had as many questions for each other.

After about 10 meetings I started to identify certain patterns. I think having all of these interviews in a compressed period of time really helped. Though it was pretty full on. I remember one day having breakfast with Google, lunch with Dropbox, and coffee with LinkedIn. But it was all worth it—I learned a lot.

To capture everything, I’d either record the conversation on my microphone, write it in my notebook, or photograph the whiteboard we’d been scribbling on. It turns out all design leaders love drawing on whiteboards. By the end of the trip I had filled 2 notebooks and 2 memory cards.

Related: The whiteboard—draw up some teamwork

Aarron: What did you talk about?

Stanley: Though the topics varied, there were 3 main themes I wanted to understand:

1. People. How are they organized both at a functional level across tech, product, and design, as well as on a mission level? Are they organized around platforms or are they organized around the user journey or features, etc.? I also just wanted to know where designers sat. Did they sit as a function, or did they sit embedded? How many locations were there? What were the pros and cons and challenges that they faced? And how many designers did they have? I was super curious about that, too.
2. Process. What were their processes optimized for? How do they balance between speed and quality?
3. Tools. What tools do they invest in to make all of this easier and better? Like design systems, prototyping, etc.

Aarron: I’m curious about the common problems that you saw, because it sounds like you saw common solutions and we definitely want to talk about those, but were there also common problems? Did people have shared pain?

Stanley: It turns out we all struggle with a lot of the same problems. We’re all just figuring it out as we go along.

The problems that came up often were things like: who’s responsible for what? How do we align across such a big team? And where should we sit?

The seating was a funny one. It’s deceptively simple—I’d never have expected it to have such a massive effect on how people behave or the effect it has on the size of the teams.

For example, in companies where designers sat together in their function, I saw that they didn’t invest in design guidelines. Being in such close proximity, they knew whether the UI components and patterns were consistent, whether that flow was consistent with that other one and so on. They got a hive mind for free.

Whereas in other organizations, where designers might be distributed across many platforms and feature teams, you’d have a weekly routine to create that hive mind. This could be reviews, critiques, or just a roundtable snapshot of what was going on. In this setup, the design organization was often larger and required more management to support it. It was also common in this setup to see companies invest in a central team to maintain their guidelines and bridge any gaps. Something similar to what we’ve been doing at Spotify with GLUE.

Albert Shum, VP of Design at Microsoft, also had this excellent insight about timing and context when thinking about where designers should sit. When you need to truly innovate on something, you need engineering and designers to co-locate. Whereas when it’s more incremental work, it doesn’t matter as much.

The power of the org chart

Aarron: What were the common solutions you found? You said you filled 2 notebooks. How do you condense that down into the most salient things?

Stanley: Well, I drew a lot of org charts, which I used to think was the epitome of corporate bullshit and was to be avoided like the plague, but it ended up providing me with the best snapshot for what a company seemed to be optimized for, consciously or not.

For example, I have this drawing in my notebook of Airbnb’s org chart with the line, “Don’t ship the org chart, ship the org chart.” It’s underlined twice because I thought their setup was so great. Katie Dill explained that Airbnb have a constituent model, meaning they’re organized by who their customers are: the host and the guest. They then organise themselves across the key milestones of those user journeys. It’s a great model because it actually makes shipping the org chart a good thing, and not something you need to mitigate for later. It also means you avoid being distracted by features nobody wants and instead focus on the customer throughout.

Later on, I was directed to Peter Merholz who was finishing a book on this very subject, and fortunately for me he was free for coffee. We talked about distributed organizations and my observations on how important it was where designers sat.

At one point in the discussion, he said, “designers like to play together too.” It was so simple, because of course designers need to collaborate as much with designers as with non-designers; otherwise how do you ensure a consistent and delightful experience? It had always seemed like a binary choice—either sit together or sit apart—but in that one statement it was clear that both were important. There’s so much more I could add here, but instead I’ll just say the guy knows his shit and you would be wise to check out his book, Org Design for Design Orgs.

Change by design

Another topic I underlined a lot was how design leaders initiated change, such as how they promoted design practices and got certain objectives prioritized.

In most cases, their success stories began when something external sparked an interest in design and they seized the opportunity. Like say, there was industry pressure to double down on design or pressure to fix product quality or some new C-level person arrived who thought design was crucial to the company’s future success. Then that design leader would make sure to have a team ready to take advantage of this opportunity.

There were examples of grassroots efforts, but they were rare and often limited in effectiveness. What seemed to have the most impact was getting aircover from the top. At Google, I heard how Larry Page would stand on stage and provide that cover, repeating the importance of beauty and simplicity. Or how companies like Intuit and IBM invested in week-long design onboarding to ensure everyone valued design thinking.

One sign that indicated design had broken through was when I’d hear the term EPD. This referred to Engineering, Product and Design. In the product orgs, this trio would be regarded as the core leadership unit with a cascading level of accountability. So if a team’s trio had a disagreement, they would push that decision to the EPD trio above and so forth. It highlighted the shared accountability of the functions and the importance of each role played in creating a successful product and staying aligned on decision making. This model is similar to the one we have at Spotify, though ours is called TPD: Tech, Product, and Design.

Reviews, reviews, reviews

Aarron: The core of your questions for the companies you visited centered around people and process, and you talked about speed and quality, and how a balance might be struck. Were there companies that found a balance between quality and speed in their process?

Stanley: What I scribbled down more often than anything else, more than the importance of where designers sat or how they were organized, was all the different ways these companies invested in reviewing.

Product reviews, strategy reviews, creative reviews, security reviews, accessibility reviews, UX reviews, reviews, reviews, and more reviews. It soon became clear that reviews are an essential part of ensuring teams stay aligned and calibrated on what matters most. Even though it adds an initial tax on speed, the fact that it was born out of necessity to fix quality and inefficiencies, means it was a cost many were happy to pay.

From Kim Lenox at LinkedIn I have underlined, “A framework to work together, a common language, a common rhythm.” From my conversations there, it was clear they valued collaboration and alignment, investing time to meet every two-weeks for company townhalls to creating a set of guidelines to distill their values. I was deeply impressed with their commitment to being ONE team and their follow through in ensuring they delivered on it.

At Salesforce, I learned how they kept everyone aligned on what’s important. Every list they write is prioritized. This forces them to be disciplined. For example, Craig Villamor told me they prioritized their design principles in order of importance. Meaning the key principle for a designer to deliver on is always the first. This seemed to me like a healthy and design-friendly habit for an organization, recognizing the importance of prioritizing what’s important and learning to say no to the rest.

In terms of how much they had turned things around, Google might have impressed me the most. From as far away as Sweden, it was clear that a more opinionated voice had started to emerge from Google, one where design quality seemed to matter. When I spoke with Richard Fulcher from the Material design team I was keen to understand how their processes had achieved this.

It turns out the Material team evolved their methods over 4 years. Carefully considering a democratic and autocratic style of reviewing work from a central team. Like how to reward teams for adopting common practices with self-reviews, and when to lean in on projects when additional support might be needed.

I learned a lot of practical lessons for Spotify’s central design team here. One in particular is how they scale their central team relative to the other parts of the organization. I learned the Material Design team are roughly 30 people, which given the number of products in their portfolio, as well as all the partners that extend it, is an impressive feat. To me, their secret sauce is focusing on scaling their processes and not the number of people working on it. Meaning they have a clear point of view on how teams should adopt and submit changes to the design system, which limits the need to have people lobby or police teams—a common challenge in many organizations.

Netflix was another example I was impressed with. They used used qualitative and quantitative testing to keep teams aligned and fast. By leveraging the value of qualitative methods (prototyping) they could quickly reduce the number of hypotheses before moving their best solutions to quantitative testing (building it for real). I discovered they have 2 types of quantitative tests, mountain testing and A/B testing.

Related: How Netflix does A/B testing

The latter is the classic incremental model, where you’d change specific parts of the UI to see how it might impact the hypothesis. And mountain testing is where they make more drastic changes to the interface. A lot of what I heard resonated with me, as they mirrored practices employed at Spotify and it was reaffirming to hear them repeat.

At Microsoft, I discovered how they align on the differences between improving and innovating. I heard how they invested in incubating new products to speed up their ability to innovate on their product line. A great way to break away and compliment the iterative cycle of the existing products. Polishing the best live experience while pioneering towards new opportunities.

The takeaway: silos are bad and collaboration is good. That it gets harder and harder to collaborate as you get bigger, but if you invest in aligning people on what’s important you can benefit from your size. And that silos are the enemy of good design, so this problem is critical to fix if you want to land your holistic vision.

Tools of the trade

Aarron: You also mentioned you asked about tools, were there any big learnings there?

Stanley: The power of the office as a tool for alignment was a big surprise.

When I walked around the offices at Airbnb in San Francisco, I saw that each meeting room was based on an apartment that existed on their site. It immediately helped me empathize with the customer and recall what their mission was. They also had storyboards that highlighted the milestones in their customer journey, which seemed like an effective way to clarify what was important.

Nike had a similar approach to building empathy in their office. But this time it was sports fields and swimming pools distributed across their campus in Portland. I also noticed how great everyone was dressed, and could imagine that wearing the same trainers, jackets, and tracksuits as the athletes could help build empathy too.

Related: Building user empathy with product teams

There were other examples of how an office could build alignment. Like Salesforce, where they communicated the core parts of their culture and values in a book. Or Foursquare, where as soon as you walk out of the elevator they have their core principles listed to remind everybody of what really matters. At Intuit, I loved how as you walk past the reception you can read case studies of their innovation projects, with photos of the people behind the project. It really demonstrates the values they care about.

I would never have thought of using the office to align people in this way. Super smart.

Coming home—putting lessons into practice

Aarron: You went on this quest to learn from many different design leaders you’ve come back home with notebooks full of observations, and you’ve discovered common strategies that can help you and your team. What’s the next step? How do you put these insights into practice at Spotify?

Stanley: So the day I returned to Sweden, I sat down in my apartment and covered the kitchen with Post-it notes. And then 2 days later I ran a mini-roadshow across Spotify’s leadership for design, product, and engineering. I told them all why I had gone on this trip, who I’d spoken with, and what I’d learned. The keynote I presented mirrored the themes of people, process, and tools. It presented the facts only. It was really important to me that this was an objective snapshot of how other companies are running design, not muddled with my opinions. I was happy to rely on the facts and didn’t feel a need to sell my point of view. Surprisingly, this led to a more receptive audience and a request for me to share my opinion on how we should move forward.

The week after that—and as a response to that request—I began drafting our design agenda. This was inspired by my conversation with Albert Shum at Microsoft, who explained how he’d drafted an agenda when aligning his team towards a series of aspirational goals.

In our agenda, we have 3 core themes with a series of actions we’re currently working through. For example, one is ensuring we have a hive mind (“one experience means one team”). And to achieve this we believe investment in collaboration is key. So beyond crits and reviews, we’ve now set up a dedicated design studio where designers can come together to collaborate in a physical space. There is no tool that can replace the value of face-to-face collaboration.

It’s probably too soon to predict how we’ll continue to integrate all these insights and whether each of them will transfer to our organization. But for now, I know I gained a 10-year jump in experience that I plan to maximize for my team.

And I like to think everyone I met extended their circle of colleagues too, so that the next time books fail any of us, we’ll have each other to turn to instead.

Read more interviews with design leaders

• Shopify’s Helen Tran on the importance of designing with compassion
• Thoughtbot’s Kyle Fiedler: Know yourself and trust your process
• Re-thinking design with Austin Knight of HubSpot