Setting Up & Scaling DesignOps: Q&A with Taylor Oliva
Taylor Oliva is something of a design operations powerhouse, having scaled Instacart’s design and research operations team as its Head of Design and Research Operations, working at Thumbtack as its first design program manager, and teaching design operations professionals as a DesignOps Assembly Learning Labs instructor. At Instacart, Taylor currently works with the Design and Research leadership team to identify and operationalize the organization's highest priority programs across people, processes, and products, with a focus on optimizing quality and enabling great work.
Taylor has had an unconventional career path—starting in consulting, moving on to recruiting, and eventually finding her way to what has become her professional passion: design operations. She recently shared her wisdom for the Designer Fund Collective community in an AMA (Ask Me Anything), expressing her thoughts on integrating DesignOps into organizations, crafting resilient design cultures, and making the first move toward bringing on the first design operations hire.
Topics covered:
How and When to Establish DesignOps at a Startup
Q: At what point should a startup design team consider making their first design operations hire?
A: Over the last few years, we've seen a shift across the industry in terms of when teams bring in their first DesignOps hire. The short answer is: the earlier the better. When I started in design operations back in 2018, it was very common to see companies bringing in their first design operator once their design org was between 50-100 people, including my first design team.
In the 2022 State of DesignOps report, we saw the ratio of designers to design operators change to 25:1. This is because design leaders are increasingly realizing that by investing in an ops function earlier in the maturity of their teams, they can mitigate a lot of the operational and infrastructural debt that happens organically as a result of design orgs scaling quickly.
Programmatic areas that are traditionally owned by Design Program Managers (DPMs)—such as tooling optimization, resource management, org governance, and hiring and onboarding best practices—can be established for scalability early on when a DesignOps person is hired when the team is still small.
Additionally, the pandemic forced companies to shift to remote-first, which meant that teams had to design remote-friendly environments that could enable collaboration and excellent work, which is what design operators do best.
By investing in an ops function earlier in the maturity of their teams, they can mitigate a lot of the operational and infrastructural debt that happens organically as a result of design orgs scaling quickly.Taylor Oliva
Q: Do you think there's a specific tipping point where an organization needs to establish DesignOps?
A: Here are common signs to watch out for within a design organization that are clear indicators that it's time to hire someone for a full-time DesignOps role:
- Managers or ICs responsible for operational tasks are spending more time doing those tasks than they are designing or managing design
- The cascade of information and project updates is becoming more and more difficult because it relies on individuals and not on structured or automated processes
- The org is so large that the sub-teams start to create silos, resulting in inconsistent design processes and a breakdown in intra-org collaboration
These are all areas that require a full-time person to design scalable programs and processes to better enable the overall operations of the org.
Q: How can sole designers or small design teams start laying down the foundations for design operations even before making that hire?
A: For designers who are doing operations work without a DPM (someone who can plan team bonding events, run sprints, manage onboarding tools, run team meetings), it’s crucial to document everything. Write down all decisions regarding the team's processes, programs, and best practices. Doing so will expedite the discovery phase of your first design operator's onboarding so they can dive into problem-solving and establish structured programs faster.
Skills to look out for in a DesignOps hire
Great DesignOps practitioners come from all backgrounds, but there is a core skillset that will help make them successful in the role. Here are a few that are commonly included in DesignOps job descriptions:
- Project and program management skills and ability to manage multiple work streams at various levels of complexity
- Experience in process and system design with a user focus
- Cross-functional collaboration and stakeholder management (up, across, and down)
- A culture builder who is a strong advocate for diversity, equity, and inclusion
- Ability to navigate ambiguity and conflict with minimal oversight; proactive with a bias for action
- Fluent in project management, productivity, and information management platforms (Asana, JIRA, Google Suite, Slack, Confluence)
- Bonus Areas: Budget management, vendor onboarding, tools procurement, and familiarity with design tools, process, sprints
How to Build and Scale a Design Operations Practice
Q: How have you seen Design Operations incorporated in larger companies?
A: It varies from company to company, but it’s pretty common for DesignOps functions to be comprised of two sub-teams: one to handle horizontal programs that apply to everyone within the design org (such as onboarding, L&D, culture, tooling management, etc.), and a team of DPMs who are embedded within specific design teams or lines of business to enable the end-to-end design process within that team. That said, the findings in this year’s State of DesignOps report indicate that we’re starting to see more specialist roles (e.g. DPMs specializing in tooling, DEB, or culture) across the space.
Q: What are some of the common missteps that you’ve noticed or experienced when establishing a DesignOps practice at a company?
A: The most common ones are trying to do it all early on and skipping some of the less glamorous ops work (like effective vendor management, compliance, budget tracking, tooling) for the more "fun" stuff (like team swag, offsites, team social channels like Instagram or Twitter).
In DesignOps, it's important to tackle the "business ops" side of the house early on because ultimately, your design org is a business unit within the broader company. Once those business building blocks are in place, you can start to expand DesignOps' focus to establish and iterate on programs for craft, culture, and community. That said, it's very common for scaling design teams to do a little bit of everything across culture, process, people development, and business operations. Just be sure to not ignore the basics!
Q: What is one core thread you have seen across teams that needs to be worked on?
The question I hear most often from other design operators is, "how do I wrangle my design team's tooling suite?", which makes me believe that effective tooling management is a pain point for every organization.
Are designers using the same tools for designing, prototyping, or running user research? Who owns the vendor relationships and budget for those tools? How is access provisioned and de-provisioned? What is the process for managing PII on those platforms? Is there a best practices playbook for using the tool for new designers who join the team?
Most design teams think about onboarding tools as a one-and-done project, but it's actually a program that needs ongoing management and iteration to ensure ease of access, compliance fulfillment, and fiscal responsibility. And with the rollout of global and local data privacy legislation (such as the CCPA and GDPR), effective data management across design platforms has become a legal requirement, not just a nice to have. Having a DPM focused on your design team's tooling is critical!
How to Structure Design Teams
Q: How do you organize product and brand designers working across different teams? Is it best to keep researchers, product designers, and brand designers under one department?
A: This is going to depend on your design org's and company's maturity level and size. I have experience with both. At my last company, the brand design team sat within the design & research org; at my current company, the brand team is part of the brand & marketing org.
For UX teams (product design, content design, and research) in particular, it’s important to have them embedded within product lanes or teams so that designers and researchers are empowered to form strong working relationships with their PMs and engineering partners and ensure the work is anchored on creating human first experiences throughout the product.
And once your DesignOps function is big enough to establish an embedded program management team, your embedded DPMs can design workflows for the product teams with that user-first approach in mind.
Q: How do you think about the design ladder for designers, especially when their work and goals are very different across research, product, and brand?
A: What I've seen work really well—especially as growing design orgs try to figure out how to structure a career ladder and criteria that will work for all of the functions within the organization—is to start with your company's competencies.
If your company has set competency buckets, start there and figure out how those translate to skills or behaviors that you would want to see at each level of the career ladder for each of the functions within your org (e.g. collaboration, communication, citizenship impact). From there, you can add additional competencies that are more relevant for the design org functions (e.g. craft, research expertise, program management expertise).
Q: What is a healthy split between researchers, UX designers, interaction designers, etc.?
A: When you’re planning for the year ahead, you're not only thinking about what your product orgs are going to be working on, but also how you are going to staff those projects accordingly. In a perfect world, we would have designers, researchers, and content writers for every lane of business that needs UX support, but that's almost never the case.
What I've seen work incredibly well is sitting down with your design and research leadership and understanding the top priorities across the business and what it would take in order to effectively support those priorities with each function. If you know that there are gonna be a hundred projects that need to get tackled and you don't have the bandwidth or the headcount capacity to support all of those things, identify the ones that absolutely need support.
How to Collaborate With Cross-Functional Teams
Q: Any advice for promoting collaboration and coordination within an EPD (engineering, product, design) org?
A: My current company is the first place where there was another operations team (Technical Program Management) in place within the product org when I started to establish the DesignOps function. Fast forward to today, we now have DesignOps, Research Ops, and Marketing Ops, in addition to Technical Program Management. Because all these functions are relatively new, we're still figuring out how we can all enable our teams to collaborate better. It's still very much a work in progress.
One example of how we're doing this is a weekly review forum (Design and Research Workshops), during which designers and researchers bring in-flight projects for discussion and feedback with the VP of Design, and we invite their cross-functional partners from product, engineering, brand, and marketing to join. This has helped bring those partners into the design and research process earlier, mitigate potential areas of misalignment, and enable a more collaborative product development process.
Q: How involved has DesignOps been in the product roadmapping process? Have you found that it is good for DesignOps to get involved at a specific point, or let product lead this and collaborate as needed?
A: At Instacart, planning (e.g. staffing allocation, design and research priorities) is driven by our design managers, who spend a lot of time building strong partnerships with product managers. Product partners loop in their design and research leaders early—ideally prior to planning kick-off—so there’s time for the team to run research and vision sprints, ensuring that informed, user-focused decisions are made throughout the planning process. Our DesignOps team started to plug into roadmapping this quarter and are establishing the best practices for supporting that process.
How to Foster Design Culture & Community
Q: Any best practices for fostering a strong design team culture, especially for async or remote teams?
I love anything that has to do with enabling or fostering a strong sense of connection, culture, and identity within a design org. This has become exceedingly difficult, especially in a remote environment. The moments of connection that historically happened at the coffee bar and over lunch now have to be intentionally designed and folded into the team’s remote day-to-day.
My current team has spent a lot of time thinking through how we organically carve those moments of connection into existing forums on a regular basis. One of the things that we did last year was pulling together a playbook with really fun visuals and tips and tricks around how to make your meetings not suck. It included everything from excellent icebreakers to how to use tools like Slack, Zoom, and Google Hangouts in a way that enables folks to feel included, connected, and engaged.
We also host a monthly design & research all-hands forum. It’s one of the most highly attended meetings within the org, and people see it as an opportunity to not only get updates from our VP of Design and learn about work happening across the org, but to also celebrate people's birthdays and welcome new hires. For example, one all-hands last year was Halloween-themed, so we hosted a live costume contest where folks could submit pictures of themselves in costume and vote live over the course of an hour.
Q: How might a company's design culture and process make room for designers to learn and grow, even while they're doing the design work?
The idea of honing and elevating your craft—while having the capacity both time-wise and mentally to focus on your learning and development—is a critical piece that many designers and creatives seek out in their roles.
Launching a mentorship program within the design org is something I’ve seen work well. This includes pairing up more tenured designers or researchers with folks who are just starting out in their careers to help coach them through how to give and receive effective feedback or how to be more strategic when they're showing up with their cross-functional partners on a project. It often involves things like roundtables, discussions, and panels featuring the mentors.
We’ve also had team members within our organization run lunch and learns, covering topics related to growing and developing design skills, whether it's using Figma or running a design critique. Within the design org, we collated a list of conferences, trainings, and workshops into a centralized hub to highlight potential learning opportunities to our org members.
How Taylor's Role Has Evolved
Q: How do your responsibilities and day-to-day now as a Design Planning & Development Lead differ from your former role leading Design and Research Ops?
When I was leading the design operations team, a lot of my time was spent coaching my team to tackle the programmatic initiatives they were driving—whether it was onboarding Figma, establishing a vendor management process, or coordinating org-wide events and team bonding offsites. I wasn't doing a lot of the tactical work myself, but instead, ensuring that my team was supported, providing them the resources that they needed, and unblocking them so that they could drive those efforts successfully.
In my new role, it’s been a lot of fun getting to dive back into some of the more tactical components of program management and operations at a much broader level. It’s a new problem space in which I’m doing a lot of zero-to-one building, but it’s still at the intersection of people, process, and product. And instead of thinking about these areas within the design org exclusively, I'm thinking about them more broadly, spending time strategizing on how the design and research organization partners effectively with other sides of our product development org, asking questions like:
- What is our relationship with our product partners?
- How do we ensure that we have the right review forums established?
- How do we think about the journey of reviewing design work, from team-level crits all the way up to reviews with our company leadership team?
- How do we put processes in place so that all stakeholders understand how to show up successfully?
My scope in this role also includes operating as the Chief of Staff to our VP of Design and our senior design and research leadership team. This means helping them operate effectively, ensuring that we're cascading information regularly and clearly, and making sure that we're thinking about the timing of things like planning, hiring, events, and visioning for our organization. I’ve been enjoying taking the skills that I've honed over the last few years leading a design operations function and applying them in a different context.
Key Lessons from Taylor
- Establishing DesignOps earlier in a team's maturity can help mitigate a ton of operational and infrastructural debt down the line.
- Documenting everything in advance—including team processes and best practices—makes it that much easier when bringing in your first DesignOps hire.
- A common mistake to avoid: skipping the less glamorous but foundational business ops work (like tooling and compliance) for the "fun" stuff (like swag and offsites)
- Consider hosting weekly review forums with cross-functional design partners to foster collaboration and prevent misalignment.
- DesignOps practitioners have the opportunity to create spaces for designers to connect, learn, and elevate their craft. A few ways to do this: mentorship programs, lunch & learns, and all-hands forums.