Team Ops and Product Ops: The Perfect DesignOps Pair

By John Calhoun and Rachel Posman

With all the change 2020 has thrown our way, there’s some bittersweet comfort in knowing that one thing has remained stubbornly constant: most design-driven companies are still trying to figure out Design Operations (or DesignOps, for short). This is totally fair — we’ve been practicing DesignOps for many years, and we’re still figuring it out.

In short, DesignOps amplifies the impact of design teams; we help them scale and deliver their vision, and support individual designers as they develop and focus on their craft. In this rapidly changing world, where companies of all kinds are scrambling to improve digital services and customer experience, good design is more important than ever. And as the scaling engine for good design, DesignOps teams have arrived at a critical moment, when how we do things has a direct impact on bottom-line success.

While there’s a lot that DesignOps practitioners are still figuring out, we’re not doing it alone. We’re building a community, forging our identity, and supporting each other through conferences, including DesignOps Summit 2020. In fact, your intrepid authors spoke at this year’s Summit about a how our own DesignOps team split its operating model into two discrete tracks, Team Ops and Product Ops. This change sets the stage for the future of our growing team, letting us scale the impact of our designers’ work to reach the millions of Salesforce users and customers who depend on our products.

Two Sides of the DesignOps Coin

We refer to Team Ops and Product Ops as two sides of the DesignOps coin. Together they form a “scaling engine” encompassing activities that help accelerate and deliver great product design.

Team Ops design program managers (DPMs), who optimize for the whole design org, with a focus on programs that go wide, scale best practices, and influence team culture. The Product Ops DPMs, meanwhile optimize for our specific product design teams; they go deep with our designers and researchers, with a focus on helping those teams deliver. In practice, this means our DesignOps team is organized to deliver service both horizontally (across the team) and vertically (within a single product).

Team Ops owns Community & Culture, Learning & Growth, and Systems & Tools. Product Ops owns Productivity & Delivery and Project & Program Management, and partners with Design Leadership.

The two tracks work collaboratively. Typically starting within Product Ops, DPMs create customized solutions for their teams (for example, a process for sequencing design work between two dev teams). As these processes mature, they are shared with Team Ops, which optimizes the solution so it is scalable, extensible, and repeatable (for example, a workflow that any design team can use to sequence its work), in the form of a team playbook, toolkit, best practices document our other output. Outputs are put into practice across product design teams and continuously iterated on as needs and improvements dictate. And yes, if this sounds like using design thinking to design your design org, you’re correct. (Also, you’ve scored a Design trifecta.)

Product Ops and Team Ops collaborate on the artifacts needed to scale and deliver great design, in a repeating cycle of iteration and sharing.

Why Two Tracks Within One Team?

We didn’t arrive at this operating model overnight. It was the outgrowth of months of pain points, for both our DPMs and their partners. The tricky thing about pain points: They’re not always obvious when you’re the one experiencing them. Nevertheless, the signals were there. Our DPMs felt stretched, had too many competing priorities, and were covering an overly broad set of responsibilities. And our partners (inside and outside Design) were asking for more clarity, a stronger POV on tools and process, and more Ops time dedicated to helping design teams do great work.

Quotes from our DPMs on how we were feeling when we “did it all”; quotes from our partners about their resulting pain points,

DesignOps leaders heard the message. But what was the source of all that pain? We realized that the team had reached an inflection point — our Ops trajectory was out of sync with our Design org, which was growing and scaling far more quickly. This situation may familiar; it can happen whether you have a part-time DPM or an entire Ops team. Recognizing the inflection points is key to understanding what kinds of problems DesignOps should be solving. And the best way to be prepared is to know where your teams lie on the spectrum of design team maturity.

A design maturity model, inspired by Aaron Walter’s “Lessons in Scaling Design.” Our DesignOps team was solving the needs of a design practice when we should have been solving the needs of a design organization.

Check out the maturity model above. Your mileage may vary, but our pain points arose because we were solving for the needs of a design practice instead of a design organization. Recognizing this inflection point helped us see our problems clearly — the catalyst for rethinking our operating model and creating two tracks.

