Integrating, Scaling & Maintaining DesignOps

Baylie Brenner-Bruzgis at UXDX USA. Video: https://www.youtube.com/watch?v=ygS8SF_Ent4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and disclaimer

[00:00:00] Hello, welcome. I am Baylie Brenner-Bruzgis, and today we'll be talking about integrating, scaling and maintaining DesignOps. By way of introduction, I am now head of design operations at Twitch. I was formerly at Disney Streaming, where I was head of design operations, and before that at JPMorgan Chase as head of design program management.

[00:00:24] A little bit of a disclaimer about this talk: these are my experiences, my opinions, things that I've run into or heard about or witnessed. It does not have to be everybody's experience, and by no means do I suggest that every place is like this or that everyone will have the same experiences. Also, this talk is a little bit different from most. I think most design operations talks go into the what: what you should be doing, when you should be doing it, building the practice, things to look for. This is a little bit more about how you do a lot of that work, and what I mean by that I will get into in just a moment.

Interviewing: know yourself, and interview the boss

[00:01:06] The beginning. I start at the beginning, with interviewing. This is actually before you get hired, so it's a little bit different to begin with. When interviewing, my suggestion is to know yourself: know your value proposition, know what you bring to design operations, what type of design operations leader you want to be, what type of work you want to be doing, and whether that company aligns with it. But really, do the role and the boss align with those values, with what you want to be doing, but also with how you're going to do it? The value proposition alignment is really important, not just for the company but for the role. Will that align with your goals?

[00:01:53] And the boss: be sure that you're interviewing the boss too. I find that often any human being gets so excited to be interviewing for a role that sometimes they forget to be interviewing the people that they'll be working for, and interviewing that company. That's really important. Again, it's just a little reminder to people. I ran into this myself before I landed where I am at Twitch right now, and I learned that along the way. I had turned down some roles because of some of the things I'll be sharing in a moment. I had turned down even interviewing because of those same principles.

[00:02:32] But I was also rejected, and looking back, again based on what I'll be sharing, it was really rejection as protection, because I wasn't really thinking hard about the person I would be working for, and what the role definition combined with the boss, when put together, was actually going to mean in practical application. It's just really important to think about all of those things, not just "I really want to go work for this company, and I'm really excited about becoming a design operations professional or leader."

What to look for: reporting line, partnership, readiness to invest

[00:03:03] So what to look for. As mentioned, I think you should always be looking at where you are in the hierarchical structure. Reporting directly to an EVP or higher is important. I have seen roles where they're buried. I don't know that it's been successful for a lot of people; it possibly has. Being layered under design systems sometimes, instead of the reverse of that, I don't know how that works. But in my own experience, I think it's important to report directly to the head of design, or if it's the head of customer experience.

[00:03:39] I should add another disclaimer: when I say head of design or design team or anything like that, I'm referring to whatever your team structure might be. You might be in a stage of scaling or maturing where a CPO, a product officer, covers all of design as well. Whatever it is, it's just your team and whoever your leadership is. Reporting directly to that head of is really important, in my opinion. It'll reflect on you. Just tactically, you are responsible for the entire team, just like that human, therefore you should be aligned with at least their leadership structure, because you're meeting with everybody. They're all your constituents.

[00:04:22] Also, the next bullet, around being a strategic partner. You want to be interviewing with someone who looks at this role as a strategic partner. You're either a key collaborator on anything going on on the team, or a proxy for big decisions or any of the leadership projects or programs going forward. That's really important, those types of words: strategic partner, key collaborator, proxy.

[00:04:50] A boss that is ready for DesignOps, which goes hand in hand with building or bolstering the team, or providing head count. I actually did hear this from my boss now at Twitch: that they were ready, in that they knew or recognized the need for the type of skill set or work that I would be bringing to the team, recognized that the team would be better for it, and that it was part of scaling and maturing the organization. The inverse of that, I guess, would be teams that are thinking less about maturing and scaling and what the future looks like, and more about problems and putting out fires, being very reactionary, I would say.

[00:05:39] And then building or bolstering the team. This does not have to be the case. Small teams may not require a giant DesignOps team, and maybe it's just you for a long time. But I think the investment is important. One way or another, feeling an investment in DesignOps, both in terms of being ready to do it and ready to invest in design operations, is really important to look for when you're interviewing.

Red flags when interviewing

