Dancing for nobody: Why DesignOps works better as a shared practice
Being part of a specialized team whose goal is to optimize the performance and quality of work of another team doesn’t guarantee that your strategies will be adopted. Let’s talk about how you can overcome blockers as an Ops person.
Origin story
First and foremost, I’m an architect. No, not in the generally-accepted vocational sense, but rather in a way that’s analogous to digital design. Over the course of my career, I’ve made websites, apps, ads, and other experiences. In doing so, I developed a vested interest in process shortcuts and repeatable frameworks (even before Design Systems blew up). I wanted to be more efficient. I wanted to create templates for those doing similar work. I wanted to streamline an approach to Experience Design, a modus operandi if you will. Don’t get me wrong, I’m aware of the couple dozen million templates and playbooks that exist out there for Research, UX, UI, etc. However, there’s a unique opportunity to yield much more tailored versions within the context of working at a digital agency-entity, especially in relationship with a specific client.
Long story short: I gradually moved from Design into Operations, without having a title that reflected it. This helped me become a more effective mentor and manager — it was mutually beneficial for all involved parties. Eventually, riding the wave of the Ops boom in the industry, I would get the title.
Plot twist: I abandoned the DesignOps title in an effort to better enable my practice of DesignOps. Wait — what? I’ll explain, just keep reading.
IN MY EXPERIENCE (read with the insistence of someone who doesn’t want to be canceled for their mildly contentious opinion), I’ve found DesignOps works better as a practice than as a person or team. Yes, there is a difference.
What DesignOps means to ME
AS PER MY episode on the DesignOps Island Discs Podcast by Zeroheight (shoutout to host Luke Murphy), it’s not just about traffic control and resourcing. DesignOps is a hatching practice that welcomes novel contributions from those stepping into it. My practice of DesignOps is very closely aligned with that of New York-based Design Leader Fabricio Teixeira (as outlined in this article):
Workflow: how the design work flows within the company
Tools: what they need to get the job done
Governance: who needs to see the work, and when
Infrastructure: what the team needs to work more efficiently
Budget: how much running that team costs, and why
Headcount: how many people are needed, with which skills
Pipeline: projects coming up and how well staffed the team is
Retention: how to make people want to stay
Education: what skills are missing and how to learn them
Evangelization: help the org understand the value of design
Let’s leave it there for now — this isn’t a DesignOps 101 article, sorry.
Being brought in to fill (or create) a DesignOps position typically means assuming the role of a dedicated specialist that has a mandate to optimize ways of working for a larger Design team. Regardless of who you report into or which meetings you sit in on, your J-O-B is less design and more design support.
In my case, I was overseeing a small task-force team that existed to establish best practices and then funnel them to Designers (including a wide gamut of Researchers, UXers, UIers(?), Writers, etc.). Now, “funnel” is the choice word that I have chosen to describe choices made by choosers (my attempt here to be funny veils a criticism of those who unintentionally became bottlenecks in my path).
I love you but you’re in my way
In an ideal world, DesignOps can easily dispatch their processes and tools to the larger Design team for adoption without disruption, inefficiency, or bureaucratic negotiation and case-building. But, as you can guess, that’s rarely the case — here’s why:
- Designers have managers
- Managers have their own mandates and objectives
- Managers have their own management style (and processes)
- DesignOps needs the support of said managers in order to enforce adoption
- Managers need to commit to an initial heavy lift to establish a pipeline for DesignOps
- Designers need to be encouraged to adopt and measured on adoption
Some pretty real examples:
- Moving out of Sketch and fully onto Figma (not just because one is better, but also to manage subscription licenses)
- Defining and following a strict Designer interview process (to make sure new hires are made thoughtfully and fairly)
- Enforcing the use of and contribution to a Design System (internal and external ones alike)
- Tracking and shortlisting the team’s personal development needs against budgetary constraints
- Routinely evaluating and enforcing equity standards against team makeup, seniority, and skillset
- Forecasting and staffing for design resources without breaking allocation rules, limiting context-switching, cross-referencing with Designers’ desired growth opportunities
- Training Designers on how to use JIRA and Confluence (to better integrate them with Product teams)
Examples like these rely heavily on a domino effect of actions enabled and upheld by People Managers on the team — otherwise it just feels like you’re dancing for nobody, and trust me, that’s not a great feeling.
I love you, so can we work things out?
Maybe you were hired on a whim. Maybe someone heard that DesignOps was a cool new role to have at your company. Maybe they didn’t know what they’d actually be in for. All these things can be true. Still though, how can you move forward?
- Have a heart-to-heart with People Managers on the team, be direct and communicate the purpose of your role (read Radical Candor by Kim Scott to prepare)
- Demonstrate the value of your work and the end-state that you’re trying to drive the team towards
- Drop names of companies that are utilizing your role well
- Ground your rationale in a business case (no shame in showing how you’re saving or making money for your company)
- Be bold and roll out some low-risk initiatives without permission and just ask for forgiveness later if you need to
- Use TLDR summaries often and strategically (I have yet to meet other Ops people that also can’t help but over-document sometimes)
I love you but I’m leaving
When all else fails, or when you feel like your dancing would be better appreciated elsewhere, it could be time to pack up and leave. That’s what I did. No shade to any Managers I collaborated with — sometimes it’s just a mismatch between what the company wants and what the company actually needs. Coming to this realization also means that you likely have a good idea of the circumstances that would set you up for success.
DesignOps: Practice versus team
Where the Ops responsibilities fall on a specific person or team, the amount of cares is limited to mostly just those individuals. Operations is a part of YOUR role and the adoption and optimization that result from it are typically used to measure YOUR performance. If you’ve exhausted the suggestions for working things out listed above, then perhaps you’ve come to the understanding that DesignOps works better as a decentralized practice, a mindset if you will (as cheesy as it sounds). Even more importantly, that practice must be exemplified and mobilized from the top. Leadership should not only be on board with DesignOps, but they must actually do some of the Ops work and expect the same of People Managers on their team.
Moving on (and up)
IMHO: I can certainly say that I’ve had significantly greater success with adoption and optimization when implementing Ops at a leadership level. I see change much faster and I find it incredibly easy to enforce a DesignOps mandate through People Managers. Don’t get me wrong, I’m aware that this may come off as patronizing advice (something to the effect of “stop being poor” à la Paris Hilton’s shirt meme). Instead, I hope it communicates the importance for Design team leadership to be very well versed and supportive of what DesignOps does and needs to do. Once, during an interview for a DesignOps position, the Head of Design described the role to me as a Chief of Staff for the team — this crosses my mind a lot because if the role continues to gain traction, it does indeed need to be a senior one that exists to serve all team members through their willing and active participation.
