speaker-0: Welcome to the Creative Ops Compass podcast, your navigation system for turning creative chaos into strategic impact. My name is Jesse Krensky. I'm a creative operations consultant and the founder of InFocus Consulting. I help in-house creative teams streamline workflows, improve stakeholder relations, and elevate their role as strategic partners.
speaker-1: You have to have an openness and a trust in allowing for change, for the betterment of a project, for adding the greatest value to the business, and ultimately getting things done in an efficient way that takes the emotional element completely out of it. Focus on those objectives, and that is how a racy will be the most successful.
speaker-0: Today I'm speaking with Alyssa Strel. Alyssa has spent her career building and implementing the processes that most teams know they need, but struggle to make actually work. One of those processes is the RACI framework. If you've been in Creative Ops for any amount of time, you've probably heard of it. Responsible, accountable, consulted, informed. It sounds straightforward, but too often teams create a RACI, they distribute it to stakeholders, and then they watch it fall apart within weeks. People ignore their assigned roles, feedback comes from the wrong people at the wrong time, and the team ends up right back where they started, managing chaos instead of preventing it. Today we're going to talk about why RACES fail and how to make them actually work. We'll talk about why alignment matters more than the framework itself, what to do when your RACES loses traction, and where to start if you've never used one before. If your team has tried RACES and given up, or if you're thinking about trying one for the first time, This conversation will show you how to get it right. Alyssa, thanks for joining me today.
speaker-1: Thank you for having me.
speaker-0: All right, let's get racy. So despite how it sounds, racy's are not the sexiest aspects of creative production, but they are one of the most important. But there can also be a lot of confusion about them. So let's, let's just start with a quick definition. For anybody who's not familiar, a racy is basically a way to get everyone on the same page about who owns what part of a project, right? It clarifies roles and responsibilities. It's an acronym. R stands for responsible, A is for accountable, C is for consulted, and I is for informed. It sounds simple, but that's a little deceptive. So let's take this apart here. I find that a lot of failures start with the basics. People can think that they understand what the letters mean and what they're for, but they're working with different understandings or definitions of them, right? So let's just start with the first two, responsible versus accountable. How do you explain the distinction between those two?
speaker-1: Yes, so excellent introduction. think understanding the acronym itself can inherently be where things break down. it is really important that everyone understands what each of the letters not only represent, but also what they mean and what they mean to the people in a particular organization. I would say the R, which stands for responsible, is the team or people or person doing the work, this is the person executing, this is the person who is putting pen to paper. So that's R in my mind. And then the A, which I would say the R and the A are pretty much the top of the totem pole, they're the ones with the most responsibility in this acronym. A, the accountable team or person is the one or team who has final say on a given project. have the final approval. They are the one who ensures that whatever the project is, is meeting the objectives of the initial brief or the campaign or whatever the business objective is of the project that it's assigned to.
speaker-0: And the other part of this other pair that can trip people up is consulted versus informed. in my work, I usually tell clients that consulted means your input shapes the decision, but informed means that you you just need to know what's happening. Where do you you draw the line on that?
speaker-1: Right, and I think that's another distinction is a lot of people want to be consulted. If they're not in the accountable category, they definitely want to be consulted. What does consulted mean? If I'm the person being consulted, do I have a voice? Do I have a level of approval? To your point, I think to sort of underscore that it is a person who brings a level of expertise to a certain aspect of the project. in which their feedback should be geared toward that level of expertise. Whereas somebody who's informed, it's a little less responsibility. I would say someone who's informed is being kept up to speed as to the progress of the project, because ultimately they will require access to the deliverables. The person who's informed will be kept in the loop throughout the process, but they don't have a say in the development of the creative. and they are more of sort of a passive participant.
speaker-0: I'll go back a second because we were talking about some conflicts that can arise. Races are supposed to head off conflict, but it doesn't always work that way, right? So for instance, someone could be listed as consulted, but there's no clarity on whether that means, like you said, would they get a vote or just a voice, right? I've seen stakeholders assume that they have veto power when the creatives intended for them just to be able to give input. how do you typically... set those expectations up upfront.
speaker-1: ⁓ gosh, it's a great, great question. There are a few different things that I think are important to identify. I already said, as long as everybody is on board and aligned on the roles and responsibilities of who does what and what each of their letters should mean in the process, the consulted role is essentially in place to have a value add from a person's level of expertise. So it's important to remember that they are contributing feedback based on that expertise, not based on subjectivity, not based on anything other than what they bring to the table. And I think that's where a creative operations person can and should, by all means, operate as both advocacy for the team and interference for the creative team. When you get into a place of subjective feedback, it's a moment where a creative team can feel quite vulnerable because that subjective feedback can often feel like an attack on a creative person, people's work, especially when it comes from that place of what does this have to do with the project at all? And that is in those moments, that is where I like to... say it is the creative operations or project managers obligation to underscore the roles and responsibilities to interject and say you are being consulted for this project because of your expertise in X, please weigh in as it relates to X and we will incorporate your feedback or something along those lines. instead of having a creative director or let's call it there are instead of the our person defending the work, a person like a creative ops person like myself or like you are both able to see that the feedback is not necessarily laddering up to those objectives. And at the same time, take that emotional element out of it by advocating for the creative, perhaps defending the creative if necessary, but also kind of taking out that emotional element that might come out if it were done. by someone on the creative team who actually made the work.
speaker-0: I think you pointed to something there that is really key, which is the feedback that's given has to be relevant to not just the person's role, right, but also to the expectations of the project and what the project was intended for from the very beginning, right? And so what I typically recommend is that as much as possible, these understandings get ⁓ get clarified in the the kickoff for any project, right? By having as many of the people who are going to be involved in the project in that meeting together, and the creative director, the project manager, contract or whoever it is, clarifies, this is what this person's role is, this is when that this is when you'll feedback, but also clarifying what the purpose of the project is, of course, why that's the goal, because It all has to stem from alignment early on in the project about whose roles are which and why. Along those lines, one of the mistakes that I most commonly see when people try to a ⁓ RACI is doing it in a vacuum, right? Let's say the project manager sets it up and emails it out to everybody without getting buy-in. Especially if it's a team that's not used to using RACI, it inevitably falls apart. What's your process for getting alignment.
speaker-1: At the outset, no racy chart should ever be just kind of thrown together without cross-functional alignment, communication, explanation of what it means for that team, who each of the acronym letters are on those teams and what they need to do at which points throughout the project. But it also, I think there is sort of a level of trust. So I saw this in a post. It was talking about... roles and responsibilities, not specifically in RACI, but it definitely related to this. When you say someone is responsible for something, you are trusting that person to be the person who is going to execute. When you say a person is going to be A, accountable, you are trusting that person to be accountable. So if you are setting up a RACI, in an organization where perhaps there is kind of a lack of trust or questionable trust, whatever that culture is, the RACI is not going to succeed as well as it might in an organization where we trust other people to do their jobs. You have to have sort of that baseline trust to say, you are now taking on this role for this particular project as this letter. in our RACI chart, can you do it? You know, it's definitely an upstream conversation. It's definitely an upstream alignment. I would say maybe even to have a little bit of the dialogue before that kickoff happens so that in the kickoff, everyone kind of knows what the RACI is already. That is just the official, here's the RACI for this project. We all discussed it and have already agreed upon it given that context. Let's dive into the project.
speaker-0: I agree with all that. I would add that it's important for teams to sort of weigh the structure of that versus some flexibility. So maybe understanding that this we are going to try out RACI for this one project, right? But that doesn't mean that we are going to stick with it for every project always. It may mean that we need to say, we're going to use RACI again, but clearly those roles didn't quite work the way we expect them to. We're going to iterate. We're going to make improvements on it. But if it doesn't quite work out the first time, let's not take that as a failure, right? We're going to improve it each time. It's always going to get better, but let's expect that it's there going to be frustrations, but there is value in this. So it's also important as you're talking about trust for the people who are assigned whatever the roles are to also have trust in. the person who is assigning those roles, right? Yes, the process and the person who is who is doing this. And so as you were saying, in some organizations and some cultures and some teams, it doesn't necessarily work. Let's say I'm working with a client who implemented RACI six months ago, and it's already falling apart. People aren't following it and
speaker-1: Trust the process.
speaker-0: You know, the reverting to old habits. My advice is typically to revisit whether the roles that they had established still make sense instead of just trying to reinforce the original version, To iterate, like I was saying before, what do you do when you see that a racy is losing traction? Let's say there was buy-in to begin with, but then it just kind of falls apart.
speaker-1: think the governance is probably the most challenging part of the RACI, especially in cases where somebody who's informed wants to be consulted, somebody who's consulted wants to be accountable, and there's perhaps loose alignment at the outset. The fact that it can change from project to project perhaps gives the perception that, ⁓ well, I was only consulted on that last project, maybe on the next one I'll be accountable or whatever the combination of switching categories might be. Then it doesn't feel as rigid. It feels more flexible. And that I think is where it could get tricky in terms of consistency and adherence to the racy. But I think to keep that governance, again, I go back to leadership support, but Sometimes leadership support isn't enough because sometimes leadership just wants to move quickly. It's tricky. I think the more the creative, let's call us the operations team, be that creative ops leaders, project managers, producers, anyone who's keeping to a timeline and a budget, the enforcement amongst those people who are in this, let's call them the greater creative team. They need to be the ones. saying the same thing to the stakeholders as part of the RACI. You know, saying like, on this project, you are C. I'll tell you the other people who are Cs, but on this project, you are a C. And as a C, it is your responsibility to do X and provide feedback on X because that is your area of expertise. I think it's just the reiterating of the roles and responsibilities until it starts working better. You have to have an openness and a trust in allowing for change, for the betterment of a project, for adding the greatest value to the business, and ultimately getting things done in an efficient way that takes the emotional element completely out of it. Focus on those objectives, and that is how a RACI will be the most successful.
speaker-0: I agree. You the purpose of the race, as I said in the beginning, is to clarify roles and responsibilities. Well, that's that's what it does. The purpose of it is to increase efficiency, but also to, as you were saying, to remove or limit the emotional challenges that come with any kind of project and not just creative projects. And for someone who's listening to this, who wants to create their first race tomorrow. My advice is usually to start small, right? With one recurring process, don't try to use it for everything and definitely not a major project. Where do you usually tell people to begin?
speaker-1: think it's actually best in terms of the type of project to pick a project that is something that you've done already several times. And you're familiar with the workflow of that project and you're familiar with the players in that project. It's not something that you're taking on for the first time. It's something that you've done and everyone already sort of knows their responsibilities. but sometimes it's gotten caught up in maybe some of the review cycles. And now you're like, okay, these projects aren't failing historically, but we do need to make them a little bit more efficient. I think that would be the first way to start a RACI and try it out and say to those people who in times before have had those roles say, we know that you've always been accountable for this project in the past. Now we're documenting it, we're going to make it official for this project type. You are now accountable, Mr. or Mrs. Person. And same goes with the rest of the team. Say you have always been consulted, you will continue to be consulted. Maybe now you layer in a couple of more informed people if that's something that's necessary. And then again, at the outset, kind of go over the roles and responsibilities, even though some people might already know them. And companies have a lot of turnover, know, so there could always be somebody new jumping into this. But because it's a project that let's say the creative team has done before and the stakeholder team has done before the accountable team, let's call them. You're not just starting from scratch. You have sort of an established rhythm and you kind of know how long that project is going to take. So, you know, the checkpoints for the most part. I think that's the best way to start implementing a RACI. And then if it doesn't work, again, this is something I always say about CreativeOps, it's not an immediate change. It's not going to be successful tomorrow. And if it's not, we iterate, we optimize, we talk about it. What worked, what didn't work.
speaker-0: think that's great advice. There's two great pieces of advice you give there. If you're implementing RAC for the first time, take something that you've already done and to expand on that a little bit more, I think another benefit of that is that you have a point of comparison, right? Because if you've done this project, let's say it's the weekly newsletter for something, right? We've done it 30 times and now you institute the RAC matrix. Once you've done that, now in the post-mortem, the team can look back and say, all right, did this work better with the RACI in place? So it's not just a new project where you're just trying to institute this, right? You have that comparison to how it was done before. So I think that's great advice. Thank you for sharing it. This is, as I said in beginning, maybe not the most exciting topic in creative production, but. It's so foundational and if you don't have these kind of structures built in, then you end up building structures without a solid foundation and things crumble and fall apart. So thank you for sharing your thoughts and your wisdom on Races. I really appreciate it.
speaker-1: Thank you for having me, Jessie. It was a pleasure and I could talk for another hour about this.
speaker-0: Yes. Thanks so much. Let's recap the key insights from today's conversation. First, RACES fail when you skip the alignment step. Don't create a RACE in a vacuum and email it out to stakeholders. You need cross-functional buy-in before it goes live. As Alyssa said, there has to be a baseline trust that people can actually fulfill their assigned roles. Have the conversation before the kickoff. Make sure everyone understands not just what the role is, but why it matters. And what happens if they step outside it. Second, governance is the hardest part. Even with perfect alignment at the start, races fall apart when people revert to old habits. Leadership support helps, but it's not enough. The Creative Ops team needs to consistently reinforce the roles. On this project, you are a C. Your responsibility is to provide feedback on X because that's your area of expertise. You have to be willing to beat that dead horse until things start. clicking. And third, start small. Don't implement your first racy on the biggest campaign of the year. Pick something you've done multiple times before where everyone knows their roles, but the process has gotten messy. You'll have a point of comparison to show whether the racy actually improved things. And when it doesn't work perfectly the first time, iterate. Racies are about clarity and structure, but there's no single right way to implement them for every team. If you found value in today's episode, please subscribe and leave a comment. Let me know what creative ops challenges you're facing. What topics would help your team work better? And if you've successfully implemented a RACI or tackled another ops challenge that other teams struggle with, I'd love to hear about it. You can reach out through the contact info in the show notes. Thanks for listening.
speaker-1: You have to have an openness and a trust in allowing for change, for the betterment of a project, for adding the greatest value to the business, and ultimately getting things done in an efficient way that takes the emotional element completely out of it. Focus on those objectives, and that is how a racy will be the most successful.
speaker-0: Today I'm speaking with Alyssa Strel. Alyssa has spent her career building and implementing the processes that most teams know they need, but struggle to make actually work. One of those processes is the RACI framework. If you've been in Creative Ops for any amount of time, you've probably heard of it. Responsible, accountable, consulted, informed. It sounds straightforward, but too often teams create a RACI, they distribute it to stakeholders, and then they watch it fall apart within weeks. People ignore their assigned roles, feedback comes from the wrong people at the wrong time, and the team ends up right back where they started, managing chaos instead of preventing it. Today we're going to talk about why RACES fail and how to make them actually work. We'll talk about why alignment matters more than the framework itself, what to do when your RACES loses traction, and where to start if you've never used one before. If your team has tried RACES and given up, or if you're thinking about trying one for the first time, This conversation will show you how to get it right. Alyssa, thanks for joining me today.
speaker-1: Thank you for having me.
speaker-0: All right, let's get racy. So despite how it sounds, racy's are not the sexiest aspects of creative production, but they are one of the most important. But there can also be a lot of confusion about them. So let's, let's just start with a quick definition. For anybody who's not familiar, a racy is basically a way to get everyone on the same page about who owns what part of a project, right? It clarifies roles and responsibilities. It's an acronym. R stands for responsible, A is for accountable, C is for consulted, and I is for informed. It sounds simple, but that's a little deceptive. So let's take this apart here. I find that a lot of failures start with the basics. People can think that they understand what the letters mean and what they're for, but they're working with different understandings or definitions of them, right? So let's just start with the first two, responsible versus accountable. How do you explain the distinction between those two?
speaker-1: Yes, so excellent introduction. think understanding the acronym itself can inherently be where things break down. it is really important that everyone understands what each of the letters not only represent, but also what they mean and what they mean to the people in a particular organization. I would say the R, which stands for responsible, is the team or people or person doing the work, this is the person executing, this is the person who is putting pen to paper. So that's R in my mind. And then the A, which I would say the R and the A are pretty much the top of the totem pole, they're the ones with the most responsibility in this acronym. A, the accountable team or person is the one or team who has final say on a given project. have the final approval. They are the one who ensures that whatever the project is, is meeting the objectives of the initial brief or the campaign or whatever the business objective is of the project that it's assigned to.
speaker-0: And the other part of this other pair that can trip people up is consulted versus informed. in my work, I usually tell clients that consulted means your input shapes the decision, but informed means that you you just need to know what's happening. Where do you you draw the line on that?
speaker-1: Right, and I think that's another distinction is a lot of people want to be consulted. If they're not in the accountable category, they definitely want to be consulted. What does consulted mean? If I'm the person being consulted, do I have a voice? Do I have a level of approval? To your point, I think to sort of underscore that it is a person who brings a level of expertise to a certain aspect of the project. in which their feedback should be geared toward that level of expertise. Whereas somebody who's informed, it's a little less responsibility. I would say someone who's informed is being kept up to speed as to the progress of the project, because ultimately they will require access to the deliverables. The person who's informed will be kept in the loop throughout the process, but they don't have a say in the development of the creative. and they are more of sort of a passive participant.
speaker-0: I'll go back a second because we were talking about some conflicts that can arise. Races are supposed to head off conflict, but it doesn't always work that way, right? So for instance, someone could be listed as consulted, but there's no clarity on whether that means, like you said, would they get a vote or just a voice, right? I've seen stakeholders assume that they have veto power when the creatives intended for them just to be able to give input. how do you typically... set those expectations up upfront.
speaker-1: ⁓ gosh, it's a great, great question. There are a few different things that I think are important to identify. I already said, as long as everybody is on board and aligned on the roles and responsibilities of who does what and what each of their letters should mean in the process, the consulted role is essentially in place to have a value add from a person's level of expertise. So it's important to remember that they are contributing feedback based on that expertise, not based on subjectivity, not based on anything other than what they bring to the table. And I think that's where a creative operations person can and should, by all means, operate as both advocacy for the team and interference for the creative team. When you get into a place of subjective feedback, it's a moment where a creative team can feel quite vulnerable because that subjective feedback can often feel like an attack on a creative person, people's work, especially when it comes from that place of what does this have to do with the project at all? And that is in those moments, that is where I like to... say it is the creative operations or project managers obligation to underscore the roles and responsibilities to interject and say you are being consulted for this project because of your expertise in X, please weigh in as it relates to X and we will incorporate your feedback or something along those lines. instead of having a creative director or let's call it there are instead of the our person defending the work, a person like a creative ops person like myself or like you are both able to see that the feedback is not necessarily laddering up to those objectives. And at the same time, take that emotional element out of it by advocating for the creative, perhaps defending the creative if necessary, but also kind of taking out that emotional element that might come out if it were done. by someone on the creative team who actually made the work.
speaker-0: I think you pointed to something there that is really key, which is the feedback that's given has to be relevant to not just the person's role, right, but also to the expectations of the project and what the project was intended for from the very beginning, right? And so what I typically recommend is that as much as possible, these understandings get ⁓ get clarified in the the kickoff for any project, right? By having as many of the people who are going to be involved in the project in that meeting together, and the creative director, the project manager, contract or whoever it is, clarifies, this is what this person's role is, this is when that this is when you'll feedback, but also clarifying what the purpose of the project is, of course, why that's the goal, because It all has to stem from alignment early on in the project about whose roles are which and why. Along those lines, one of the mistakes that I most commonly see when people try to a ⁓ RACI is doing it in a vacuum, right? Let's say the project manager sets it up and emails it out to everybody without getting buy-in. Especially if it's a team that's not used to using RACI, it inevitably falls apart. What's your process for getting alignment.
speaker-1: At the outset, no racy chart should ever be just kind of thrown together without cross-functional alignment, communication, explanation of what it means for that team, who each of the acronym letters are on those teams and what they need to do at which points throughout the project. But it also, I think there is sort of a level of trust. So I saw this in a post. It was talking about... roles and responsibilities, not specifically in RACI, but it definitely related to this. When you say someone is responsible for something, you are trusting that person to be the person who is going to execute. When you say a person is going to be A, accountable, you are trusting that person to be accountable. So if you are setting up a RACI, in an organization where perhaps there is kind of a lack of trust or questionable trust, whatever that culture is, the RACI is not going to succeed as well as it might in an organization where we trust other people to do their jobs. You have to have sort of that baseline trust to say, you are now taking on this role for this particular project as this letter. in our RACI chart, can you do it? You know, it's definitely an upstream conversation. It's definitely an upstream alignment. I would say maybe even to have a little bit of the dialogue before that kickoff happens so that in the kickoff, everyone kind of knows what the RACI is already. That is just the official, here's the RACI for this project. We all discussed it and have already agreed upon it given that context. Let's dive into the project.
speaker-0: I agree with all that. I would add that it's important for teams to sort of weigh the structure of that versus some flexibility. So maybe understanding that this we are going to try out RACI for this one project, right? But that doesn't mean that we are going to stick with it for every project always. It may mean that we need to say, we're going to use RACI again, but clearly those roles didn't quite work the way we expect them to. We're going to iterate. We're going to make improvements on it. But if it doesn't quite work out the first time, let's not take that as a failure, right? We're going to improve it each time. It's always going to get better, but let's expect that it's there going to be frustrations, but there is value in this. So it's also important as you're talking about trust for the people who are assigned whatever the roles are to also have trust in. the person who is assigning those roles, right? Yes, the process and the person who is who is doing this. And so as you were saying, in some organizations and some cultures and some teams, it doesn't necessarily work. Let's say I'm working with a client who implemented RACI six months ago, and it's already falling apart. People aren't following it and
speaker-1: Trust the process.
speaker-0: You know, the reverting to old habits. My advice is typically to revisit whether the roles that they had established still make sense instead of just trying to reinforce the original version, To iterate, like I was saying before, what do you do when you see that a racy is losing traction? Let's say there was buy-in to begin with, but then it just kind of falls apart.
speaker-1: think the governance is probably the most challenging part of the RACI, especially in cases where somebody who's informed wants to be consulted, somebody who's consulted wants to be accountable, and there's perhaps loose alignment at the outset. The fact that it can change from project to project perhaps gives the perception that, ⁓ well, I was only consulted on that last project, maybe on the next one I'll be accountable or whatever the combination of switching categories might be. Then it doesn't feel as rigid. It feels more flexible. And that I think is where it could get tricky in terms of consistency and adherence to the racy. But I think to keep that governance, again, I go back to leadership support, but Sometimes leadership support isn't enough because sometimes leadership just wants to move quickly. It's tricky. I think the more the creative, let's call us the operations team, be that creative ops leaders, project managers, producers, anyone who's keeping to a timeline and a budget, the enforcement amongst those people who are in this, let's call them the greater creative team. They need to be the ones. saying the same thing to the stakeholders as part of the RACI. You know, saying like, on this project, you are C. I'll tell you the other people who are Cs, but on this project, you are a C. And as a C, it is your responsibility to do X and provide feedback on X because that is your area of expertise. I think it's just the reiterating of the roles and responsibilities until it starts working better. You have to have an openness and a trust in allowing for change, for the betterment of a project, for adding the greatest value to the business, and ultimately getting things done in an efficient way that takes the emotional element completely out of it. Focus on those objectives, and that is how a RACI will be the most successful.
speaker-0: I agree. You the purpose of the race, as I said in the beginning, is to clarify roles and responsibilities. Well, that's that's what it does. The purpose of it is to increase efficiency, but also to, as you were saying, to remove or limit the emotional challenges that come with any kind of project and not just creative projects. And for someone who's listening to this, who wants to create their first race tomorrow. My advice is usually to start small, right? With one recurring process, don't try to use it for everything and definitely not a major project. Where do you usually tell people to begin?
speaker-1: think it's actually best in terms of the type of project to pick a project that is something that you've done already several times. And you're familiar with the workflow of that project and you're familiar with the players in that project. It's not something that you're taking on for the first time. It's something that you've done and everyone already sort of knows their responsibilities. but sometimes it's gotten caught up in maybe some of the review cycles. And now you're like, okay, these projects aren't failing historically, but we do need to make them a little bit more efficient. I think that would be the first way to start a RACI and try it out and say to those people who in times before have had those roles say, we know that you've always been accountable for this project in the past. Now we're documenting it, we're going to make it official for this project type. You are now accountable, Mr. or Mrs. Person. And same goes with the rest of the team. Say you have always been consulted, you will continue to be consulted. Maybe now you layer in a couple of more informed people if that's something that's necessary. And then again, at the outset, kind of go over the roles and responsibilities, even though some people might already know them. And companies have a lot of turnover, know, so there could always be somebody new jumping into this. But because it's a project that let's say the creative team has done before and the stakeholder team has done before the accountable team, let's call them. You're not just starting from scratch. You have sort of an established rhythm and you kind of know how long that project is going to take. So, you know, the checkpoints for the most part. I think that's the best way to start implementing a RACI. And then if it doesn't work, again, this is something I always say about CreativeOps, it's not an immediate change. It's not going to be successful tomorrow. And if it's not, we iterate, we optimize, we talk about it. What worked, what didn't work.
speaker-0: think that's great advice. There's two great pieces of advice you give there. If you're implementing RAC for the first time, take something that you've already done and to expand on that a little bit more, I think another benefit of that is that you have a point of comparison, right? Because if you've done this project, let's say it's the weekly newsletter for something, right? We've done it 30 times and now you institute the RAC matrix. Once you've done that, now in the post-mortem, the team can look back and say, all right, did this work better with the RACI in place? So it's not just a new project where you're just trying to institute this, right? You have that comparison to how it was done before. So I think that's great advice. Thank you for sharing it. This is, as I said in beginning, maybe not the most exciting topic in creative production, but. It's so foundational and if you don't have these kind of structures built in, then you end up building structures without a solid foundation and things crumble and fall apart. So thank you for sharing your thoughts and your wisdom on Races. I really appreciate it.
speaker-1: Thank you for having me, Jessie. It was a pleasure and I could talk for another hour about this.
speaker-0: Yes. Thanks so much. Let's recap the key insights from today's conversation. First, RACES fail when you skip the alignment step. Don't create a RACE in a vacuum and email it out to stakeholders. You need cross-functional buy-in before it goes live. As Alyssa said, there has to be a baseline trust that people can actually fulfill their assigned roles. Have the conversation before the kickoff. Make sure everyone understands not just what the role is, but why it matters. And what happens if they step outside it. Second, governance is the hardest part. Even with perfect alignment at the start, races fall apart when people revert to old habits. Leadership support helps, but it's not enough. The Creative Ops team needs to consistently reinforce the roles. On this project, you are a C. Your responsibility is to provide feedback on X because that's your area of expertise. You have to be willing to beat that dead horse until things start. clicking. And third, start small. Don't implement your first racy on the biggest campaign of the year. Pick something you've done multiple times before where everyone knows their roles, but the process has gotten messy. You'll have a point of comparison to show whether the racy actually improved things. And when it doesn't work perfectly the first time, iterate. Racies are about clarity and structure, but there's no single right way to implement them for every team. If you found value in today's episode, please subscribe and leave a comment. Let me know what creative ops challenges you're facing. What topics would help your team work better? And if you've successfully implemented a RACI or tackled another ops challenge that other teams struggle with, I'd love to hear about it. You can reach out through the contact info in the show notes. Thanks for listening.
