Integrating, Scaling & Maintaining DesignOps

Hello, welcome, I am Baylie Brenner-Bruzgis. And today we'll be talking about integrating, scaling, and maintaining design ops. So by way of introduction, I am now head of design operations at Twitch, I'm formerly of Disney streaming, where I was head of design operations there. And then before that at JPMorgan Chase as head of design, and program management, a little bit of disclaimer about this talk, these are my experiences, my opinions, things that I've run into, or I've 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 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 kind of the what like what you should be doing, when you should be doing it, building the practice sort of 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 won't get into in just a moment.

So the beginning, I started at the beginning of interviews, actually, this is before we get hired, because it's a little bit different to begin with. So when interviewing, my suggestion is to know yourself, know your value proposition and know what you bring for design operations, what type of design operations leader you want to be, what type of work you want to be doing, and does that company align with it, but really does the role. And then the boss aligns with those values, the what you want to be doing, but also 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, 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, that's really important. I ran into this myself. So before I landed, we're on Twitch right now. And I kind of 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, but then also was rejected. And looking back again, based on what I'll be sharing, it was really rejection as protection, because it 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 applications.

So it's just really important to think about all of those things, not just because I really want to go work for this company. And I'm really excited about becoming a design operations professional or leader. So what to look for, as mentioned, I think you should always be looking for where you are in the hierarchy or hierarchical structure, reporting directly to a VP or higher is important. I have seen meetings where they're kind of buried, I don't know that it's been successful for a lot of people.

But 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 head of customer experience. And I should add another disclaimer that when I say I had a design team or design team or anything like that I'm referring to whenever your team structure might be, you might be in the stage of scaling or maturing where CPO or a product officer covers all of design as well. But 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.

Also, the next bullet around strategic partnership or being a strategic partner, so you want to be interviewing for someone who looks at this role as a strategic partner. You're either a key collaborator on anything going on the team or a proxy for big decisions or any of the leadership projects or programs going forward. So it's really important those types of words: strategic partner, key collaborator proxy, a boss that is ready, ready for design, which kind of goes hand in hand with building or bolstering the team or providing headcount. So 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 and recognized that the team would be better for it. And then it was part of scaling and maturing the organization. So they're the inverse, I guess of that would be teams that are kind of thinking about, well, less about maturing and scaling what the future looks like and more about thinking about problems and putting out fires and being very reactionary, I would say and then building or bolstering the team, this does not have to be the case, small teams may not require a giant design ops team.

And maybe it's just you for a long time. But I think that the investment is important. So one way or another feeling an investment in design ops, both in terms of like, ready to do it, and also ready to invest in design and operations, is really important to look for when you're interviewing. And beware. So things I have mentioned, very junior title. So 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 actually, they underestimated what they were going to need in terms of your scope and role and that you shouldn't be in a leadership position or title can always just change that easily. So it's something to look for on that tactical end.

But also in terms of like people and relationships, a very junior title just 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, and 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, I would 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.

And then undermining, of course, can be a challenge, people have the best intentions, and I don't 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, right? We're not supposed to care about it. But it is important, it matters, promises of shared resources. This means no investment in your team, if you're a very large designer, or whatever your team structure is, if it's very large, to not be able to build out the design ops practice can be a major challenge. And if you're sharing resources in the form of a designer, she's really passionate about the process.

That's so great, it's so important. And we'll talk more about utilizing that skill set. But upfront, that's not exactly what will be helpful. You need to be able to build a team if the environment calls for it. And if you're constantly promised shared resources, that can be a bit of a challenge, just you might not get things done in the timeframe you need them in. And it just gets a very separate program management team within or outside the team.

So this is not always the case as a red flag or something to be aware of. But if you're within a team, and you are owning people's processes and tools, it can be challenging to work with a peer or partner to say this is the execution of our process and not be able to kind of lead and drive that yourself. It's not always a problem, I just have seen where it can go a little bit Ru.

So moving through the lifecycle of employment you've interviewed, you've found the ideal place for yourself. And now you're on board. Congratulations, welcome. So what do we do now, getting started, there's a lot of the typical things that someone were talking about from the design ops standpoint around like, the lowest risk and work combined with the highest value for the team as things to work on. Not really going to talk about that. It's more about the social structure. So I think the most important thing is to start by galvanizing the team by building relationships, and then it'll build trust. What I mean is start meeting with folks and getting them excited, really important.

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. And that's really important. That's my first rule. Rule number one, the design team are your constituents. So as human beings are your constituents and you have to give a shit about them, Pardon the language. You have to care about everyone on the team. You have to be able to give them a voice because, to be honest, If they're not on board, nothing that you do or execute will matter, it won't work.

