Episode 8: Design Operations

Welcome to Opsy, a podcast for people doing opsy work in tech. I'm your host, Caro Griffin. And every month I dig into what opsy work really is by talking to an operations pro who has something really cool to teach us in a traditional part of ops like HR or finance, or a newer specialty, like no-code ops or marketing ops. Thanks for listening!

This episode is sponsored by Runner, a platform that connects outstanding operational talent with inclusive companies.

Today, we're talking to Dominique, Head of Design Ops at Atlassian.

But first, a confession—I didn't actually know what design ops was before I started Opsy. It was only through members of our community that I learned about this growing field and how valuable it can be not just to a design team, but a company at large.

I knew from the get-go I wanted to do a whole episode about it with an expert in the field, and Dominique Ward is definitely that, but I'll let her explain. So without further ado, let's dive in…

Caro 1:07
Dominique, thanks so much for joining me today. I'm really excited to talk about ops and design ops and your career over the last couple of years and how you found yourself in the role that you're in today.

Dominique 01:12
Yeah, thanks for having me. I'm so excited.

Caro 01:15
Let's start at the beginning. Why don't you tell us a little bit about your career path so far, and how you got into operations?

Dominique 01:22
In the beginning… I've been a nerd all my life, but I really wanted to be an aeronautical engineer and so that's why I went to Purdue to study engineering. Then I woke up one day and I was like, "There is no future or job prospects in engineering so I'm going to switch my major to philosophy." [laughs]

Caro 01:46
Wow, quite a journey. I love this. I feel like there's going to be lots of twists and turns in this story.

Dominique 01:52
[Laughs] So being 18 years old, it was really for me… I don't need to get too far into this, but I had done a program with Lockheed Martin in high school and it was focused on getting more girls and people of color interested in engineering. We were designing robots and programming them and it was just so fun. Then you go to college and you're doing MATLAB and you're doing all of these things that… It's not fun.

Caro 02:36
You're like, "Where are my robots? I signed up for robots."

Dominique 02:38
Where are my robots? Why am I stuck in a computer lab learning this coding language that doesn't actually get used? No shade to any engineering programs, but it was less than inspiring.

One of the things that I've always been interested in is getting to the root of a problem and figuring [things] out from there, which is at the end of the day, not that different from engineering or design or philosophy.

When it came [time] to start working, it was 2008. I ended up applying at a startup for an office manager job that I didn't get. But then they called me back and they're like, "Hey, we have a role for you."

I went and I talked to the VP of Finance, and he's telling me about the role and I'm like, "I have no background or interest in this whatsoever. I don't want to be a CPA. I don't want to be an accountant. I have no background in finance." And he's like, "Oh no, I know that, but I think you can do it." I'm like, "No, I could do it but like-"

Caro 03:46
But I don't want to do it!

I have to say when I saw the finance role, from finance to design ops, I was like, "I've seen some interesting combinations, but this might be the most interesting." So I was excited to see how you… It's funny, I got into my first job in the exact same way. I applied for a role and then they were like, "Oh no, this other role." And I was like, "I don't know about that."

But I'm interrupting, so continue your story!

Dominique 04:04
Oh no, you're fine.

I was the first hire on the finance team, so it's just me and the VP of Finance. The title initially was billing analyst, but what it ended up being was really figuring out why our customers were churning and what was happening, which in hindsight was a design job.

There was no way for a customer to enter a new payment method. There was no cancel button. There was no ‘change my terms of my contract’ or ‘re-up my contract.’ It was all in the product. Those are all UX problems.

So, in hindsight, I've been in design my entire career and I've been digging into the root of problems and trying to identify solutions and opportunities—from my very first job with the VP of Finance and then when I went on to work at Frog Design, which is an innovation design consultancy.

I started out in program management which I hated, to be frank. An opportunity came up a year in and I jumped at it. Really, my job was to analyze the numbers and figure out how you run design as a business. That's anywhere from scoping, to how do you structure teams, to what are the opportunity spaces and the type of work and industries that we should possibly go after, and how does it then ultimately impact the business?

What's interesting is that, looking back over my career, I've largely just really closely worked with executive leadership from that very first job. That has uniquely helped me identify, “How do I tailor how I communicate and the insights that I'm giving to be actionable? To be understandable, quite frankly.” Because, a lot of times, especially with designers in a certain context, depending on your exposure, when you see a wall of numbers, you're like, "So what?”

