DesignOps 2020: Two Sides of the DesignOps Coin-TeamsOps and ProductOps (Session Notes)
Speakers:
– John Calhoun, Director of UX Product Operations for Salesforce
– Rachel Posman, Director of UX Team Operations for Salesforce
— Good afternoon. Both speakers with the salesforce UX team, and they will share how they reshaped the Salesforce DesignOps team into TeamOps and ProductOps
-
Coins like DesignOp teams have more than one side
-
Examining all sides of the coins leads to new ways to grow
-
People put at center of work
-
Community and Culture-Ways to connect and celebrate the Salesforce UX organization, through events like team health programs, and empowering the team to give back to the local community
-
Learning and Growth—Experiences to help Salesforce UX employees grow, including hiring/onboarding, and continual learning
-
Systems and Tools—Ways to scale practices across entire org, and defining the foundational things to do work
-
Help Air Traffic Control UX work, and artifacts to meet expected deliverables
-
Shape cadences for discovery, and logistics of product development
-
For UX Partners: ProductOps’s goal is to help develop product team health
-
Learn team problems and needs for specific product
-
Product Ops shares this information with Team Ops
-
TeamOps optimizes the information for the entire organization
-
-
The Pink-Star moment- TeamOps learns how product ops practice works within teams, and codifiers best practices from the different teams
-
This removes the need for reinventing wheel for teams solving problems
-
-
UX playbooks to scale best practices
-
A UX Org Team Site—Home base for discovering things across UX org
-
UX Org Communication Examples—Timely recurring communications, about celebration and informing
-
Supporting UX Org at internal and external events
-
Provides work-tracking help track UX deliverables for development teams
-
Help designers look across product portfolio and find general patterns/use cases
-
Facilitating design workshops of all kinds from project kick-offs, to guerrilla research
-
Way work was taken on, prioritized, and distributed, didn’t make rational sense
-
Everything felt like Ops, with no consistent day-to-day practice
-
DPMs were being asked to do too much
-
DPMs were unsure how they could grow in their careers
-
They felt workshops could have been done more efficiently
-
They wanted to purchase software, but didn’t know who to go to
-
They didn’t have visibility to what designers were working on
-
There was an unclear scope of responsibility
-
The Design partners were unsure which tools to use
-
DPMs seemed too busy to work with partners. Hard to prioritize what needed to be done
— Why was the team hearing this? DesignOps had reached an inflection point
Design Group:
-
Design Team (1-30 people): Strong family feeling, and decisions easy, and generalists wearing many hats
-
Design Ops (0.5-1 people): General guidelines around optimal ratios, ad DesignOps work is done as needed. Might not require dedicated practitioner at this stage, only a focus on ensuring set-up to do design work is present.
Design Team:
-
Design Team (31-50 people): More processes and communications needed. Still mostly generalist.
-
DesignOps (2-4 people): Establish new practices across team
Design Practice:
-
Design Team (51-200 people): See weakening of strong family feeling, and harder to stay connected
-
DesignOps (5-20 people): Aligned to specific product area or focus area and solve specific problems
Design Organization:
-
Design Team (201-600 people): Mature product and team turnover leadership change, high organizational complexity
-
Design Ops (21+ people): Scaling in new ways, with focused areas on different things. Now is creating stability for big organization
— Salesforce found that the growth of DesignOps was step behind the growth of Design Team and that the teams were scaling at different rates
-
Recognizing at inflection point, saw DesignOps problems clearly
-
Projects were going from the scope of the entire org to a single project
-
Each project took a 100% of practitioners time
-
Partners feel their need weren’t a priority
-
A multi-month effort for DesignOps
-
Product teams still need release support while Dreamforce planning is happening
-
Meanwhile, current product releases interfered with Dreamforce planning
— Salesforce can now tackle opportunities at varying scales without swinging in focus
— Problem 2- The Mind the Gap Problem: Gaps in quality emerged, since the DPMs were stretched too thin
-
There was a gap in supporting new hires and managers with formal onboarding process
-
Nobody owned managing the onboarding process for the team
-
Not insignificant number of people were being onboarded incorrectly (on average 40-60 individuals are hired, so that is a significant percentage)
-
Putting onboarding puzzle together was left to each individual manager
-
People did things differently, and had different experience per new hire
-
The new hire had to figure things out on her own
-
Manager also was new, and wasn’t able to help the new hire. This resulted in stress, frustration, and overwhelm for both parties
-
Created staged materials and feedback loops and strong relationships
-
Playbook to scale process and support, as part of broader learning journey
-
This couldn’t be done as a side project
— Valuable were skills to work at multiple levels of scope within the organization, but quality suffered at the org-level as a whole
— Problem 3- The Lone Wolf Problem: DPMs were siloed from the broader DesignOps program
— The team felt lonely and felt they were cut off from the rest of the company
-
Salesforce was forcing people into silos by having them take on too much, and take on the tasks too quickly
— The current state: They have solved the lone-wolf problem with team hats lining up to the work each team does, and having dedicated roles to focus on specific tasks
— Connections between like-minded DPMs are encouraged in the current operating model
— Problem 4-The Career Step Stool Problem: People felt stalled in their careers in DesignOps
— For some teams, the career ladder was high enough for someone to look around and see what was interesting, but no next step on what to take
-
Examples include UX Tools Ops, Event Enablement Ops, etc.
— The above slide shows how to be resilient and create new model if no longer works
— So what came of all these efforts?
-
More confident to work and fund UX ops
-
Improved morale
-
Salesforce is able to recruit and retain for Ops growth and org needs
-
Take your time: New model will take time
-
Be intentional: Approach like any other design projects
-
Be human first: Moving new people into roles, and teach people with new role like new hire
-
The even is never in sight: Always be evolving and iterating
-
Know Your Maturity: Know inflection points you are encountering
-
It Takes a Team: Bring everyone along
Questions
-
How large are each of teams in orgs? And how many associates?
-
What to say about collaborating DPM roles in an Agile environment?
-
Explain what the value of good design is to stakeholders
-
Is the structure at Salesforce similar to the structure at Adobe Design? Are other companies using model/industry benchmarks?
-
Is ReOps partner of DesignOps? Or dedicated team?
-
Do you have recommendations for orgs that have design siloed across multiple orgs?
-
Goal to figure out best practices across of other Design Teams. Thinking of how to scale DesignOps to other teams
-
Are you hiring?