I spent nine years at Spotify leading design systems and accessibility. During that time, I learned as much from what failed as from what succeeded. I'm sharing these insights not to critique decisions made at the time, but because I believe they're valuable and can help others navigate similar challenges. This article is part of a series exploring those lessons.
It's a cold Monday morning in Stockholm at the start of December, a few years ago. I wake up, check my phone, and see a text from a fellow EM: "Oh my god, check your email." I know exactly what it means without looking. I've been here before.
I opened my email, and there it is. Layoffs are happening today. "Your role is not affected, but people on your team are."
My heart sinks. I feel sick. Today is going to suck.
I joined a meeting with my manager and their lead to discuss the layoffs and what would happen throughout the day. I've been through this before, I know what to expect. Oh, and you're getting a new manager. Oh, and just one more thing. The team you lead, the team you've built from the ground up over the last few years. It's being broken up and moved to another department. They're taking one engineer, the codebase, and the squad name, leaving you with two engineers, no code, no product, and no idea what you're going to work on.
The rest of that day is a blur. There are conversations with the engineers, discussions with other managers, and conversations with my own management about what happens next. I don't have answers to most of the questions. I don't know what my role is anymore. I don't know what these two engineers are supposed to work on. I don't know how long this will last. I'm exhausted and emotionally drained.
What I do know is that this decision is wrong. Everyone with any real context of this problem space, both in my department and in the department taking ownership, knows it doesn't make sense. But in that moment, I also know something else: I'm going to have to lead through this.
What we're actually talking about
This article is about what happens next. About how you lead when you're powerless. How you navigate a structural decision that you fundamentally disagree with, that you can't prevent, and that you now have to make work anyway?
These kinds of decisions happen in organisations all the time. Sometimes they barely touch your day-to-day work. Sometimes they require a shift in approach. And sometimes, like this one, they're seismic. They change your team, your work, and impact people personally.
When you're in that third category, your response matters. Not just for the immediate fallout, but for what comes after. For your team, for the people now scattered across the organisation, and for your own credibility as a leader.
In this case, the structural decision affected a design system team. I'd spent years building and leading this team, creating a unified design system that hundreds of designers and developers across the organisation depended on. The decision was to break up that team and move the system to a different department. One engineer, the codebase, and the squad name would go to a feature-focused department. There would be no dedicated designer on the new team. A design system without a designer. That's what we were dealing with.
This is the story of how I navigated this and what I learned.
Trying to understand
My first instinct was to stop it. The decision was so obviously wrong, it had to be a mistake. Maybe there was something missing from the thinking. Some context that, if explained properly, would make leadership see that this was wrong.
So I started asking questions. Why are we doing this? What problem are we trying to solve? Was there something we'd missed? The reasons came back, each sounding plausible on the surface.
"You are too slow." A common reason I heard was that the team wasn't moving fast enough. By placing the team in a different organisational structure, we'd speed things up.
But the data showed the opposite. We were delivering faster than ever. We had the metrics to prove it.
"You're too focused on other team problems." I was told this move was happening because we were spending too much time on other teams' priorities, so the new department was taking ownership.
We knew exactly who our customers were. 90% of them worked on a single product. We built our entire roadmap around that 90%. As seasoned practitioners, we knew that with minimal consideration, we could support the remaining 10%. A quick check would confirm our components were suited to their use cases, too.
"This aligns with our current org structure." This one was about efficiency. The thinking was that if the primary consumer took ownership of the design system, things would be more aligned, and we could move faster.
What this ignores: design systems are platform problems, not feature problems. By placing platform work within a feature organisation, you're fundamentally misaligning incentives and ways of working. Feature teams optimise for speed and shipping. Platform teams optimise for consistency, scalability, and long-term health. Those aren't compatible, and you can't just will them into compatibility by reorganising.
I could go on. There were more reasons, and they all followed the same pattern.
These weren't the real reasons. They were the reasons people were comfortable stating publicly. The real reason was simpler and more frustrating. I wouldn't uncover it until much later, after I'd pieced things together over weeks and months.
After the disbelief faded
When it became evident I couldn't reverse this decision, and after the disbelief, frustration, and anger subsided, I had to make this work.
I had to think clearly about what mattered most. What were my priorities?
- The People. Always my first priority. We'd just uprooted a bunch of people. They needed stability, clarity, and support.
- The Product. The design system itself. I'd spent years building and shaping this system; I knew it was working; I didn't want to see my efforts go to waste. Continuity mattered. Customers couldn't afford for the system to falter - and the primary customer was the very department now taking ownership, whether they fully grasped that dependency or not.
- The Vision. The direction we'd been building towards was sound. The data showed this. My experience as a design system practitioner told me this was the right solution. The vision needed to be preserved, even if the team was scattered.
These priorities shaped how I approached what came next.
How I navigated it
1. Disagree and commit (but don't abandon your belief)
Once I'd accepted that the decision wasn't changing, I made a choice. I was going to disagree and commit. But I want to be really clear about what that means, because there's often a misunderstanding here.
Disagree and commit doesn't mean you abandon your position and suddenly stop believing the decision is wrong. It doesn't mean you pretend everything is okay or that you've changed your mind. It means you accept that the decision has been made, you're going to make it work, and you're going to stop trying to reverse it or prove the decision-makers wrong.
For me, that meant stopping the conversations about undoing this. No more case-building. No more "if you just understood the data" arguments. That era was over. Now I needed to focus my energy on something I actually had control over: how I responded and how I helped the people affected by this decision.
This distinction freed me from having to convince anyone I'd changed my mind. I didn't have to validate the decision publicly. I didn't have to pretend I thought it was brilliant. I just had to stop actively resisting it and start actively making it work.
2. Be a positive partner
The alternative is becoming the person who's bitter about the decision. The person who resists, who's challenging to work with, who makes it clear they think the whole thing is a mistake. And yes, in this case, it was clearly a mistake. But that approach gets you nowhere. It gets you labelled as someone who doesn't play well with others. Someone who's a blocker rather than a partner. Any resistance risks giving them a scapegoat: "We tried to make this work, but they wouldn't get on board."
I took a different approach. I was going to be the most helpful, most positive partner in this transition, someone they could rely on and learn from. Not because I'd suddenly decided the move was good, but because being difficult would only damage the people, the system, and the vision I was trying to protect.
This is what I think of as "kill them with kindness." You show up, you offer support, you make yourself available, you share what you know. You demonstrate commitment to making this work. And in doing that, you protect yourself and your team from being seen as blockers or problems.
3. Ensure continuity
Newly formed teams take time to get up to speed. The question was how to maintain continuity while that happened.
The new team was taking over ownership of an existing, adopted design system, and its customers needed continuity. At the same time, the two engineers who stayed with me needed focus and purpose as we figured out what came next.
I proposed an embed. The two engineers would temporarily rejoin in the team they'd just been separated from to support the transition and shorten the new team's ramp-up time. They'd share knowledge, provide continuity for customers, and help the new team get up to speed on how the system worked and what we'd been building towards.
This addressed all three priorities at once:
- People: The two engineers had stability and a clear focus, even if just temporarily. They weren't floating in limbo. They were part of something concrete, helping their former team get established.
- Product: The design system had continuity. Customers didn't lose access to expertise or institutional knowledge overnight. The transition was managed.
- Vision: By embedding experienced people who understood what we'd been building, we had a chance to influence how the system evolved in its new home. To advocate for the standards and direction we'd established.
We ran the embed for six months. During that time, we transferred knowledge. The design system continued to serve customers. Continuity was maintained. When the embed ended, the two engineers came back to work with me on what came next.
4. Build trust with the new manager
The team got a new leader I didn't know. Someone with little context and experience in the design system problem space. Someone who was inheriting a team, a codebase, and a set of responsibilities that were entirely new for them. It was also something they didn’t ask for.
Building trust with them quickly became crucial for the embed phase and the system's long-term success. If we didn't have a good relationship, if they didn't trust my judgment or value my input, then everything became harder.
I deliberately worked to build that relationship. I made myself available, answered questions, and shared context without making them feel stupid for not knowing things. I acknowledged they were stepping into something complex and respected the challenge they were taking on. But I also listened. I asked them about their vision for the team, what they wanted to build, their priorities, and where they thought things needed to go. I didn't assume they'd make the same decisions I would have.
What I learned
Look for the wins
Despite the move being fundamentally wrong, some things worked out. They show that even in bad situations, good things can happen.
The new engineering manager who'd taken over the team was impressive. They came in with little context or experience in design systems, but they threw themselves into learning. They asked good questions. They cared deeply about understanding the problem space and the team. They were genuinely committed to making this work. As they became more familiar with the problem space, they became true advocates for design system thinking and the vision we'd been building towards. Over time, a genuine working relationship formed, built on mutual respect.
The senior engineer who moved with the system to the new department really stepped up. They started operating more like a staff engineer, becoming the de facto technical lead, not because they were promoted, but because they understood the system and the vision we'd built. They actively worked to maintain that vision and the standards we'd established. When the team lacked design expertise, this engineer stepped in to solve design problems. It was impressive to watch.
As that senior engineer stepped up, it created space for another engineer to grow into. They began working as a senior engineer, taking on more responsibilities, leading projects, and participating in architectural discussions. This allowed them to build the evidence they needed to be officially promoted to senior engineer.
None of these wins was the point of the move, nor did they address the problems it was supposed to solve. They mattered anyway. They showed me that no decision is entirely bad. People can still do good work and grow, even in a fundamentally misaligned setup.
The leadership transition
One thing I didn't anticipate about the embed was how much it would change my role and how challenging that would be.
I was no longer leading the team. I became the advisor in the background, watching from the sidelines while someone else took it forward. I had the knowledge and context to shape the future, but I was no longer in the driver's seat. I couldn't make the decisions anymore. I could only inform them, share my perspective, and demonstrate the experience I'd built up over the years.
This was my first real lesson in managing up.
Managing up means understanding the constraints your leadership faces, anticipating their questions, and providing context that helps them make better decisions. It means being clear about risks without being a blocker, and building credibility through consistent input rather than formal authority. In this case, it meant understanding what the new manager was trying to achieve and helping them see patterns they hadn't encountered yet, rather than telling them what to do.
I'd spent years managing down and across, but this required a different skill entirely: shaping outcomes through influence alone.
It's harder than it sounds. You have to let go of control while staying invested. You have to accept that decisions might be made differently than you'd make them, and you can't always prevent that.
What happened to the team
In the months and years that followed, things got harder.
Leadership in the new department didn't know what to do with a platform team dropped into their feature organisation. Over the years, there were multiple reorganisations, new managers cycling through, and a lack of clear vision and direction. The team struggled. Some people found opportunities to move to other teams where they could have more impact.
It was painful to watch. Not just for me, but for everyone involved. Two years of wasted effort, energy, and opportunity. People's careers were affected. The system stagnated. Customers suffered.
If there's a silver lining, it's that the evidence is clear. The costs are visible. I hope someone in a senior leadership position eventually comes to their senses, admits this was the wrong decision, and does something to try to fix it.
The real reason for the move
I mentioned earlier that the public reasons weren't the real ones. Over months, if not longer, conversations with various people helped me piece together what I believe was the main factor. Nobody ever officially confirmed this.
The real reason was structural convenience. Another team from a sibling department was being reorganised. Someone looked at that move and thought, "We could move the design system team at the same time." No strategic evaluation. No consideration of whether it made sense for the work. Just organisational efficiency. The justifications I explored earlier felt like they were created after the fact to try and make the move seem rational.
What this revealed was a gap in the organisation's understanding of our work. The decision was made because that distinction wasn't visible to those making it. They didn't know what questions to ask or the impact their decisions would have.
The reality of leading through it
Dumb decisions happen in organisations. They shouldn't. They don't make logical sense when you examine them closely. But that's the reality of how organisations work. People make decisions without consulting their experts. Politics, career aspirations and convenience win over what's right. Context gets lost in the shuffle of larger priorities.
As leaders, we don't always get to choose the decisions that affect our teams. Sometimes they're made for us. Sometimes they're clearly wrong, and everyone with any expertise knows it.
But we do get to choose how we respond. We get to decide whether we're going to be bitter about it or try to make it work. We get to decide whether we're going to protect our people and fight for what matters, even when the odds are against us.
That's where the real work happens. Not in being right about the decision, though sometimes we are. The real work is in leading through the aftermath. In maintaining your credibility while disagreeing. In staying positive when things are frustrating. In building relationships with people who didn't ask to inherit your work. In leading through influence, when you no longer have authority.
It's harder than just making good decisions in the first place. But it's also where you discover what kind of leader you actually are.