[00:06:03] And beware. Things I have mentioned: the very junior title. This does not always have to be the case; this is what I have witnessed. Sometimes it's really difficult in a large organization to move up the ladder if it's recognized right away that they underestimated what they were going to need in terms of your scope and role, and that you should be in a leadership position or title. They can't always just change that easily. So it's something to look for on that tactical end.

[00:06:34] But also, in terms of people and relationships, a very junior title can mean that the boss or the hiring manager or that team is just looking for someone who's going to see their vision through, execute against their vision. That might not be a bad thing necessarily, but for what my value proposition was, I need to be able to come in and have my own opinions around what the team might need, and protect the team's needs, and therefore help develop the vision instead of just executing the vision. Everything's a partnership, but you want to have a certain amount of autonomy around what your team will be doing.

[00:07:17] And then undermining, of course, can be a challenge. People have the best intentions; they might even know that they're doing it. But if you're at a certain level, you just may be undermined, or not invited to the right meetings, and that's just a challenge. So I'm here to say it. I know we're not supposed to talk about these things, we're not supposed to care about it, but it is important. It matters.

[00:07:35] Promises of shared resources: this means no investment in your team. If you're a very large design org, or whatever your team structure is, if it's very large, not being able to build out the DesignOps practice can be a major challenge. And if you're sharing resources in the form of "a designer who's just really passionate about process," that's so great, it's so important, and we'll talk more about utilizing that skill set, but up front that's not exactly what will be helpful. You need to be able to build a team if the environment calls for it. If you're constantly promised shared resources, that can be a bit of a challenge. You might not get things done in the time frame you need them in, and it just gets buried.

[00:08:24] A separate program management team, within or outside the team. This is not always a red flag, but it's something to be aware of. If you're within a team and you are owning people, process and tools, it can be challenging to work with a peer or partner who says, "This is the execution of our process," and not be able to lead and drive that yourself. It's not always a problem; I have just seen where it can go a little bit awry.

Getting started: galvanize the team

[00:08:55] Moving through the life cycle of employment: you've interviewed, you've found the ideal place for yourself, and now you're on board. Yay, congratulations, welcome. So what do we do now? Getting started. There are a lot of the typical things that someone would talk about from a DesignOps standpoint, around the lowest risk and work combined with the highest value for the team as things to work on. I'm not really going to talk about that. It's more about the social structure.

[00:09:22] I think the most important thing is to start by galvanizing the team by building relationships, and then that'll build trust. What I mean is: start meeting with folks and getting them excited. That's really important. If from the beginning, as a leader on the team, you are meeting with every single designer in one capacity or another, it shows that you care about them. That's my first rule, rule number one: the design team are your constituents. Those human beings are your constituents, and you have to give a damn about them, pardon the language. You have to care about everyone on the team. You have to be able to give them voice, because to be honest, if they're not on board, nothing that you do or execute will matter. It won't work.

[00:10:05] It might sound obvious, but interview, meet with everyone, take it seriously. If the team's over 50, I know that sounds crazy, but if it's over 50, hold coffee chats or informal meetups, social hours, things like that. And of course have your value prop intro handy, so that it's a really quick, well-oiled machine. Capture everything you hear from them, and we'll get into that in a moment. Thinking about shared resources longer term, this is a good time to start picking up on who the key individuals are, whether they're people who would be part of a strike team or a center of excellence, whatever that might be. Keep an eye out in these meetings; it'll become very obvious.

[00:10:46] I also think it's important to know the mission and vision statement for the team overall, or if that needs to be set and you're being onboarded to help support that, get that set. Start to think through what that might be, but have one for yourself, have one for the DesignOps team, to help implement a workplace style. It's a good way to lead towards the culture of the team. What is the culture like? Think about your work environment with words like "this is a culture of inclusion" or "it's a place where we are inclusive." We want to build comfort for the team, we want to engage with our partners and our peers. Debate is really important, collaborating. These are the kinds of things you want to be able to share as part of your mission and vision and approach, but also as the whole team's workplace or work environment style.

[00:11:37] I think that's sometimes overlooked. Maybe not often; maybe that's just my experience. But it helps you get people on board. Combined with hearing some of their concerns, or what they'd like to keep or kill, you're also getting a sense of what they might be thinking is missing. Maybe it is advocacy or safety; maybe they're just not fully comfortable sharing their work or sharing their feelings. So if you can start to create or foster that, it's really helpful up front, early on.