So it might sound obvious but interview meetings with everyone take it seriously, 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 then, of course, have your value profit in show handy so that it's just like a really quick well oiled machine, capturing everything you hear from them. And we'll get into that in a moment. But this is a good place. Thinking about shared resources, longer term, this is a good time to start picking up on who the key individuals are, whether there are people who will be part of a strike team or a center of excellence, wherever that might be, keep an eye out in these meetings.

So it'll become very obvious. I also think it's important to obviously know the mission and vision statement for the team overall. Or if that needs to be set, and you're being on boarded to help support that, get that set, start to think through what that might be, people have one for yourself, have one for the design ops team to help implement a workplace style. And it's a good way to lead towards the culture of the team, what is the culture like? So thinking about your work environment with words like this is a culture of inclusion, or it's the 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 a part of your mission and vision, and approach.

But also, the whole team's kind of workplace or work environment style. I think that's sometimes overlooked, maybe not often, and maybe that's just my experience, but it helps get people combined with hearing some of their concerns or what they'd like to keep or kill, you're also getting a sense for what they might be thinking is missing, which maybe it is advocacy or safety, maybe it's just, they're not fully comfortable sharing their work or sharing their feelings. So if you can start to kind of create that, or foster that it's really helpful upfront early on.

But while you're doing all of this, make sure to keep in touch with leadership. And what do I mean by that just, 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 a part of getting you hired or getting this position approved. In large organizations, sometimes it can 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, and what did your boss promise in terms of the organization in order to get you hired. So this is like, they will build process, they will maintain the FTE planning, things like that, that are really important to prove at the end of the year that you're actually doing that still all of your goals, your approach things, themes, projects, should ladder up to these high level tenants values, whatever you might call them. So understanding again, what those commitments are. And again, you can come from your GD, your job description, what were the commitments, and are you actually laddering up or lining up to that?

And then make more friends and understand the ins and outs of your company. So this is within your team. But then, kind of getting out and meeting more folks. I think staying in Florida, in the beginning, is really important. You'll get a temperature from the rest of the company. But eventually, it's really important to understand how budgeting works, what info security or InfoSec requirements there are, who your HRBP or people ops folks are, and ensuring that there is no issue where you may be going against policy or stepping on toes, things like that

You just want to kind of 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 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. It's also important to know these 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 design ops practice.

So just kind of establishing the same relationship eventually with all those people that you work with your inner constituents or inner circle. So getting into some beware or possible red flags. really undermining slash being led astray. Sometimes, again, with best intentions, people who feel strongly about what your priorities should be, and you will go down a rabbit hole completely ignoring the fire behind you, the dog, it's a fine dog kind of image, we need a new prototyping tool, that's the most important thing. So interviewing the team: we over-commitment can't conduct iterative research, we can't get rapid prototyping done, because our machine doesn't work, and whatever tool you're using isn't working. If that's the case, you're hearing that being okay, fine. But if you're not hearing, whatever, 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. So just getting over commitment of supporting folks, instead of getting 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 you 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. 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, and 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 want you to hone in on. It's good to maintain that relationship and understand who your people are. And those are the ones that I would cross-check with.

So working sustainably is basically everything else, we've kind of gotten to a point where you know what your themes are, what the most important things to do are some now, personally, I think the word culture comes up all the time. They want to design operations, to build culture, to create the culture, to get a sense of culture, belonging, all of these things. And I find that's it's so important, but I think that that's 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 get into, no that culture is fun, or the icing on the cake. But then you can get into some of the other activities that people are more likely to latch on to.

So 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. So I mean, that kind of getting into the white a little bit, that speaks to the 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.

So pretty standard, but creating themes to build your roadmap based on your chats with all sorts of folks start to come together or bring together themes, what was repeating most you can do your own little workshop by yourself to kind of or if you have a team at that point, dot voting against what you think is the most important or most frequently talked about, cross checking that with your leadership structure, making sure that they're on board that they agree with the sequencing of your roadmap, all those things that you have funding to get all that done, and that you have the right resources.

One other point I'd like to make is, 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 scar tissue. They're just so accustomed to working around something or working with something and just forgotten about it. And that work arounds don't have to be there. So don't be afraid to share that or to add your own like thread your own ideas throughout the themes.

And then over time getting a little bit more mature in your practice and building it out. Again, have your value prop your elevator speech, be able to share what you're doing. I think that's also really important from that top down buy-in is 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, what value you're bringing into the team.

And I wanted to say design operations, think about yourself as the root, not the seasoning, like seasoning is great, it brings a dish together. But actually, Ru is something that doesn't even know it's there. And it has created the entire dish. And it's such simple ingredients that are so important. And they're simple, but require so much finesse and intelligence and practice and all of that, like a Ru is so important. It's unseen. And it's kind of the base of everything. And I think of design ops that maybe other people don't, but it's kind of what I think.

