Building a design team to revolutionize how Cisco sells
Company
Cisco



Introduction
Cisco is a longstanding Fortune 100 tech company. In the early 2020s they faced a change in the market: People were buying less hardware and more software, mainly SaaS subscriptions. For example, instead of buying a physical firewall box, customers wanted cloud-based firewall solutions.
The company set a goal to have 50% of revenue come from cloud software subscriptions by 2024. To do this, Cisco needed to change the culture, and the tools, of sales, which were both oriented towards selling physical, not virtual, goods. Sales' primary tool was Salesforce — in fact, there were dozens of Salesforce instances running across the company in regions and subsidiaries.
The Workforce Experience Design team (later IT Design) hired me to extend and grow a team of designers and researchers working on this modernization.
Goals
Help Cisco reach the 50% cloud sales goal
Align the way sales is done with Salesforce, with the goal of unifying all the instances to a single one for all of Cisco
Use design and user research to improve collaboration between Product, Engineering, and Design teams
Cisco is a longstanding Fortune 100 tech company. In the early 2020s they faced a change in the market: People were buying less hardware and more software, mainly SaaS subscriptions. For example, instead of buying a physical firewall box, customers wanted cloud-based firewall solutions.
The company set a goal to have 50% of revenue come from cloud software subscriptions by 2024. To do this, Cisco needed to change the culture, and the tools, of sales, which were both oriented towards selling physical, not virtual, goods. Sales' primary tool was Salesforce — in fact, there were dozens of Salesforce instances running across the company in regions and subsidiaries.
The Workforce Experience Design team (later IT Design) hired me to extend and grow a team of designers and researchers working on this modernization.
Goals
Help Cisco reach the 50% cloud sales goal
Align the way sales is done with Salesforce, with the goal of unifying all the instances to a single one for all of Cisco
Use design and user research to improve collaboration between Product, Engineering, and Design teams
Cisco is a longstanding Fortune 100 tech company. In the early 2020s they faced a change in the market: People were buying less hardware and more software, mainly SaaS subscriptions. For example, instead of buying a physical firewall box, customers wanted cloud-based firewall solutions.
The company set a goal to have 50% of revenue come from cloud software subscriptions by 2024. To do this, Cisco needed to change the culture, and the tools, of sales, which were both oriented towards selling physical, not virtual, goods. Sales' primary tool was Salesforce — in fact, there were dozens of Salesforce instances running across the company in regions and subsidiaries.
The Workforce Experience Design team (later IT Design) hired me to extend and grow a team of designers and researchers working on this modernization.
Goals
Help Cisco reach the 50% cloud sales goal
Align the way sales is done with Salesforce, with the goal of unifying all the instances to a single one for all of Cisco
Use design and user research to improve collaboration between Product, Engineering, and Design teams
Comprehension
Comprehension
Making A Team Into A Team
When I arrived I discovered that due to some re-orgs the team of ten I inherited consisted heavily of early and mid-career designers, many of which came from startup backgrounds and/or organizations with a small number of stakeholders. At the time they struggled with presenting design, defending it, and managing the plethora of people who had a stake in the design outcome.
The perception of the design team by the product leadership was that they lacked the domain knowledge and maturity needed to navigate the very, very complex and political space of the sales organization.
So, my first phase of work with the team was to grow the team's skills. Some of the things I did:
Established a culture of critique — with regular weekly opportunities to present designs to one another in a friendly environment away from the stakeholders
Promoted "pair design" — tried to assign two designers to each project instead of the usual one so they could work together and sharpen each other. I also encouraged this across projects so there was not just the opportunity to learn from one another but also understand the different parts of the sales process
Coached on presenting to stakeholders — not just on how to be tight and crisp in their readouts, but also how to ask "why" and push on assumptions that came with an organization more concerned with outputs (i.e. shipping to satisfy arbitrary time-based goals) than outcomes (i.e. shipping to satisfy customer and business goals)
In the meantime, I did what any good leader should do: Have a lot of conversations. Biweekly 1:1s with reports, scheduled check-ins with program leadership and peers in the product organization, and monthly readouts to the design organization and core stakeholders.
I used our user research team as one level to build trust and rapport with the product organization. We shrank research down to user interviews and quantitative analysis, focusing on generating as many "aha" moments as possible.
Understanding the Sales teams
As part of that research, I pushed our research organization on bringing to life an idea I'd done myself in previous jobs — a map of user goals and jobs-to-be-done where we could illustrate not just the personas and tools but also the pain points and research-based evidence in each step.
One thing I discovered in a workshop was that there was so much siloing that the product managers didn't understand quite how their area fit into the larger picture. With a lot of encouragement from me and a few false starts, the design and research teams delivered a "persona map" built in Figma.
The impact was immediate — the product leadership, along with VPs in the IT org, fell over themselves to get access to what we had. One VP of product stated, point blank, "I'm utterly amazed at the level of clarity and depth you delivered — and why have we never had this before now??"