Keep in touch with leadership, then make more friends

[00:12:05] But while you're doing all this, make sure to keep in touch with leadership. What do I mean by that? First off, meet regularly with your leadership. I'm sure that goes without saying: sharing what you're working on. But I also think it's really important to know what the expectations are for your role. In some places you may be building everything from the ground up, which is perfectly fine; there's no issue in any of that, of course. But you need to understand what was promised. So your job description is really important: what was promised as part of getting you hired or getting this position approved?

[00:12:41] In large organizations it can sometimes take months, if not over a year, to get positions approved. So it's really important to know what the hoops were to get you there. Who did your boss promise what, in terms of the organization, in order to get you hired? For example, "they will build process, they will maintain the FTE planning," things like that, which are really important to prove at the end of the year that you're actually doing. Still, all of your goals, your approach, themes, projects should ladder up to these high-level tenets, values, whatever you might call them. So understand again what those commitments are, and again it can come from your JD, your job description. What were the commitments, and are you actually laddering up or lining up to them?

[00:13:36] And then make more friends: understand the ins and outs of your company. That was within your team, but then get out and meet more folks. I think staying slower in the beginning is really important. You'll get a temperature for the rest of the company. But eventually it's really important to understand how budgeting works, what the info security or infosec requirements are, who your HRBP or people ops folks are, and ensure that there's no issue where you may be going against policy or stepping on toes, things like that. You just want to protect yourself, but also be the grown-up: know all of this information, know those people, so that you can protect your team. Not from the policies, but by making sure they're following policy. You do not want to piss people off, right? We don't want to piss people off; we want everyone to get along.

[00:14:29] It's also important to know people beyond just the few that I've mentioned. You should really get to know your product folks, your engineering folks, all of that, because they'll help give legitimacy. They will help you elevate the design team and your DesignOps practice. So eventually establish the same relationship with all those people that you would with your inner constituents or inner circle.

Red flags early on

[00:14:54] Getting into some bewares, or possible red flags. Early undermining, slash being led astray. Sometimes, again with the best intentions, people really feel strongly about what your priorities should be, and you will go down a rabbit hole completely ignoring the fire behind you. The "this is fine" dog kind of image. "We need a new prototyping tool, that's the most important thing." So interview the team. If that lines up, like, "Yeah, we can't conduct iterative research, we can't get rapid prototyping done because our machine doesn't work, every tool we're using isn't working."

[00:15:39] If that's the case, if you're hearing that, then okay, fine. But if you're not hearing it, whatever it might be that you're being asked to look into early on, prioritize accordingly. And then, as mentioned a few times, resource constraints: getting an over-commitment of supporting folks instead of an investment to hire. Just make sure you can, one, advocate for the resources that you think you need, but also understand the resourcing of the folks that you're being lent or can borrow. It's really important to keep that in mind. Be very transparent in terms of your needs for their capacity. That will help long term; I think that's a good mitigation method.

[00:16:26] And then of course, as mentioned, make the relationships with the right people in leadership from the start. They should understand the needs of the team already. There should be a little bit of alignment between what you hear in all of your interviews or coffee chats, combined with what their roadmap for you might be, or the key areas of focus that they wanted you to run with. It's just good to maintain that relationship and understand who your people are, and those are the ones that I would cross-check with.

Working sustainably: building blocks before culture

[00:16:57] Working sustainably: this is basically everything else. You've gotten to a point where you know what your themes are and what the most important things to do are. Personally, I think the word culture comes up all the time. They want design operations to build culture, to create the culture, to give a sense of culture and belonging, all of these things. I find that it's so important, but I think culture is actually the sum of all of its parts. Meaning, building blocks, foundational elements, are the most important things to do first, to build that sustainable practice that will scale. Then you get into, not that culture is the fun part or the icing on the cake, but then you can get into some of the other activities that people are more likely to latch onto.

[00:17:45] As I've already said, a great workplace or environment or culture starts with knowing what you're supposed to be doing and how to do it. Getting into the what a little bit, that speaks to building process that is meaningful and sustainable for your team. That goes into resourcing and understanding the work that we do, prioritizing, building intake structures and tracking, and training on methods. It's a lot of really important work, and usually that's one of the first things that you should prioritize. But you need to know who the people are, you need to know where to find the stuff, and you need to know what you're doing. That's from the bottom up.