The ‘so what’ is really important, and I think that's also really important when it comes to any operational role. It's like, “Here's some inefficiencies or here are some gaps and some pain points. Here's why this is important,” not just the fact that they exist. Because at the end of the day, there will always be pain points. You can't solve for all of them. But here's how solving for this or how removing this roadblock will affect us down the line, and so it's really important for it to be actionable.

I really loved working at Frog. A lot of those people are some of my best friends now. I've been very fortunate to have had great mentors and managers, and a good chunk of them came from during my time at Frog, and many of them are my friends and still my mentors now. They have helped me shape my career and helped me grow.

Then after Frog, I was like, "I really want to continue in a creative environment, but maybe not a design consultancy." So I went into advertising, a new frontier.

I spent a year and two weeks in advertising. I was Head of Business Operations, but really, it ended up being all of ops—so people ops, program ops, all the things. It was an opportunity to bring design best practices, so design methodology, into a different type of creative space, into the advertising ways of working. So, really building out a new business model, a new engagement model with clients, a new way of pricing. Instead of billing by hour, how do we do that in a package way?

I was really fortunate to have two founders of that agency who were really interested in breaking the mold. That's really what we were digging into and hiring different types of people from different backgrounds, going after different types of work, having a different business model. It was really fun to build everything from the ground up.

Then I was interested in really going back to design and solving problems. I was really looking for, “What type of problems do I want to solve?” Team problems. I want to see how it trickles out into the customer, which is one of the things that I loved about working at Frog was designing the future.

I look at design operations as really designing design, who is then designing the future of X. So it's a super meta role.

Caro 09:22
It is. That's a great pull quote, “designing the design, designing the future.”

I love that earlier you were talking about building these processes and how it's really a design role. The whole time before you said that I was thinking, "Oh, such an ops role."

I think you've so clearly tied those things together because it's like so much of ops and design is solving a problem, or at least experience design and UX, and really seeing that overlap there.

We're five minutes into the episode and I'm like, "I get it so much more clearly now."

Dominique 09:54
When I joined Atlassian, and that's where I am now—I'm now Head of Design at the Design Office at Atlassian—it was a new frontier for me. Because it had been about eight years since I had been in tech explicitly. When I joined [that company], I was hire 75. Then we grew to 200. Now they’re well over 1,000 people.

Atlassian, when I joined, was 5,000 people and I'm like, "I've never worked at a company this big." Because, even Frog… it was a global company. It's been around for 40 years, or 30 years at that point and it was still like 750. I think the largest at that time was 1,000… but 5,000 people? That's continually growing? It's a different culture. It's not driven by design. It is driven by engineering and product. So, how do you pivot into that culture?

That has been such a great learning, just for me and how I work, and also in opening up my worldview.

Caro 11:02
Absolutely. You were talking about having been able to work really closely with executives. It sounds like once you really got it, they were open to change. Such a necessary part of ops is that, while you can come up with these big problems and solve them and come up with these really innovative solutions… you still need that buy in.

Then, in an organization the size of Atlassian, like you said, who doesn't have as much of a design focus, I imagine it's looked a little differently. Can you talk more about how you've had to adapt in that environment?

Dominique 11:32
Before I joined Atlassian, there was someone in the role of Head of Design Ops before I joined, actually a former Frog, Tim Paciolla. He was a design leader who was really ops-minded. He went to Atlassian and he started a design ops org. About a year in, he was like, "I really miss being in the weeds in design." It was also at this period of change.

As orgs continue to grow, there are different eras. The design team at Atlassian is about 10-11 years old. It's about half the time that Atlassian as a company has been around. Atlassian is 20 years old. So, as an org, compared to engineering, we're pretty young, which means that we've just grown over the past 10 years in both size and "offerings" and maturity. So right now, we're in a different period.

But when I joined three years ago, we were trialing out a different model and figuring out, “how can we really double down on how we work cross-functionally as a team?” Because we are a teamwork company, right? We're trying to unleash the potential of all teams, and that includes our teams as well. And having a robust, high functioning, healthy, cross-functional team, at the end of the day helps us deliver great experiences and great products to our customers, who are then trying to have healthy well-functioning teams.

So, we did this experiment where we were trying to take the learnings from design operations and apply them across all of our cross-functional teams, so R&D, so design, product management, and engineering.

In a lot of ways, I think we were maybe 10 years ahead. Because at the end of the day, when you're looking at trying to take learnings from an org, it's hard to do that if you still need to work out the kinks in the org. And so over the past two years, I’ve really just been focused on design. I report into our platform org and I’ve really been thinking about the pain points that designers, the design team and then the overall design org are experiencing. Then figuring out how we partner with engineering and product management to ensure that we're not doing things in silo, that we're building a shared understanding across the craft so we, at the very least, have the same language and we're pointed in the right direction.

