Great design isn’t enough. Outcomes over output. Many teams, one culture. These are some of the big lessons Greg Petroff learned during the past year in his role as Chief Design Officer at Cisco Secure. From creating a unified design system to changing the way product design teams think about features and building a design-led culture, he shares defining moments in this reflection on the power of design as a differentiator.
When you’ve been in enterprise software design as long as I have and worked at a lot of the big names, you learn a lot—but mostly you learn about yourself. You learn what you need from a job. What your “non-negotiables” are.
A little over a year ago, when I started searching for my next role, there were two things that I had as “non-negotiable”: (1) to work at an organization with a growth mindset—somewhere that was willing to challenge convention; and (2) have an executive leadership team that understood the power of design as a differentiator.
From the first conversation with Cisco, it was clear that they checked both boxes. Now, one year in the role as Chief Design Officer for the Security Business Group, I’m taking the time to reflect on some of the defining moments and the lessons I’ve learned along the way.
Great design isn’t enough
Let’s start with Design Systems. There are four things that must be true for a design system to be successful: great design, great documentation, the right engineering resources, and the right governance model.
When I first started at Cisco one year ago, the Security team was already well underway with implementing a unified design system, called Magnetic, across the portfolio. Originating from the Meraki team in the Enterprise Networking Business Unit, Magnetic has a simple, intuitive, and beautiful design, making it the ideal choice for bringing cohesion to the thousands of interfaces and screens across our products.
Right off the bat, I knew we had the first box checked: great design. With the backing of our senior leadership, we created a joint Design System team across Networking and Security—which helped pave the way to check the rest of the boxes. Today, the Magnetic design team has completed adoption-ready UI Shell components that are the first step to ensuring a single, cohesive user experience.
Outcomes over output: Changing the way we think about features
Here’s one thing that I’ve learned about most large organizations: we love features. “Customer X needs Feature Y,” we say. We add the feature to our roadmap, believing this will be the deciding factor on whether that customer buys from us.
Here’s the problem: when all your customers request their own list of bespoke features, you suddenly have an exponentially long list that you can’t possibly deliver on. It’s not sustainable.
So how do you overcome “feature-itis”? As Joshua Seiden lays out in his book Outcomes Over Output (one of my go-to references), you do as the title suggests, you focus on outcomes.
The best example of this over the last year was our development of Cisco Secure Access, our Security Service Edge (SSE) offering that we launched in June. When the team initially sat down for an Engineering Commit last year, there were 489 features requested. The team was trying to figure out how to prioritize the list, but with that many features up for debate, it was unmanageable.
So instead, we wiped the slate clean. The team instead laid out the 20 workflows that would drive the most impact for customers with the least features. By taking this approach, we were able to narrow down the priority list of features to 189, creating a plan that was not only doable but powerful. Within a short six months, we had a product.
Now, I keep multiple copies of Outcomes Over Output in my backpack, ready to reference or hand to new team members. I’m Joshua Seiden’s #1 fan.
Many teams, one culture
The last big lesson learned from this year: culture can make or break strategy. When I came into the role of Chief Design Officer, we started by unifying the disparate design teams across the Security team into one organization.
However, changing the org structure means little if you don’t also change the mindset. So how do you get a group of smart, dedicated people with different work styles to see Security Design as their first team? You work with the team to co-create a unifying set of language and rituals.
For our team, that started by creating the Mountaineering program, which was a program bringing together my team. Using a climbing metaphor, we asked ourselves, “If we’re at Base Camp today, what do we need to get to Camp 2?” With common goals in mind, the arbitrary walls that had been created by being from different product teams broke down. We came up with “Peak,” our outcome-based road mapping exercise, and “Ember,” our research philosophy. We even created a new design sprint process called “Goat” (aka, mountain goats, but also “Greatest of All Time”). By having this common set of language and rituals that we then cascaded to the rest of the org, we created a sense of community and culture that has led to better cross-functional outcomes.
At the end of the day, it doesn’t matter how great your strategy is if you don’t have a great culture. Many times, culture is driven from the top-down, and with the Mountaineering program, leaders across our organization took ownership of defining the culture together.
In conclusion…there is no conclusion
I say this because I truly believe my team is just getting started. There is so much goodness that has happened over the last year that will only continue. I can’t wait to see what the next year in this role brings.
