What the corporate world can learn from academia’s respect for expertise and autonomy
Learnings from three years of design system advocacy
The Knock Nevis, built in 1979, was the largest ship ever constructed. It could carry 565,000 tons and was 458m long. It was far too chunky for any port to accommodate it, so it needed to be anchored off-shore and unloaded by smaller vessels.
According to Newton, an object in motion stays in motion, and a fully loaded super tanker has an incredible amount of inertia. It can take as much as 8 kilometers to stop a vessel that size, and requires several kilometers to turn.
The process of changing course is slow. It’s deliberate. Any miscalculation can lead to serious consequences, particularly when operating in tight shipping lanes and canals (just check out the terrible things that happened to the Ever Given on the Suez Canal).
Organizations are big ships
If we’re trying to cast vision and influence how a large organization operates, it’s going to take time.
A lot of time.
Just as a tanker cannot make sudden movements without causing disruption, organizations are slow to adapt and change due to their size complexity and established structures. Shifting the course of a company requires careful planning, coordination, and patience.
I lead the Momentum Design System team at Cisco where I’ve spent the last three years trying to generate buy-in for a dedicated engineering team. It’s been an uphill battle. There have been lots of times where my arguments have fallen on deaf ears. But, I’ve been patient and continued to push, bringing a voice to my vision of what our design system could become.
I thought I’d share some of my frustrations as well as the things that I’m learning as I develop my ability to influence a large organization.
1: Every conversation is an opportunity
A person remembers about fifty percent of a conversation they just had. A week later, that same person might remember ten percent (maybe). If we’re trying to drive change within a large organization, every meeting matters. Each interaction is a chance to sell our vision for the future. Change can’t happen in isolation or through a single decision. It’s built, brick by brick, through repeated, consistent messaging that reinforces the value that we’re advocating for.
Our goal is to communicate our vision so clearly that everyone around us can understand and articulate it.
Consistency is key to vision building. The more often that people hear our message reinforced, the more likely they are to internalize it and begin to adopt to the new direction we’re working towards.
A Design System to Make Life Easier for Everyone
Since the beginning of my role at Cisco, I shared that we were building an internal product. It would be a suite of shared tools to make the lives of designers and engineers across the Collaboration Business Group easier. We were going to do that by creating design tokens, shared assets, and a UI toolkit, consumable by everyone across all products and platforms.
I regularly vocalized that message to my team, my design partners, and my engineering collaborators. In every meeting that I could, I shared my vision for the design system and value our team wanted to build.
I just needed to find some like-minded friends.
2: Understand what people need and how you can help
Talking about what we want to do and build isn’t enough. Trying to cast our vision for a better world isn’t enough. If we want people to buy into our vision, they need to know how it will impact them. How is what we’re doing going to benefit them? We need to understand the people we work with, their pain and concerns. Then we can speak specifically to that pain as we’re casting a vision for the future.
Building partnerships
When I first started working at Cisco, I began building partnership with engineers across the different platforms that we were supporting. At the time, the Webex app was built natively on operating systems and mobile devices (Windows, MacOS, Android, iOS, and Web). Platform teams were building UI toolkits for each of their platforms. We on the design team were supporting a different Figma library that contained native components where necessary.
I would meet regularly with engineers leading the construction of each toolkit to get to know them and understand the biggest problems that they were trying to solve. I asked what they expected from a design system. And I asked how I could help.
Being able to accurately articulate the needs of another person is an incredibly powerful way to make an ally.
Despite not having an engineering team, I was able to articulate the needs of my collaborators and build systems to help them. The first thing we did was create a token system everyone could align to instead of hard coding hex values. Addressing their needs led to really strong partnerships, particularly with the web engineers.
Collaborating on the token system led to conversations about the future of our design system. And when I started talking about creating a universal web UI toolkit for all the products in our business group, they got interested.
3: Large companies are large for a reason
And the implementation of our disruptive ideas could rock the boat…big time. Companies like Cisco are big for a reason, and while we might believe in our ideas, disrupting something that is working is a big risk. The downside of which could mean the loss of people’s livelihoods.
It’s easier to do nothing than something. So people, particularly leadership, are encouraged to maintain the status quo, even if they witness a good idea.
Any time we want to create change, we need to think about how disruptive we’re being, what we’re risking with that change, how we’re addressing that risk, and how much value our idea will bring to the table.
Pitching Engineering Leadership
For me, as a design system leader, the problem was that we had no dedicated engineering support. After building working UI toolkits for their platforms, the engineers I had built relationships with moved on to feature work. I would check in with them on occasion, but any time we needed to make a change to our design system it was incredibly difficult to implement. This created a slew of problems: inconsistencies across our software products, inability to address and fix issues, and a lack of scalable solutions across multiple product teams.
Let’s say a design on my team was fixing an accessibility issue for one of our button components. We’d document that change in our Figma library, then we would have to reach out to five different engineers across five different platforms and ask if they had capacity to update the component.
Typically, they didn’t. Feature work was always prioritized and the change may or may not end up on their backlog.
We were handicapped. That handicap hurt and delayed feature work. Because no engineers were responsible for design system updates, anytime an engineer had to make one, it was a painful interruption. And the solutions that were implemented in code weren’t scalable, they weren’t built in a reusable way for other teams to leverage.
Despite Cisco being a large, successful business, I knew that this design system support model was hurting us and our ability to create innovative products. I found a partner in the web team’s engineering manager. He was also passionate about building scalable engineering solutions, particularly around the design system. We worked together to pitch engineering leadership to invest in a dedicated team.
Over the course of a year and a half, we met with multiple engineering executives across our organization. We showed them the issues that were happening across multiple product teams, the money we could save by having a centralized team (over $10M a year), and the specific projects we’d implement first. But despite the head nods of agreement, no one wanted to take the risk. Things were “working.” Engineering leadership continued to push the failed model of federated ownership that Nathan Curtis talks about here so poignantly.
Eventually though, a couple years of pitching turned into something…
4: Don’t count your chickens
Priorities change at any business. That’s normal. As leaders, it’s our job to cast vision and create clarity of focus for our organizations. However, even the healthiest of orgs needs to pivot every once in a while. Unhealthy, visionless organizations love to light everything on fire all at once and tell their people to put them out with blankets soaked in gasoline.
My organization could have been healthier…
A Slight Pivot
With the support of my design leadership, we were finally able to get engineering leadership to invest. They gave me five web engineers to build shared tools and a UI toolkit. This was the dream team! We had already spent the last year collaborating on smaller projects and dreaming about how we’d work together if we ever got investment.
It finally did! We were elated!
In our first month and a half we built custom tooling that automated the syncing of design tokens from Figma to GitHub. We also built a custom plugin that allowed us to push icon library changes from Figma to GitHub, then publish NPM packages for consumption by our product teams.
We made magic! It was brilliant work. And it was incredibly fast!!!
Then a bomb dropped.
Engineering leadership pivoted their resources. Building shared tooling that helped everyone wasn’t valuable enough. They needed to create feature parity for the web version of Webex.
My team was pulled away, and our work was deprioritized. I was crushed.
5: Sometimes you get lucky
Plans changed. Unexpected, disappointing things will happen. This is the nature of work. It’s not just about sticking to the plan, we need to have the grit to navigate obstacles and keep moving forward. Leading through difficulty requires determination, creative problem-solving, and the ability to inspire others to persevere.
Also, sometimes we need to get lucky…
A Selfless Gift
Without an engineering team, we were stuck. We continued to create design clarity for our design system, respond to requests, and maintain our token and icon libraries. But we couldn’t make anything real without engineers.
There are 30+ products in the Collaboration Business Group at Cisco. You can count the ones using our design system on one hand. The rest are built with 5 year old branches of Momentum, or they’ve hobbled together their own system, or they don’t have a system at all.
I have regular monthly meetings with all the design leaders across those products. In those meetings I ask what kinds of issues they’re dealing with and how our design system team might help.
One of those leaders, Cheryl, made my dreams come true. She needed to get her products onboarded to Momentum, and knew what I wanted to build (because I had communicated my vision and how it’d help her organization so often). When some positions opened up in her organization, she gave them to me.
She just gave them to me…
It was an incredibly selfless move. Open requisitions were hard to come by at the time. We’ve had multiple hiring freezes over the last few years. I couldn’t believe it.
I walked through the hiring process with the help of many of my engineering friends. I also was able to recruit the help of one of the original web team engineers to lead the new engineers that we hired.
We just began building our UI toolkit two weeks ago. Three years of design system work are finally becoming real. Three years to turn this ship around.
We’ll see where we land.
Hey y’all! I’m Trip Carroll, a design leader at Cisco and aspiring cartoonist.
I write and publish a new article on design, leadership, and software development every other Monday. You can see more of my work on my website, check out my drawings on Instagram, or subscribe to my newsletter on Substack.
Let’s make work great!
You’re trying to turn an oil tanker was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
