Pivot to Product: 5 Lessons from a Design Systems Manager at Spotify

Moving from a design systems focused team to the frontline of customer facing roadmaps can sometimes feel like you're starting all over again in your career. As noted in "The Art of the Professional Pivot" article, just like Erica I exercised the "boomerang pivot" moving from leading a design systems team to something entirely different but still within the same company.

I'll walk you through how I learned to apply design system leadership traits to a product focused team and how I came out the other side not just unscathed but thriving.

Start with what you know

When I landed in the world of enterprise podcasts after many years of building, promoting and managing design systems, I found myself surrounded by looming deadlines, and a growing desire to hit a giant red button labelled "SHIP IT!". But, I knew from my experience managing design systems that measuring priority for the business with speed to deliver is always a balancing act (regardless of the remit of your team), so instead, embarked on a listening tour to better understand the current state of these features I was now overseeing.

I met with my engineering, design, and data peers and found some surprising insights into where we had to move fast, which systems were mission critical and deeper background into systems and processes for this new world.

The world of product had some familiar traits to design systems but the speed to deliver was much, much faster and with higher expectations on results.

I never would've known this had I not taken the time to have a fika with these individuals first. This led me to a faster ramp up time, better insights into why certain decisions had been made in the past but most importantly where I could give good advice and start to have real impact.

If you find yourself in a similar situation, the first thing I suggest is to meet with your peers (think: other engineering, design, data, and product leaders). Here are a few questions you can ask:

• How are people sharing code and design?
• What's the most common way to measure success for a product team?
• Are there some runbooks for collaboration between teams?
• What's the most likely thing to slow down delivery?
• Are there any collective review sessions, design critiques, or product workshops that happen on a cadence and you can drop in to?

Building and leading design system teams grows strong muscle in understanding true pain points for customers (your peers) and the ability to frame more than one potential route to a solution. Managing competing interests from teams across your organisation and focusing on the highest impact with the least effort becomes second nature to those working on design systems. Take these learnings and scope them down to the smaller, product focused world you now live in.

The biggest shift I found in my personal journey was needing to supercharge the speed of my process and extend that as a leader to the teams I managed.

Understand the "why"

The next lesson was about digging deeper into the motivations behind the work. This part took much longer than I initially anticipated. I wanted to understand why my product team hustled so hard to deliver, who we were building for, and ultimately how important it was to the business. Thanks to the steps I followed above all of this started to become much clearer, which led to myself being more invested and clear-minded on the mission of the team.

Understanding the makeup of skill sets within my new team and the customer requirements for the business helped me focus on when to push, when to step back, and how that process differed greatly from my previous role in a design systems team where we typically had more time to explore options, implement stronger testing procedures and rollout plans.

It's not about drinking the Kool Aid and becoming fanatical about the direction of your new team and product

It's about understanding the complex machine of delivery in this new world and ultimately where your team fits in best. This is a key skill to unlock that will ultimately help you tweak your team's sense of urgency to deliver supercharged with a deep understanding of the "why". One way to see if you've stuck the landing here is to ask a peer in your product team to ask you what you all work on and why.

Find your cadence

In a design systems team you may find that the bulk of your releases tend to be extremely thorough, release notes carefully crafted, and all customer teams given months of warning before a release. This is to be expected and not at all a bad thing! However when shifting gears and moving to a new team you might find yourself releasing software on a minute to hour basis (continuous delivery) or at least on a 24 hour controlled cadence (manual releases).

Personally I found this shift in speed to be much, much faster than I was used to but something I embraced quickly and learned to thoroughly enjoy. It can be infectious when your team has the ability to ship something of high significance to the business and straight into the hands of a customer. Understanding why your team(s) product features affect the critical path will lead to you feeling more connected as a leader, and make you better at translating business goals into tangible targets for your teams.

Get your hands dirty

By no means do you need to become a subject matter expert overnight; in fact, your peers and individual contributors own this role and you will depend on them for their deeper insights in knowledge. However you do need to get your hands dirty and wade into an area or discipline you're likely unfamiliar with to better understand the broader ecosystem of your new team.

Find something that's outside of your typical comfort zone and get started on learning the basics.

I have a traditional web background and needed to dig into an area of the business written in a backend language with principles and architecture wholly unfamiliar to me. Thanks to some pairing sessions with engineers and my product manager, I slowly but surely started to understand how this area of the business worked. However I didn't go so far as to add comments on pull requests and suggest different detailed methods for a bugfix or feature addition – it's important to avoid the urge to go too deep and instead maintain your role as a leader.

In my case, I should have taken the plunge into the unknown sooner, as after speaking with my peers I learned that certain conversations and doors would have been open to me had I expedited this learning such as being more helpful in certain high stakes situations where we had outages or bug reports.

It's important in a new team to skill up to the point where you can identify opportunities and gaps that your previous life in a design system team may not have allowed you to see. For example, learning more about how our complex ad serving platform functions gave me enough insight to help guide workstreams and provide the right amount of space for engineers in my team to perform.

Share your wins

Someone once told me to communicate your wins until someone tells you to shut up.

In that vein, now is when you can start to consider scale and impact beyond your immediate teams. The world of design systems typically involves trying to convince your company to adopt the system on a wide scale – no easy feat. Take the skills you've learned around promotion of systems, convincing leadership of the smartest thing to do and do what you do best. Fly the flag for your product loudly and as far as you can.

Start to initiate sessions with individuals and teams around writing press releases (over) celebrating feature releases and bugfixes. Become that cheer person your product area didn't realise they sorely needed.

This is an opportunity for you to take that platform mentality of selling something that people aren't thinking about and apply it to your new home. Find opportunities for individuals to gain credit for spearheading a release, bugfix or anything in between. Add slides to all hand decks, post Slack or Teams updates with emojis and GIFs aplenty.

Working on design systems you are likely focused on your colleagues as the customer. Moving into product based teams can sometimes be a jarring experience when you find people outside of your company using your product and critically analysing any shortcomings or bugs.

Remember that you have strong muscle around reusability, building hype, gaining buy in and celebrating colossal wins and failures. These are all necessary qualities and traits of a strong product focused leader.