Salesforce One
As we built that rapport with product and engineering, the conversations and asks shifted from tactical ("make me a Figma") to more strategic ("help me understand the problems and give us direction.")
The Salesforce One project was a good example. Cisco was an early adopter of Salesforce, but so were its many subsidiaries it bought over the years. Unifying all the instances was a daunting task.
To make something this complex happen, I needed the right people involved — so I went about searching for and hiring the right architect who understood the extreme complexity and political sensitivity that came with a project like this. I supported them, and their team, throughout, focusing on giving them the agency and autonomy they needed to deliver their best possible work, all while maintaining accountability to time and performance metrics.
After three months, Cisco migrated its first subsidiary into the "Salesforce One" experience. Their work was trumpeted by senior leadership, with one senior VP saying the design team's blueprint for migration "represents a significant leap, steering the business towards a cohesive, efficient, and strategic approach to incorporating future acquisitions into its sales ecosystem."




Making A Team Into A Team
When I arrived I discovered that due to some re-orgs the team of ten I inherited consisted heavily of early and mid-career designers, many of which came from startup backgrounds and/or organizations with a small number of stakeholders. At the time they struggled with presenting design, defending it, and managing the plethora of people who had a stake in the design outcome.
The perception of the design team by the product leadership was that they lacked the domain knowledge and maturity needed to navigate the very, very complex and political space of the sales organization.
So, my first phase of work with the team was to grow the team's skills. Some of the things I did:
Established a culture of critique — with regular weekly opportunities to present designs to one another in a friendly environment away from the stakeholders
Promoted "pair design" — tried to assign two designers to each project instead of the usual one so they could work together and sharpen each other. I also encouraged this across projects so there was not just the opportunity to learn from one another but also understand the different parts of the sales process
Coached on presenting to stakeholders — not just on how to be tight and crisp in their readouts, but also how to ask "why" and push on assumptions that came with an organization more concerned with outputs (i.e. shipping to satisfy arbitrary time-based goals) than outcomes (i.e. shipping to satisfy customer and business goals)
In the meantime, I did what any good leader should do: Have a lot of conversations. Biweekly 1:1s with reports, scheduled check-ins with program leadership and peers in the product organization, and monthly readouts to the design organization and core stakeholders.
I used our user research team as one level to build trust and rapport with the product organization. We shrank research down to user interviews and quantitative analysis, focusing on generating as many "aha" moments as possible.
Understanding the Sales teams
As part of that research, I pushed our research organization on bringing to life an idea I'd done myself in previous jobs — a map of user goals and jobs-to-be-done where we could illustrate not just the personas and tools but also the pain points and research-based evidence in each step.
One thing I discovered in a workshop was that there was so much siloing that the product managers didn't understand quite how their area fit into the larger picture. With a lot of encouragement from me and a few false starts, the design and research teams delivered a "persona map" built in Figma.
The impact was immediate — the product leadership, along with VPs in the IT org, fell over themselves to get access to what we had. One VP of product stated, point blank, "I'm utterly amazed at the level of clarity and depth you delivered — and why have we never had this before now??"



Salesforce One
As we built that rapport with product and engineering, the conversations and asks shifted from tactical ("make me a Figma") to more strategic ("help me understand the problems and give us direction.")
The Salesforce One project was a good example. Cisco was an early adopter of Salesforce, but so were its many subsidiaries it bought over the years. Unifying all the instances was a daunting task.
To make something this complex happen, I needed the right people involved — so I went about searching for and hiring the right architect who understood the extreme complexity and political sensitivity that came with a project like this. I supported them, and their team, throughout, focusing on giving them the agency and autonomy they needed to deliver their best possible work, all while maintaining accountability to time and performance metrics.
After three months, Cisco migrated its first subsidiary into the "Salesforce One" experience. Their work was trumpeted by senior leadership, with one senior VP saying the design team's blueprint for migration "represents a significant leap, steering the business towards a cohesive, efficient, and strategic approach to incorporating future acquisitions into its sales ecosystem."