They are incredible and consistent with your team within your team. Just overall documentation is really important. You don't need to, I tend to overkill documentation. Bullets are fine, but something to say this is what we're doing. This is why we're doing it. 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. That's important. Having rigor and sticking to rigor, you can always retro and revise how you're doing it. But sticking to activeness is important and mean what you say and say what you mean, I think that goes without saying. But it's really important to, in order to stay credible with your team don't disappear, show them to lead by example, remain around and visible, and continue to amplify and support the team.

And remain credible with your leadership to deliver what you're saying, well, if you don't think you can do something, be realistic, share, provide updates. And then 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 your leaving yourself within the team.

Finding help but staying lean, as mentioned earlier, that whole idea of shared resources maybe can't last forever. But this actually is a good point in 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 app side. And you need people who will be able to create a sense of engagement through routines and rituals, who will manage all of the kind of overarching dashboards, team health, team sentiment, things like that.

Just think about what the most critical needs are of the organization and what kind of partnerships you have outside of the organization before you start to fill out job racks. But again, you can use folks from within this point or leverage internal resources on the design, whatever, again, design research, UX writing, or copywriting, whoever is on the 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 don't need to do.

But it also helps with like ongoing people who will be the early adopters, people who will be a like a cohort of design ops excellence or process excellence, things like that, where you'll have like plants, basically, in meetings where someone you know, will ask questions or will present at the drop of a hat, like, those are the people you want to kind of identify really early on and leverage over and over again.

Being the voice of the team. It's probably just organic and happening but escalating 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 any anyone else, but if you're sensing it, if you're feeling it, and your designers are suffering Are you sorry, your whatever the team makeup is they're suffering for it, it will escalate at some point you might as well just get ahead of it

So don't be afraid of being the voice of the team. But also like issues aside, amplifying 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 inclusion, joining certain conferences like Afro Tech 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 like those are the people who should be in those places. Amplify those voices, get them at, it doesn't have to hurt to volunteer other people who could be amazing, and your place on that.

Or not even, you know, in your place, it could be just saying, Hey, I think this person should be a part of the DEI Council. And then consistent feedback loops, which brings me to nothing is ever final. So be able to share surveys, ask for feedback, share a newsletter, and ask for feedback. However, you can always ask for feedback on anything that you've launched that's really important, or anything that's missing, like, have you not done this yet? Do they see a gap in someplace, just always check in with a team, and always be learning? ABL doesn't exist, but it is always learning. If there's a new tool, if there's something changing within the organization, just have that, like, you're out for any of those possible changes, that would affect your practice that you might want to take into consideration.

Within the team itself, if there is kind of 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 it survey or actually hold a formal retro, and the cadence, you'll have to decide yourself. But we recently launched our internal onboarding materials, and welcome materials, and while we're getting great feedback, I want to wait and do kind of 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 be doing?

I just think that they're important at the right time. Everything should be living and breathing. And then as you have new people or you're scaling the team, things can shift and change or you 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 maybe making it even better. So with that, some final possible red flags. These are kind of soft red flags that might not necessarily ever happen to you, or they might not affect you at all, but major or multiple reorganizations may be the sign of time to come.

So I would just be careful about it again, know your value prop lateral of your goals up to what was promised. All of this kind of comes back together. But what HR promised to me, that's like my guiding principles like HR was promised the following bullets and recruiting found me for that, 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 design ops do to folks who may not really be aware of it. Copycat syndrome or that's my job syndrome, the copycat syndrome is actually, it's not a bad thing. And this is when, you know, another team hears that you're working on an end-to-end process and you're building a whole playbook out, and then all of a sudden, they are doing it.

And there's actually encompasses all of your work. And therefore you should really just join in with them. This can come in the form of copycat kinds of activities, and debates flattery, right? Or it can be like Agile transformation, or we want to follow this model of squads, and you might not get people who really understand the design process. That's why I believe we'll get to that. That's my job syndrome that can happen within your team or outside of your team. This is not a hard and fast rule. But if you're really struggling with a change that's been made, and just people not adapting to those roles and responsibilities or just are not adapting to 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.

Some mitigation methods I was one of them, but like showing people what you're made out of showing them your stuff, making 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 up to you, It's to both your team and outside of your team, make sure people are aware of what's going on.

Then show them what you're made of. You are the roux you are holding all this together and making it the most fantastic meal. Anybody who's ever had, you need to be able to prove that right? So, again, the shared house, the relationship building, all of that comes together into showing what you're made of.

So 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 otherwise to help scale.

So with that, I just want to thank everybody for listening. I'm always available for any comments or questions or want you to reach out to me throughout the conference or on LinkedIn. I'm all yours. I'm around.

So it was a pleasure talking to you today. And I look forward to hearing everyone's success stories.