[00:18:30] This is pretty standard, but create themes to build your roadmap based on your chats with all sorts of folks. Start to bring together themes: what was repeated the most? You can do your own little workshop by yourself, or if you have a team at that point, dot voting on what you think is the most important or most frequently talked about. Cross-check that with your leadership structure, make sure that they're on board, that they agree with the sequencing of your roadmap, all of those things, that you have funding to get all that done, that you have the right resources.

[00:19:04] One other point I'd like to make: sometimes it can be intimidating to share back. Maybe not for everybody. But you should not be afraid to share areas that have not come up that you do think are important or would add value to the team. Because sometimes it's just scar tissue: they're so accustomed to working around something or working with something that they've just forgotten about it, and that the workarounds don't have to be there. So don't be afraid to share that, or thread your own ideas throughout the themes.

Be the roux, and stay credible

[00:19:38] Then over time, getting a little bit more mature in your practice and having built it out, again have your value prop, your elevator speech, and be able to share what you're doing. I think that's also really important for top-down buy-in: being able to share with any leadership across your company, or outside of your company, or new hires, what the value of design operations is and what value you're bringing to the team.

[00:20:04] And I wanted to say: design operations, think about yourself as the roux, not the seasoning. Seasoning is great; it brings a dish together. But roux is something where you don't even know it's there, and it has created the entire dish. It's such simple ingredients that are so important. They're simple, but require so much finesse and intelligence and practice. Roux is so important. It's unseen, and it's the base of everything. I think of DesignOps that way. Maybe other people don't, but it's what I think.

[00:20:42] Be credible and consistent with your team, within your team. Overall, documentation is really important. I tend to overkill on documentation. Bullets are fine, but something to say, "This is what we're doing, this is why we're doing it, and this is the plan." Memorializing conversations, things like that, storing it in a place that's accessible for other folks, having your list of priorities available. It's important to have rigor and stick to it. You can always retro and revise how you're doing it, but stick to it. And mean what you say and say what you mean. I think that goes without saying, but it's really important in order to stay credible with your team. Don't disappear. Show them, lead by example, remain around and visible, and continue to amplify and support the team.

[00:21:36] And remain credible with your leadership too. Deliver what you're saying. If you don't think you can do something, be realistic, share, provide updates. And I think being inquisitive is important with leadership. Asking questions does not mean you are questioning people. It's okay to ask why they want you to prioritize something, or why something was done, for historical context. It's just important to continue to do that and build, moving yourself within the team.

Finding help and staying lean

[00:22:07] Finding help while staying lean. As mentioned earlier, that whole idea of shared resources maybe can't last forever, but this is actually a good point at which you can begin to use internal resources. Hopefully you are building a team, and you understand what you need at that point. Perhaps you need to lean in on program management. Perhaps it's more on the ops side, and we need people who will be able to create a sense of engagement through routines and rituals, who will manage all of the overarching dashboards, team health, team sentiment, things like that. Just think about what the most critical needs of the organization are, and what kind of partnerships you have outside of the organization, before you start to fill out job reqs.

[00:22:54] But again, you can use folks from within at this point, or leverage internal resources on design, or design research, UX writing or copywriting, whoever is in that team makeup. This is the point where you know what you're doing, you have a roadmap, so you can give people very clear boundaries in terms of what they'll need to do. It also helps with the ongoing people who will be the early adopters, people who will be a cohort of DesignOps excellence or process excellence, things like that, where you'll have plants, basically, in meetings: someone who will ask questions or will present at the drop of a hat. Those are the people you want to identify really early on and leverage over and over again.

Being the voice of the team

[00:23:43] Being the voice of the team. It's probably just organic; it happens. But escalate concerns. If you are hearing a lot of challenges, or there are opportunities to fix things or get ahead of risk on your team, just escalate it. Just talk to your VP or whoever you're reporting into. That would be who I would talk to first, of course, before going to HR or anyone else. But if you're sensing it, if you're feeling it, and your designers, or whatever the team makeup is, are suffering for it, it will escalate at some point. You might as well just get ahead of it. So don't be afraid of that. Be the voice of the team.