Because that's the thing. When it comes to teams, whether it be conflict or missed roadmaps or missed expectations, it's because you're not pointed in the same direction when you start.

Caro 14:40
Yeah, and you're using different labels to talk about the same things. This has even come up on the podcast before, I think in our marketing ops episode, because it's so many people use… We use the same words to mean different things and it's just the root of so much confusion. In theory, we're all speaking the same language, but we're speaking something different. So much of ops can trace back to that, or at least in my experience it has. And it sounds like you've had the same kind of experience.

Dominique 15:05
It's an ops thing, and it's just also a people thing. So much of operations work is about the people.

Caro 15:16
We talk about how, as ops people, we love spreadsheets and quantitative things, and we're process-driven, but also we're people.

So much of the problems that we're trying to solve have an organizational, like from a team organization standpoint, to a communication problem to the whole sector of people ops, which falls under operations. So many problems are communication problems and people problems, if not the whole problem then like a piece of the problem.

Also, you've mentioned being part of this larger org as Head of Design Office at Atlassian. I'm guessing you lead a team, which is a bit different than owning design ops as an individual contributor at a smaller organization. You mentioned Atlassian has 1,000 employees. I’m curious to hear what your team looks like and who you work closest with in the org.

Dominique 15:58
Design operations has, with that name, only been around since about 2015. But design ops as a thing that needs to be done has been around since the dawn of design. The reality is that, regardless of whether or not you have a design ops function or team or someone who is explicitly in the role, design operations is happening. It's usually being done by design managers or even ICs.

So, because it's been this nascent and growing and now pretty widespread and expanding function, many teams and organizations in the past five years especially, they're like, "We should try this design ops thing." And so, they hire one person. I say one person, and it does not matter the size of the org. You could have a 30-person design team or you could have a 500-person design team, and they always start with one.

There are many, many, many, many design ops teams of one. I myself started as a team of one. The first two years I was a design ops team of one. Now I have six people on my team and I have five open roles. By the end of our fiscal year, which ends at the end of June, we'll have 12, fingers crossed if I can get butts in the seat. By the end of the following quarter, we should have 16. We're rapidly scaling.

Part of that is because we plan to grow significantly as a company, Atlassian, in the next three years. Obviously, that means our design team is going to grow as well.

I mentioned that because, when you're a design ops team of one, you only have a certain vantage point. Depending on the size of the org, you can maybe get a little bit deeper if it's a 30-person team, you can juggle all the things. But, when I joined, we were 150. By the time I got my team, we were 250-280 people. So those ratios don't really balance.

A lot of the things that I focused on when I was a team of one where org-wide things - How do I partner with the heads of design to identify the pain points across the org and figure out cross org solutions for that? Or opportunities to build that and also advise them given that I can't take on the tactical work out of that?

Then, as the team has grown, we've been able to go from spreading across the ice and just flying across to being an inch deep where I was to going a little bit deeper, and then also refining what we're focusing on. I still partner with our two Heads of Design, our Head of Platform, our Head of Products, and then their direct reports. I'm part of both orgs' leadership teams.

As we continue to grow, we'll embed design ops leads into each of those pillars or organizations, and they will then partner with those Heads of Design in their next roles of leadership. Then we can identify, what are the pain points that are happening within the Agile DevOps team? How do we share those learnings, those pain points, those solutions that we've come up with and share it across the org so we're all benefiting from it?

One of the things that happens is that as your organization gets larger and starts to function as individual business units, they create silos and then operational inefficiencies. One of the big risks with growing an organization like a design ops org is that you start to replicate the pain points that exist already in the org. If you embed, and don't come back to a central organization where you can share those learnings, and then the solutions, the pain points live and die there, and no one else benefits from it.

And so, I’m trying my best as a team to resist Conway's Law and really think about how we can be one step ahead of that. But I have a great team who's really thinking about how we design programs, templates and tools, best practices in collaboration with our ICs and our leaders to ensure that we're amplifying the value and the impact of designers and design org.

Caro 21:10
It really all comes back to communication, scaling, so much of that. I was just having this conversation the other day where I'm like, if you think you're saying it enough, you need to say it twice as much. You have to say everything in at least three different formats. If you're going to bring it up in a meeting, then it's also in Slack, it's got to also be in email, it's also got to be in your Notion or whatever tool you’re using for info-sharing because people need to hear it a bunch of times in order for it to sink in. People don't check every medium. You can feel like you're repeating yourself, but that's such a part of scaling that I hear you're talking about here.

