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

 

— Imagine your DesignOps team is a coin and every time you flipped it, the coin comes up heads. You would think the other side was missing
  • Coins like DesignOp teams have more than one side
  • Examining all sides of the coins leads to new ways to grow

 

 

— Why did Salesforce consciously decouple DesignOps into TeamOps and ProductOps?
— The Salesforce team will walk through to recognize an internal inflection point in the design organization, the problems this inflection point might create, and the resilience in building new operating model

 

 

— Rachel and Jon represent two sides of DesignOps at Salesforce
— TeamOps is all about optimizing for the UX organization as a whole, and is about scale, and partner with the entire global UX team
— ProductOps is all about optimizing for small individual product UX teams, focusing on supporting 40 products across eight business units

 

— TeamsOps: Community and Culture, Learning and Growth, Systems and Tools.
  • 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
— ProductOps: Productivity and Delivery for UX products
  • 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

 

— The sine graph above shows how people share and learn from each other
— Product Operations are experts within team, customize within their needs
  • 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
— It is an iterative and collaborative process as each team learns from each other

 

— Sample initiatives delivered for UX by the two teams
  • 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
— UX Ops
  • 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

— Let’s go back in time before ProductOps and TeamOps.
—DevOps was a bunch of unicorn design product manager and functioned as a support team for everyone.

 

— DesignOps did everything,
— The team wore many hats, but didn’t put process around own team structure
  • Way work was taken on, prioritized, and distributed, didn’t make rational sense

 

— DesignOps heard complaints from DPMs
  •  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

 

— The Design partners also had various pain points with the current set up:
  • 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

 

— Trajectory of DesignOps org was out of sync with the trajectory of the Design organization as a whole
— The two were not growing and scaling at same rate, and mismatch was causing problems

 

— How do you recognize this mis-match in scale?
— The above chart shows different rate of growth for a design team, and how DesignOps should grow as a result
The different org levels are as follows:

 

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

— The DesignOps was solving the wrong problems for the organization
  • Recognizing at inflection point, saw DesignOps problems clearly

 

— Problem 1- The Pendulum Problem: DesignOps problem was shining wildly between priorities
  • 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

 

— The speakers provide the example of the Salesforce Dreamforce Conference (which has 100,000+ attendees)
— DesignOps built out the logistics for the Dreamforce conference, but this meant:
  • 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

 

— How it is now: Salesforce now has two dedicated teams for priority, and a clear RACI model. DesignOps is not responsible for everything under the sun
— Sharing and amplifying team org wide is not responsibly of a single DPM

 

— 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

 

— How could DesignOps look across at problems happening in the org, while solving internal team problems simultaneously?
— Since DesignOps was splitting priorities across multiple levels of zoom, easy for balls to get dropped
  • 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)
— Onboarding before the change:
  • 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

 

— What was done: A dedicated owner as assigned for the onboarding process
  • 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

 

— People felt urge to get things done, and were inheriting responsibilities that didn’t match skills
  • 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

 

— From a Glassdoor survey, turnover is heavily driven by workers feeling they are stagnating in their current roles
—Salesforce thankfully hadn’t lost DPMs, but it did have problem of attracting talent, and had DPMs with specialized skills who did not know how high could they climb
— The Design Org growing fast and more opportunities for people with specialized skills were appearing

— The TeamOps and ProductOps tracks refine and simplify the rules, and let people be recruited for specific things
— The Ops structure allows for specialization and management
— It allows people to celebrate skills and talents

—It allows people to celebrate skills and talents in new Salesforce domains:
  •  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?

— The new model gives focus and clarity for partners
  • More confident to work and fund UX ops
— More quality in projects, such as the new hire program
  • Improved morale
  • Salesforce is able to recruit and retain for Ops growth and org needs

— Salesforce DesignOps is still on its journey and has a ways to go. But there are a few takeaways:
  1. Take your time: New model will take time
  2. Be intentional: Approach like any other design projects
  3. Be human first: Moving new people into roles, and teach people with new role like new hire
  4. The even is never in sight: Always be evolving and iterating
  5. Know Your Maturity: Know inflection points you are encountering
  6. It Takes a Team: Bring everyone along

 

— Know that it’s okay to flip DesignOps coin and be critical of operating model and move forward
—Thank you to DesignOps 2020 and our viewers. We are grateful to speak with all of you

 

Questions

  1. How large are each of teams in orgs? And how many associates?
— About 4 people for UX Ops
— ProductsOps team of 8 people across 40 products
  1. What to say about collaborating DPM roles in an Agile environment?
— Good luck, it is the right form of action to take
— The hard part is getting partners to think what is meant to do good design
  • Explain what the value of good design is to stakeholders
  1. Is the structure at Salesforce similar to the structure at Adobe Design? Are other companies using model/industry benchmarks?
— Facebook has DesignOps folks, but its not clearly structured
— People of thinking similar models, but as far as they can tell, not rolled out yet
— Would love to know what other teams are doing
  1. Is ReOps partner of DesignOps? Or dedicated team?
— ReOps team moved from DesignOps into larger organization looking at broader project scope
  1. Do you have recommendations for orgs that have design siloed across multiple orgs?
— Develop a horizontal team, and working to  have Salesforce Design coordinate with other design teams across the org
  • Goal to figure out best practices across of other Design Teams. Thinking of how to scale DesignOps to other teams
  1. Are you hiring?
—  Salesforce is growing and expects to hire more in the future.