Problems. Solved.

The problems we were experiencing will probably sound familiar to any DesignOps team at the “design practice” level of maturity. Most issues fell into one of four themes, which we call the Pendulum Problem, the Mind the Gap Problem, the Lone Wolf Problem, and the Career Step Stool Problem. Here’s a look at each, and how our new operating model has helped push us in a better direction.

The Pendulum Problem is when your do-it-all DPMs have priorities that swing wildly, from helping the entire org to helping a single project. Each of these takes 100% of their time, and swinging in either direction can lead some partners to assume their needs are not a priority.

Solution: Discrete Team Ops and Product Ops tracks let us tackle big org things AND specific product things, without swinging wildly. Our partners no longer worry about losing DPM support to giant org initiatives, nor do we have to pause an org-wide project for product release milestones.

With the Mind the Gap Problem, quality gaps, and blind spots emerge because DesignOps is trying to look across and down simultaneously. DPMs get split across multiple levels of focus, quality suffers, and balls get dropped.

Solution: While multi-tasking and multi-focus will always be valuable DPM skills, having DesignOps tracks that focus on specific altitudes makes it easier to close quality gaps and address problems (such as onboarding, training, and communications) at levels that can scale across an entire Design organization.

With the Lone Wolf Problem, DPMs take on such widely varying responsibilities that they don’t feel aligned with each other, or with the DesignOps team. Each DPM can end up owning a niche that nobody else needs to occupy, creating artificial silos and eroding family feeling.

Solution: Our operating model encourages connection between like-minded DPMs who perform more targeted, but more similar roles. And our DesignOps family is drawn together to scale up best practices from small teams and implement org practices back down into them.

With the Career Step Stool Problem, the DPM career ladder looks more like a step stool: DPMs get high enough to look around, but there’s no next step. No clear ways to develop and specialize can lead DPMs to get discouraged or look elsewhere.

Solution: The Team Ops and Product Ops tracks solve the specific needs of our Design organization — scale and delivery — and allow us to refine and simplify our Ops roles to match. We can recruit and grow people who are really good at specific things and match that with a career ladder that reaches higher, supported by an Ops team that’s set up for growth and specialization.

You’ve Reached the End. But It’s Also the Beginning.

Our “conscious uncoupling” of DesignOps into Team Ops and Product Ops has had a positive impact on our DPM team and its partners. We have more focus and clarity; morale and sense of family have improved. Our partners are more confident about working with (and funding!) DPMs, and we’re better positioned to recruit and retain talent that can sustain our growth. But we recognize that this process is a journey, and it’s only just beginning. Some lessons we’ve learned along the way:

• Take your time. The road to a new Design Ops model is long and often winding.
• Be intentional. Approach your new model like you would any other design project: set a goal, assign owners, do your research, experiment, and get feedback.
• Be human first. Making new roles within a new DesignOps model means moving people into those roles. Write good job descriptions, and treat the team taking on these roles with the same care as you would a new hire.
• Know your maturity. Reflect on the maturity model of different design teams. Know where you are, and which inflection points are on the horizon.
• It takes a team: Bring the whole team along on the process. Listen to every voice.

Our DesignOps team is simultaneously growing, and learning to grow. We hope sharing some of the problems and insights we’ve encountered along the way will help DesignOps teams of all sizes grow in ways that are healthy and sustainable for their DPMs. And if you’re interested in growing with us, please check out the Salesforce Careers and search for roles on our Design, UX, and Operations teams. You can also connect with us on LinkedIn (Rachel Posman and John Calhoun).

Special thanks to Jason Kriese and the Salesforce UX Operations team for their partnership and leadership along this journey. And thank you to Noelle Moreno and Lisa Stonestreet for your feedback and edits!

Learn more about Salesforce Design at www.salesforce.com/design.
Follow us on Twitter at @SalesforceUX.
Check out the Salesforce Lightning Design System