[Music]

Hey Opsy friends, this is Lauren from Runner. The power to curate your career is here with Hire Runner. At Runner, we match fractional operations talent known as Runners with inclusive companies. Our runners not only get access to a suite of benefits, but they get to pick their schedule, set their pay rate, and work with companies they're passionate about supporting. No more cheap gigs, horrible bosses, or miserable schedules. Visit hirerunner.co to apply today.

Caro 22:00
I want to hone in on something you said about how you're part of two different design leadership teams. I imagine, as you scale the design ops team, that becomes its own leadership team too, if you're going to have all these design leads.

So, thinking about that… How do you communicate across all of those? Are you leaning on async tools? Do you really prioritize the written word or meetings? What are some of the philosophies that you've carried with you?

Dominique 22:31
At Atlassian, we're passionate about dogfooding and using our own tools, so Confluence is lifeblood. We don't really send a lot of emails. The emails that I get come from people outside of Atlassian or they're HR or IT like, ‘don't click that button’ type thing.

Everything is done through Slack or Confluence. Anything that would have been an email in a different company is a Confluence page or space and so what you were saying about modes of communication in a lot of ways, if it's not in Confluence, it doesn't exist. If it's not a page that people can access. Open company and no BS is one of our Atlassian values and so that means that we're sharing and we have open documentation and we also have a very strong culture of blogging.

When we're sharing our wins or, “Hey, be on the lookout for this” or, “Hey, we're running this program or this experiment” or, “We're looking for people,” a lot of that is in a blog in Confluence. So people from marketing, from finance, from engineering are looking at all the blogs and you can see what's happening.

Again, you want to learn from other people. I am a big fan of stealing. From an operational perspective, you should not be creating everything from scratch. It's a waste of time.

Caro 24:09
It absolutely is. You just exactly put the nail in the head of why I made Opsy. I'm like, so many of us are recreating the wheel, when it's like… let's just share what we're working on. Let me save you the first three steps and then you can put your own spin on it! I love that.

It's funny, I used Confluence on my last job religiously, but it's not… Everyone talks about Notion and all these other like Google Docs and whatever and I'm like, "My brain still thinks in JIRA stories and it still thinks in Confluence pages. That's been a shift I’ve had to make, but part of me is still like… No, I got so used to that. I need it back. I need it back in my life! But I digress.

All of this communication, you're talking about all these pages and Confluence, all these blogs, what has been your experience with people reading them and with overload of information? Do you have best practices for that? Tell me about your experience.

Dominique 24:55
I would love for someone to give me the solution to that problem. We are now at close to 9,000 people, or maybe 8,000 people. We're going to grow continuously as a company and so creating blogs and pages left or right, everything, it gets lost.

You see a thing, you read a thing. It's like, “I know I read that.” I don't know where I read it. It's in my brain somewhere. It's in my brain!

And from a design perspective, if the same thing happens when you're talking about reinventing the wheel, there are pain points that happen across all the teams, right? I can't even tell you how many different teams or pods that we have down to the feature level up to triads and squads.

Each of those teams is producing information and also sharing out things and when there's a pain point or a workshop or something that a designer solves for and they’re like, "Hey, I want to share this out so people can benefit from it." And they're like, "Hey, here's a blog about what we did. Here's how you might do it." And people read it because we share it in Slack. Then they're like, "I'm going to use that next time that comes up."

A month later, it comes up and you're like, "I don't remember where that was. I don't remember the name of the blog. I can't find it." Then the time it takes to remember all of those things, you're like, "Well, I could have just built it myself."

So, my team right now, my design ops team is called Design Hub. The reason for that is because we want to be the centralized place for design practices, tools, templates, standards, resources.

Caro 26:47
So, no big deal, quick and easy task.

Dominique 26:50
Exactly. Right now, we're building out the hub itself, where a designer could go for those templates, best practices, tools.

In all of that, that content is coming from the designers. It's like, "Hey, you made this thing. How can we refine it so other people can use it too?" Because what you get is, let's say 15 different teams have the same problem. They don't have any visibility into that because they're working in different spaces, on different products, and so they create something, but they only have enough time and space and bandwidth to go from zero to 15 in fidelity, like 15%.