[00:24:24] But also, issues aside, amplify the people on the team. In my role I get asked all the time to lead or participate in guilds, or anything related to diversity, equity and inclusion, joining certain conferences like AfroTech and Grace Hopper. I love nothing more; it is an honor to be there. But there are probably people on your team, on the broader design team, who are also very interested, and it would be great for them to build out their career, and they're the right makeup. Those are the people who should be in those places. Amplify those voices, get them at it. What does it hurt to volunteer other people who could be amazing in your place? Or not even in your place: it could be just saying, "Hey, I think this person should be a part of the DEI council."

Nothing is ever final

[00:25:17] And then consistent feedback loops, which brings me to: nothing is ever final. Be able to share surveys and ask for feedback, share a newsletter and ask for feedback. However you can, always ask for feedback on anything that you've launched. Really important. Or on anything that's missing: have you not done this yet, do they see a gap somewhere? Just always check in with the team. I mean, always be learning. ABL doesn't exist, but always be learning. If there's a new tool, if there's something changing within the organization, just have that ear out for any of those possible changes that would affect your practice that you might want to take into consideration.

[00:26:00] Within the team itself, if there is a shift in location, or people spending more time with their cameras off, just be very aware, and always be thinking about how you might be able to shift what you do to address the needs of the team better. Retros, of course, are always important. Do a survey, or actually hold a formal retro, and the cadence you'll have to decide yourself. We recently launched our internal onboarding materials, welcome materials, and while we're getting great feedback, I want to wait and do a whole cohort retro of new folks who not only started recently, but started over the last two-plus years in the pandemic. What are we missing? What else can we do? I just think they're important at the right time.

[00:26:50] Everything should be living and breathing. As you have new people, or you're scaling the team, things can shift and change, or you can have new ideas coming out. So nothing has to be final. If it's not working, fix it. If it's working fine, then maybe you don't need to; maybe it's just about maturing it and making it even better.

Final red flags: reorgs, copycats and "that's my job"

[00:27:10] So with that, some final possible red flags. These are soft red flags that might never happen to you, or they might not affect you at all. Major or multiple reorganizations may be a sign of times to come. I would just be careful, again: know your value prop, ladder all of your goals up to what was promised. All of this comes back together. What was HR promised? To me that's my guiding principle: HR was promised the following bullets, and recruiting was promised [?] the following, and I need to make sure I'm actually doing that. In the event of a lot of reorganizations outside of your team, or that impact your team, it's just always good to be able to show what DesignOps does to folks who may not really be aware of it.

[00:28:03] Copycat syndrome, or "that's my job" syndrome. Copycat syndrome is actually not a bad thing. This is when another team hears that you're working on end-to-end process and you're building a whole playbook out, and then all of a sudden they are doing it, and theirs actually encompasses all of your work, and therefore you should really just join in with them. This can come in the form of copycat activities, which again is okay; it's flattery, right? Or it could be an agile transformation, or "we want to follow this model of squads," and you might not get people who really understand design process.

[00:28:46] That's why I believe... we'll get to that. "That's my job" syndrome can happen within your team or outside of your team. This is not a hard and fast rule, but you might be really struggling with a change that's been made, with people not adapting to those roles and responsibilities, or just not adept at change, and they feel like that's their job. Or even your own job: you can be doing something, and you were hired to do it, but someone else on the team, or maybe a design manager, just really feels strongly that resourcing and program management overall is their job, and you should not have any place in it. That requires a little bit more finesse and more conversations. Personally, I don't start holy wars over something that's not significant enough, and I think you'll know the difference when you're in that seat. So just be your own red flag. Be wary of starting holy wars that you don't need to be a part of. There's plenty of work to go around.

Show them what you're made of

[00:29:46] Some mitigation methods; that was one of them. But show people what you're made of, show them your stuff. Make sure you're sharing out the work that you're doing. It doesn't have to be the end product, it doesn't have to be beautiful, but give updates both to your team and outside of your team, making sure people are aware of what's going on. Then show them what you're made of. You are the roux; you are what is holding all this together and making it the most fantastic meal anybody has ever had. You need to be able to prove that.

[00:30:16] So again, the share-outs, the relationship building, all of that comes together into showing what you're made of. Show people your final product, show them what you bring to the table and what your team has accomplished. That'll help you in the future to continue down that road of making improvements or making updates, to help scale. So with that, I just want to thank everybody for listening. I'm always available for any comments or questions if you want to reach out to me here at the conference or on LinkedIn. I'm all yours, I'm around. It was a pleasure talking to you today, and I look forward to hearing everyone's success stories.