Making A Team Into A Team
When I arrived I discovered that due to some re-orgs the team of ten I inherited consisted heavily of early and mid-career designers, many of which came from startup backgrounds and/or organizations with a small number of stakeholders. At the time they struggled with presenting design, defending it, and managing the plethora of people who had a stake in the design outcome.
The perception of the design team by the product leadership was that they lacked the domain knowledge and maturity needed to navigate the very, very complex and political space of the sales organization.
So, my first phase of work with the team was to grow the team's skills. Some of the things I did:
Established a culture of critique — with regular weekly opportunities to present designs to one another in a friendly environment away from the stakeholders
Promoted "pair design" — tried to assign two designers to each project instead of the usual one so they could work together and sharpen each other. I also encouraged this across projects so there was not just the opportunity to learn from one another but also understand the different parts of the sales process
Coached on presenting to stakeholders — not just on how to be tight and crisp in their readouts, but also how to ask "why" and push on assumptions that came with an organization more concerned with outputs (i.e. shipping to satisfy arbitrary time-based goals) than outcomes (i.e. shipping to satisfy customer and business goals)
In the meantime, I did what any good leader should do: Have a lot of conversations. Biweekly 1:1s with reports, scheduled check-ins with program leadership and peers in the product organization, and monthly readouts to the design organization and core stakeholders.
I used our user research team as one level to build trust and rapport with the product organization. We shrank research down to user interviews and quantitative analysis, focusing on generating as many "aha" moments as possible.
Understanding the Sales teams
As part of that research, I pushed our research organization on bringing to life an idea I'd done myself in previous jobs — a map of user goals and jobs-to-be-done where we could illustrate not just the personas and tools but also the pain points and research-based evidence in each step.
One thing I discovered in a workshop was that there was so much siloing that the product managers didn't understand quite how their area fit into the larger picture. With a lot of encouragement from me and a few false starts, the design and research teams delivered a "persona map" built in Figma.
The impact was immediate — the product leadership, along with VPs in the IT org, fell over themselves to get access to what we had. One VP of product stated, point blank, "I'm utterly amazed at the level of clarity and depth you delivered — and why have we never had this before now??"



Salesforce One
As we built that rapport with product and engineering, the conversations and asks shifted from tactical ("make me a Figma") to more strategic ("help me understand the problems and give us direction.")
The Salesforce One project was a good example. Cisco was an early adopter of Salesforce, but so were its many subsidiaries it bought over the years. Unifying all the instances was a daunting task.
To make something this complex happen, I needed the right people involved — so I went about searching for and hiring the right architect who understood the extreme complexity and political sensitivity that came with a project like this. I supported them, and their team, throughout, focusing on giving them the agency and autonomy they needed to deliver their best possible work, all while maintaining accountability to time and performance metrics.
After three months, Cisco migrated its first subsidiary into the "Salesforce One" experience. Their work was trumpeted by senior leadership, with one senior VP saying the design team's blueprint for migration "represents a significant leap, steering the business towards a cohesive, efficient, and strategic approach to incorporating future acquisitions into its sales ecosystem."




Results
Results
Metrics my tenure:
I managed 15 people with only one departure due to regrettable attrition
Stakeholder satisfaction, measured by UMUX, rose the first year by 15 points, with product leadership clamoring for our time
I promoted three designers as they grew and matured
Team job satisfaction metrics improved quarter-on-quarter around "doing meaningful work" and "feeling included"
Cisco accomplished their 50% subscriptions sales goal earlier than expected
I was, and remain, very proud of these designs and the design team I built. They took care of each other, built each over up, and grew in skills and competencies like weeds.
Metrics my tenure:
I managed 15 people with only one departure due to regrettable attrition
Stakeholder satisfaction, measured by UMUX, rose the first year by 15 points, with product leadership clamoring for our time
I promoted three designers as they grew and matured
Team job satisfaction metrics improved quarter-on-quarter around "doing meaningful work" and "feeling included"
Cisco accomplished their 50% subscriptions sales goal earlier than expected
I was, and remain, very proud of these designs and the design team I built. They took care of each other, built each over up, and grew in skills and competencies like weeds.
Metrics my tenure:
I managed 15 people with only one departure due to regrettable attrition
Stakeholder satisfaction, measured by UMUX, rose the first year by 15 points, with product leadership clamoring for our time
I promoted three designers as they grew and matured
Team job satisfaction metrics improved quarter-on-quarter around "doing meaningful work" and "feeling included"
Cisco accomplished their 50% subscriptions sales goal earlier than expected
I was, and remain, very proud of these designs and the design team I built. They took care of each other, built each over up, and grew in skills and competencies like weeds.