It's like, this is good enough, it gets me where I want to go, and so you have the 15 different things that go from zero to 15. No one, because they don't have access to it or visibility or they can't find it or they didn't know it existed, takes it from 15% to 50% or 50% to 75% and makes it the best it could be.

That's what we want to do. It's like introducing... Yes, I said stealing, but really what I'm talking about is remixing. Taking something that existed and making it new. Sometimes a remix is better, many times.

Anyway, I digress. But taking it and improving, actually using the design process, constant iteration to improve a template, a way of working a framework, testing it out. That's one of the ways that we're trying to mitigate that information access tool overload.

We're also synthesizing newsletters like, hey, here are the things that are happening around the org, here are some things that you definitely want to check out if you missed it, so going back to that communication piece. It's the communication and it's also the access to the information.

Caro 28:45
Yeah, figuring out how to bubble up the most important things and make sure people see them more than once.

Switching gears a little bit, what advice would you give to someone who wants to do this kind of work?

Dominique 28:57
There are a lot of great communities out there. One of them is a DesignOps Assembly, which is founded by Meredith Black and some others. It has a robust community of design operations practitioners across the world. I think there are 5,000 people in the Slack community.

Caro 29:12
I've heard great things about it.

Dominique 29:13
We have monthly events where we're sharing out and doing panels and talks and discussions.

We just wrapped out our first cohort of Design Ops Learning Labs. So, essentially, a 12-week mentoring or learning circle. We broke it out by like, if you’re new to design ops and want to learn all the things, then you start in the beginning of design operations — people practices and platforms, or systems, tools, etc. in the beginning — all the way up to an established leader’s [track].

I was one of the learning labs professors for established leaders. We just kicked off the summer cohort I think last week, and so we'll be running that. If you're interested in learning more about design ops or building community in design ops, definitely check out DesignOps Assembly.

There's also a large community that is driven by Rosenfeld Media, who runs the DesignOps Summit. That's an annual summit. They are a lot of really smart people. It's not just the design ops practitioners' people with design ops as their title, but it's also design leaders, it's designers. Because like I said, design ops happens whether or not you have that in your title.

Caro 30:36
You’ve got to break out of the silos and work [together]. Absolutely.

Dominique 30:40
Exactly. There are a lot of resources. There are a lot of blogs. There are a lot of really smart people.

Caro 30:46
That's awesome. On the flip side, what are you working on this year that you'd like advice on? What are you trying to learn or get better at?

Dominique 30:54
I need to write more. It has been a [goal for] probably three to five years, a ‘something that I need to do more of’ thing that's always in the back of my head.

In my last performance review, that was one of the things that… not necessarily my review, but my peer feedback was like, “We need you to write more like.” Because I talk, but that only gets to the people who were in the meeting. And I do a lot of external talks and things about design operations, like thought leadership. But, internally, it's something that I need to do a little bit more of. That is my growth area. But also, finding the time to just write about something that is not a project that is actively being worked on, or a pain point that I'm highlighting, or a strategy… it’s finding that time.

Caro 31:57
I will say, you just said something I've learned. Because I've had this struggle too, where I'm like, “I need to write more. I need to share more.” You said ‘finding time to write about something that's not like an active pain point.’ One of my workarounds has been to start writing about things as I'm working on them. I hate a blank document and so I've been able to go back in and… I have stuff that I can start with. I started writing out, here's what the pain point, here's what the thing is. So I feel like we all have to find our process.

Again, one of the reasons why I started this podcast is because I think it's so much easier for us, as ops people, to just talk, to not have to… I think you obviously are more out there externally with your talks and podcasts and stuff, but, for so many of us, it's hard to get from behind the scenes where we naturally are.

So, this is actually a great segue to our last section of this episode, which is what I call the brag book. It can be hard to show off your work as an ops person, at least in a concrete way that non-operations people get, or people outside of your org [can understand], so this is your time to show off.

I want to dig into an ops project that you're proud of, or one you recently had. I can give you a second to think about it, if you need it.

Dominique 33:03
There are so many things I'm proud of and a lot of it is work in progress. The thing that my team and I are personally working on right now is really solidifying our three-year strategy for design operations. How do we scale to support this massive scale that we're going to bring out?

Caro 33:26
Three years, that’s a very long timeline.

Dominique 33:30
It's funny because [for the] next year, it's like… I can pretty much predict where this needs to be. So, where the headcount needs to be, what we're going to focus on. The second year, I can see about halfway through and the third year, it's… shrug.

I don't know where all of these people are going to be, what the needs are going to be, what the pain points are going to be. You can really create problems when you say these are the problems of today and these… It's probably true that these are going to be the problems of tomorrow. But what we do know is that the solutions of today aren't going to be the problems of tomorrow. We're already creating, just like the things that we're solving today, solutions that we had two or three years ago. It's one of those things about being proactive around if this is what we're designing today, what are the possible pain points that could arise from this? That's what I'm thinking about.

But as far as bragging, I think for me, and this may not be as exciting, I'm super, super proud of the relationships and the trust that I have between myself and the other design leaders at Atlassian. They're some of the smartest people I've worked with and I feel really privileged to be their peer and be able to collaborate with them, and also to have earned their trust and for them to believe in the impact and value of design operations for them to then say, "Hey, I know that design ops will be a multiplier for my team and for the design org at large. Here is a headcount." I have five open roles. All five of them came from those conversations, which is when I'm talking to peers and people who are those design ops teams, one or very small design ops teams, that is one of the pain points that they experienced over and over again, and the questions that, if you do a quick search on design ops, I would say probably five out of 10, or five out of 20 blog posts will be about building a case for design operations or building a case to invest in and fund it. Unfortunately, I haven't had to build a case for it. In some cases, I've had to pump the brakes and say, hey…

You don't want to throw bodies at the problem because you then create more problems. And so, I'm really mindful about intentional growth and rethinking what we mean when we use the word scale. Because when people say scale, they often just mean more. That is one of the components of scale, but it's also about breadth and depth and mindfulness and intentionality. So, when we are thinking about how we grow as an org, there is no reason that, a year from now, my team should be 50 people.

Now, if you're trying to work to design ops ratios where many design ops teams that are my design org's size and even smaller, they're working towards a ratio of 1:10. With a six-person team, that is absolutely not the ratio that we have. But growing at that high of a rate, just to get to the right ratio, will cause way more problems. It won't serve design ops as a function, it won't serve the design teams, and it certainly won't serve the individuals.

The thing that I'm proud of is being able to partner with my peers and having a great manager and great partner in my managers. Also, Robert Dietz who is the other head of design…

We don't have a centralized global head of design so we have these twin roles and we operate as this trifecta. They're great partners. They're super supportive, especially Zack who is always like, "How do we make sure we're bringing people along the way and we're doing this intentionally?" And really thinking about the robustness of design operations. It's not just about shipping work. It's about enabling effective and efficient design teams and building a sustainable design org.

We were saying, about the people thing… There's a reason that, when we talk about design ops, the first thing we say is people. People, process, systems or people, practices and systems and tools, it's all of those things. There's the scaffolding.

My team is doing a great job in partnering with those leaders and in thinking about that, especially from a people perspective like how do we help people grow? So I'm really proud of that.

Caro 39:35
I love that. That was such a great, all-encompassing deep dive into really some of the biggest problems. You're tackling and approaching both individually as part of the team and the larger design work, so thanks for digging into that and for coming on the show today. I really enjoyed learning more about you and design ops.

Dominique 39:56
Well, I hope that people actually have an understanding of what design ops is. Sometimes I'm like, "Do they know? Or did I just say all the things?" It's all the things.

Caro 40:07
I think to some degree, it is all the things. But you also gave a couple of really good definitions.

Dominique 40:14
I will say that I, and this sometimes bites me, that my philosophy about design operations is that designers should focus on design, design managers should focus on managing the designers and the work and moving that along, and then design ops handles everything else.

Caro 40:33
That's great. See? You're just slipping in there at the end of the episode, another little nugget.

Dominique 40:39
But everything else is big.

Caro 40:41
Yeah, it is big. It is really big. That's ops in general, it's big. And that's why we have all these specialties and focuses and systems so that we can tackle these big problems and solve them for the people.

So, yes, I think this is a great crash course intro to design ops and you've also given us some extra resources as well for people who want to learn more. Thanks again for coming on Opsy. And everybody, make sure to check out Dominique online and follow all the writing she's going to do in her work. [laughs]

Dominique 41:13
Man, now you've publicly committed me.

Caro 41:16
Yeah, I have. Accountability. Well, I'll follow up with you in a couple of months to see how you're doing. [laughs]

Dominique 41:20
All right.

Caro 41:21
All right, thanks.

Dominique 41:22
Thank you so much for having me.

Thanks for listening to Opsy. You can find resources and links from this episode in the show notes at Opsy.work. And, while you're there, I hope you'll take a second to join our free community where we share resources and opportunities that help us all level up in our ops careers. Again, that link is Opsy.work. Until next time, stay opsy, friends.