Bringing Agile to RevOps

James Geyer: Hello everybody. We’re back for the latest episode of Boardroom RevOps, where we’re bringing you valuable tips from RevOps experts so you can make to the C-suite. I’m James, co-founder of RevOps, the RevOps BI platform. I’m joined by Liv Carter, who has over a decade of experience in various sales ops and RevOps roles.

Um, we’re gonna talk about a topic that Liv is very passionate about from that experience. Um, and that’s putting an agile methodology into work, uh, within RevOps. Why don’t we just dive right in. Um, Liv, great to have you here. Tell me like maybe just briefly, what Agile is and why you think it’s a good fit for RevOps.

Liv Carter: Sure. Uh, thanks for having me. I think the best fit or the thing that everybody talks about when they’re doing revenue operations or sales operations, everybody talks about the fire hose. If there’s stuff coming to you constantly, requests constantly, then there are the strategic things that you want to do in the middle of all the, I need a report on this.

Can you write a playbook for that? Can you like the constant thing for me, I have not found a better organizing principle than the Agile framework to keep me sane. When, I am in a role of RevOps where I have strategic work that needs to get done. and a constant fire hose of requests,

James Geyer: that’s spot on. That’s maybe the thing that I hear most commonly talking to folks in RevOps is that they have all the strategic work they wanna do, but they just can’t get to it.

So that’s a great reason to do it. Sanity is also very important too. Keep track of as well. So tell me how you first kind of got into it.

Liv Carter: I very first got into it, so everybody will be familiar with Agile as something that engineering teams use. Most products and engineering teams will be on some form of agile, at least in every tech company I’ve worked in.

So I was, this feels like a hundred million years ago, dinosaurs were roaming the earth and I was working at Eventbrite. They started different guilds for different skill sets. So they set up the Agile Guild and it was all engineers messaged the Agile coach and I was like, can I sit in, can I, I’m really interested.

So she had a conversation with me to, I think, to gauge why I would want to, you know, invade their space. But she allowed it and I joined the Engineering Agile Guild at Eventbrite and spent. Met, I think every few weeks where it was like specific topics that the coach would teach and then group discussions on where are people stuck.

So I sat quietly, I know uncharacteristic for probably the first few sessions to really just like listen and learn and then slowly being able to see, okay, this, this is actually what I thought it was, and I could really adapt this for non-engineering teams. So that was my, my introduction was a agile guild.

Filled with engineers and then me.

James Geyer: That’s great. Another case study of where curiosity leads to good outcomes. Right. I think the people that are most curious in, in life always, uh, continue to learn and, and thrive. So That’s awesome to hear. Um, alright, so tell me then if you, you said this is kind of an engineering first methodology typically, like how did you use these principles originally?

Like, I, I don’t think, if I remember from our past conversation that you kind of fully set up a scrum team as they call it, but yeah. How did you use the principles?

Liv Carter: Sure. So Agile is a pretty wide framework and it was born out of engineers seeing a problem with how they were doing their jobs, their engineering, pre 2001, when this really was born, was very, uh, documentation heavy.

They were spending so much of their time documenting instead of doing so, the delivery of new products was slow ’cause everything had to be documented. And Agile came out of the need to drive faster delivery and in being able to do that in an adaptable way, hence the name. So the way I initially started using it was Agile brings you a couple of different ways of looking at your work, and you can take them even without setting up sprints and kind of having a more rigid way of organizing your work.

The biggest one that I implemented almost as soon as I heard, uh, or as soon as I started. Joining that Agile Guild was how to think about prioritizing your work. And I think most people will have the, you know, that kind of prioritization matrix where you have, uh, low, medium, high effort and low, medium, high impact.

Agile takes that, but gives it a twist. So you really, you’re not just thinking about effort and impact, you’re also thinking about complexity. You’re thinking about resources needed. You’re thinking about all these different things that go into. What is my prioritization? Can I do this on my own? Does somebody else need to come in?

Do I need to do any testing before I deliver this or can I just deliver it? All of those things come into play. So the way that it taught me to think about prioritizing all the work was the first thing that was useful within weeks of learning about it, and that had nothing to do with having to create backlogs and sprint boards and all the more technical parts of Agile.

You can kind of immediately take that. And then the second thing I think that I took, which now I actually consider the most important, is everything around visibility and communication. Hmm. It really taught me how to communicate about my work. ’cause again, here we are trying to do these strategic initiatives and the fire hose is just in our face all day long.

Being able to communicate about that and negotiate with stakeholders of what is their prioritization, or you have two conflicting priorities, getting those stakeholders to agree and not always RevOps having to be, you know, bad cop who tells one person no and another person. Yes. I think right now I actually consider the more important part of agile without even using sprints is visibility and communication.

And then secondarily is how to prioritize your work.

James Geyer: Tell me more about the visibility piece. Is it the, was it the, the concept of a backlog? Like even if you weren’t traditionally using a backlog like you would in Agile, was it just the idea of having a backlog to be the framing for that negotiation or like what tactically led you to like doing a better job of visibility and communication?

Liv Carter: The best way. So if we think about Agile, and we’ll do the slightly more technical right of what, what are kind of all the steps is the way Agile organizes all of your work is it makes you think in terms of the largest lens is called initiatives. These are often things that you’re doing over the whole year, or I would should say, not things you’re doing, but things you’re contributing to over the whole year.

So that could be. A new product that’s being launched within the company, right? That’s a classic. You don’t do that in three months in a quarter. You don’t even do that in six months. You do that over the whole year of everything that you need pre and post-launch. So let’s say that the new product being delivered is your initiative, your under your initiative, you might have several epics.

So you’ll ha think of epics more as sort of individual projects that contribute to the larger initiative.

James Geyer: Kind of finite, basically like just like a tangible Yeah, like more

Liv Carter: contained. Yeah. And so an epic could still be something that takes place over multiple sprints. It usually is, but it’ll be a smaller piece.

So when you think about, we have the big product rollout is our initiative, all of the enablement material. Could be an epic enablement and marketing assets. Maybe an Epic. It could be getting everything ready for the playbook for sales, for that new product that’s an Epic. All of the reporting you need to set up the billing that you might need to, uh, set up.

All of those would be projects underneath, and then your individual sprint tasks roll up to those epics. So when you think about it in the big term, every sprint item. Is connected to an epic that is contributing to an initiative that by itself is gold. ’cause imagine you’re doing this. You have say, three initiatives to deliver for that year.

Somebody comes to you. Wouldn’t it be cool if we had a report on, um, I don’t know, like something dumb like every customer that signed when there was a full moon and then we wanna see how they can, nobody cares. Right? But that’s also not tied to a specific initiative. It’s not tied to an epic, it’s not tied to an initiative.

It is just a one off random idea that somebody came up with and dumps onto RevOps. We have all been there, right? The sort of random idea that somebody has. If it’s not tied to that Epic or initiative, it’s much easier to then say, here’s why that can’t go into our list of priorities. Even if you don’t have sprints, you could still be Kanban.

But you can then much more easily. Again, that communication piece, it’s much easier to work with your stakeholders if you can say that doesn’t contribute to anything. We are completely booked solid on all the things that have to contribute, so we don’t have space for this. It just makes that so much easier.

James Geyer: Yeah. Not to mention, like I imagine the sheer amount of tasks within the epics to the initiatives also helps say like, oh, it’s actually not so easy to just go do this or that. There’s actually 10 other sub items here that we have to accomplish. It’s pretty complex.

Liv Carter: What is the one thing that every RevOps person has heard?

The one phrase that every RevOps person has heard that usually accompanies a request

James Geyer: Isn’t that, isn’t it quick?

Liv Carter: It’ll just take five minutes.

James Geyer: Yeah, yeah, yeah. Yeah.

Liv Carter: I’ll just have a quick request. It’ll just take five minutes. Can you make this whole workflow in Salesforce? Right. Um, is the, it helps with that a lot.

And then the other thing to the point you just made, that brought up a memory of working with an executive a couple of years ago who had a lot of things that needed to be accomplished also, a lot of things were brought to RevOps and it started to get a little frustrating ’cause things weren’t being prioritized from the perspective of that executive.

Like things weren’t being prioritized. For their team. Then we made our public, our backlog and our sprints public. And the next meeting I had with that person, it was like, oh, I get it now because now that I see how much other stuff. And I think at that point all the marketing items were, uh, color coded purple, I think purple or blue, I can’t remember.

But it’s that person going Now I see how much of the ways in purple I see how much is being delivered. For other teams. So again, it just makes working together so much easier where people can see, it’s not that you’re not prioritizing this request because you just don’t feel like it is, you’re not prioritizing this request because here does other work that’s getting done tied to these priorities very cleanly laid out.

That really helps with the kind of just being able to work together in a productive way.

James Geyer: Yeah, that’s great. You mentioned something earlier too on the prioritization piece that you led with that. Um, there’s the traditional matrix of like effort and impact and you mentioned that Agile kind of taught you to bring in some other things around, like complexity and things like that in terms of how you prioritize your work.

Anything more to say on that front? Like how do these other criteria impact your prioritization? Is it the fact that certain things need more lead time, therefore they need to be prioritized first, even if they’re maybe less important? Or like how do these factors, I’m, I’m trying to think on like a multidimensional matrix now and how you can actually take a advantage of that tactically and decision making.

Liv Carter: That is exactly right. I’m trying to find a good example. So I was recently talking to a company and they were like, we have these three priorities that need to happen in in this order. Priority three takes months. Priority one and two, take time. But priority three actually takes a really long time. So even though somebody says this first thing, you know, item A is our biggest priority.

When I then think about how would we wanna start creating sprint items that go into that roll up to these priorities in Sprint one, I already would be wanting to do the groundwork for that third priority because I know it will take months and it will take a lot of back and forth and needing to get approval sign off.

So I knew they would internally need to be having a lot of conversations about approvals. All of that adds complexity. All of that adds additional people who need to say. What they, you know what they want out of it. So you need to start doing the, the groundwork for that in sprint one and not do, we’ll do everything for priority one.

We’ll do everything for priority two after, and then we’ll do priority three. You don’t have enough time, so it’s part of, have you heard of story points?

James Geyer: I have. Should.

Liv Carter: Does that come across your desk?

James Geyer: Yeah. Tell tell for the audience though.

Liv Carter: Most people have heard of story points, but there’s a couple of different ways to do what Agileists will call like sizing, right?

It is like how do you size how, what the work is, and there’s a couple of different ways to do this. One way is simply to go, this will take me three days versus this will take me five days, right? It’s like just the amount of time, the way that Agile makes you think about sizing. Is again, taking into account resources and the complexity and the time, including the time it might take.

So what they came up with is you score all of your items with um, de Fibonacci numbers. So it’s 1, 2, 3, 5, 8, 13. If you are scoring something higher than 13, you need to break it up ’cause that’s too much to go into one sprint usually. So you can have a 21. But you’re not gonna put that in a sprint ’cause that is just, that’s too big.

You need to, that needs to become an eight and a something else, or a couple of fives. So it helps you think about all these different dimensions that go into prioritization, assigning at a numerical value. The biggest benefit you get from that is it allows you to learn how many story points you can clear in a sprint.

Yeah, because if I give you, you know, here’s your to-do list for the week, actually aside, remind me to talk about the pull system in a second. Um, like here’s the things that, yeah, the classic manager thing, right? Here’s your tasks for the week. If I give you five things and you do four. I don’t really learn from that much.

Hmm. It’s like, oh, you just didn’t do what you were told to do. And you can then say, well, but this took more time than I thought. Or, you know, and again, you have friction and communication versus after a few sprints, I learn that you consistently can clear, let’s say, you know, 16 story points and you got, you.

We know you get some ad hoc requests in the middle. We can start to look at the data. And learn how many story points maximum do you wanna pull into a sprint? And how many do we wanna leave open for the ad hoc requests we know we’re gonna get? So you can say, okay, I can definitely clear 16. I know I need to leave five for the ad hocs, so when I build my sprints, I will not go over 11 story points, and that gives me time to respond to those ad hoc requests when I get them.

James Geyer: That’s great. Super helpful. Um, tell me about the pull system.

Liv Carter: The biggest, so this is the first thing I, when I implement Agile, this is the first thing I do. I don’t start bringing a team into Agile with everything I just said. It is one thing at a time. And the first thing I think teams need to learn how to do is move from what’s sort of referred to as the push system to the pull system of filling their work weeks up.

So push system, the classic. The manager says, here’s what you’ll have to deliver this week. That doesn’t work in Agile. In agile, you yourself, look at the backlog, you look at all the things that need to happen, and you create your sprint yourself. So rather than me as a team leader telling you, you deliver these things, you are telling me what you’re gonna deliver, and you do the sizing, and this is unbelievably crucial, and this is where I’ve seen even teams that have implemented agile.

Miss the mark because the person who is creating, who is leading the team, is still too involved in controlling what goes into the sprints and is trying to control what the sizing is. It’s not for me to tell you, you need to build this dashboard, and by the way, that’s a five. That’s your job. You tell me, and then again, if you get that wrong, you learn and you learn for next time.

Well, it was really more of a three. Or it was really more of an eight. ’cause there actually was a lot of back and forth on getting that dashboard right with the stakeholder. So you kind of learn from your sizing how much work you can pull, what you can consistently deliver. Um, but you take on a lot more responsibility than in a traditional push system.

’cause you told me you were gonna do it. It wasn’t me. Yeah, you said it

James Geyer: interesting. So you’re getting someone to mind and it creates that accountability. Make commitment. Yeah. Interesting.

Liv Carter: Yeah, and it’s just in our brains, it changes it in our brain, right? It’s like I said, I was gonna do it. So it really creates that accountability, that extra layer of accountability of, I said I was gonna do it.

I should hold myself accountable to delivering it. And again, if you’re leading a agile team, you wanna build in, um, a couple of places where people can renegotiate if they realize that they’ve drastically missed their sizing.

James Geyer: Yeah. Interesting. I think we maybe have started to bleed into this, I think. So we’ve talked about some of the principles you took to Agile in the beginning when you were first learning about it.

We started talking a little bit about what are the actual steps of agile, how the work is broken up, story points pulling, et cetera. That might have led a little bit into what I wanted to ask, which was like about your full agile transformation that you did when you had a larger team. Yeah. Um, so tell, tell me more about that.

Everything that went into it.

Liv Carter: So that was, um, a team of, I think seven or eight at the time when I, when I did the. When I did the transformation and it was like I just said, I started with, I started weekly first of all, so not two week block, but a weekly block. And I started with, you tell me what you’re gonna deliver in every week, and you size in a more simplified way.

So the sizing initially was T-shirt sizes, extra small, small, medium, large. No extra large. If it was extra large, you needed to break it up over multiple weeks, again, to sort of teach people and get them used to the basic things they need to be able to do to be able to work affect efficiently and agile.

So it’s pulling your own work, sizing it correctly, and then being able to break up. Larger pieces of work into smaller components. Those are kind of the basic things that your teams will need to be able to do by themselves without handholding. Otherwise, there you cannot move over to Agile just yet. It’s, you’re gonna fail.

I mean, that’s a good thing by the way. Failing ’cause that’s how you learn, but it’s, it just will cost you more time if you can take the time to teach people those three foundational things. So we started with that. And then about a few weeks in we were like, okay, now what if we do the same thing, but we do two weeks, two week blocks.

So now they had that additional thing of thinking, okay, I can pull in more work. But now within the sprint, they had to think about how they were prioritizing their own work. Mm-hmm. Because if you do, let me take care of all my ones, my ones and twos, right. The quick things, I’ll do that Monday, Tuesday, Wednesday of the first, the first week of the first sprint.

But now all your larger projects are bundled together toward the end of the week or toward the end of the school.

James Geyer: Yeah. I mean, those lead times that we talked about.

Liv Carter: Yeah, exactly. So again, it’s learning that like this thing is gonna take me, I need to go. Um. Do qa or if it’s something bigger in Salesforce, I need to do user acceptance testing.

If all of that has to happen, you can’t wait to start building in sandbox until Thursday of the second week. Right? You have to start Monday, Tuesday with some of the basic things. ’cause you know you’re gonna have that back and forth. That’s the skill that everybody can learn. I, I don’t think there’s anybody who can’t learn this.

You just need to fail at it a few times. Which is why failure is a good thing. And then you start to learn what that needs to look like for you and you become much more efficient. So that was kind of the first thing is teaching people that different way of thinking about their work contained in one week.

Then it became, okay, now let’s do it over two weeks. And then we really started thinking about what’s our delivery method. How are we delivering things for our internal customers? For the folks who more steeped in this, what I initially used is called continuous delivery lean, so it wasn’t even agile delivery ’cause we needed to be so quick.

There was so much to do. We used lean for delivery so that it was almost every sprint. There were multiple things that were being delivered just because we had to keep up with the pace. And then once things kind of settled down and, um, the, the, especially the fire hose was under control a little bit, we moved to, uh, agile delivery, which makes you a little bit, do a little bit more work upfront.

Um, but then on the backend we will probably have a little less like change requests for the things you’re delivering. ’cause your stakeholders are more involved at the front.

James Geyer: Super helpful. Tell tell me a little bit more about the difference between lean and agile delivery. Real quick, for those uninitiated that might be listening is lean just more frequent.

Liv Carter: Lean is more frequent in the way that you do it. So you have different, and this is true in every project management, this is in. Spec specific to Agile. So you’ll have kind of your inception phase of getting business requirements, translating those to technical requirements. You know, like that stuff, kind of what does somebody even need?

Why do they need it? All of those questions you ask, that’s inception, and then you start to think about what you’re trying to do. Then you move to a construction phase where you’re building the thing and then you have your delivery phase. That’s true for any project management. What you do when you do lean is you do little, little or sometimes no, um, of the first you take the request and as you are constructing, you are weaving in your inception.

You can’t do that forever because I think you ultimately will start to. Especially if it’s something more complex. You do really need that inception phase. You need to truly understand the requirements, but when you have to deliver so quick, that’s the one where you can kind of go, let’s vastly reduce that.

And then as you move more to agile, you start doing more and more inceptions. So more information gathering, more negotiation at the front end before you even start building. So you can do your building a little bit quicker usually, and you have less change requests as you are building and talking to your stakeholder, like, okay, your dashboard looks like this now, is that in line with what you were wanting?

Those conversations, they then slow down when you work in real, like more agile delivery. But yet it’s all about thinking about those phases of projects and where. You can allow a little bit more detail and a little bit more time, and where you take that away on purpose in order to drive faster delivery.

James Geyer: Yeah. Okay. Cool. So to summarize, with your kind of full agile transformation, you started off having the team, what you first, you broke apart all the tasks from the top level initiatives into epics and into tasks. You taught the team to size them themselves. They were pulling it out for a one week sprint to start.

Expanded into two, which actually had its own challenges of like needing people to learn how to prioritize even better, like within the sprint. And then you also evolved like the delivery method as well. Anything else that we missed in like the agile transformation that you did or does that kind of like cover it?

Is that, is that a complete agile process?

Liv Carter: Well, the, we forgot a whole section and that is how you talk about this with other, other teams.

James Geyer: That’s right. ‘

Liv Carter: cause that’s a big change for the people who work with you. Right? Everything we’ve talked about so far with that one example as the exception has been like, what does it look like in your RevOps team?

Mm-hmm. But the real power comes from how you now work differently with all of your other GTM stakeholders because they can now see if you can find, and there’s plenty of, uh, products now you’re not stuck with, you know, JIRA or nothing. There’s a lot of really, really good products now where you can do this.

And honestly, if you just start, you don’t even need, all you need is a spreadsheet. Yeah. An Excel sheet or a Google sheet, and you start building there. You can even start with that. Um, as long as you can show, when I things come into your backlog is tie them to an epic that’s tied to an initiative. You wanna do that as fast as possible.

If that is not the case, that tells you that maybe that item isn’t a priority and you work with that stakeholder. But that’s, I think, the biggest driver of better communication, better collaboration for me has been having a backlog that’s public, clearly tying it to the company priorities. So it’s, it’s not us just in isolation, deciding.

This isn’t a right now issue. It’s we have all this other stuff to deliver for the company. Therefore, this isn’t a right now issue. That’s a very different conversation with usually, you know, executives who are under a lot of pressure. They need to deliver too. They’re relying on you, the RevOps team, for certain things to happen.

It just creates a completely different way of communicating.

James Geyer: Yeah. Is that how you get people on board with it? Like the the talk track I am presuming is like, Hey, this is gonna allow us to work together more effectively. You’re gonna be able to see what we have in flight, and we’re ultimately gonna be able to deliver on your highest priority things faster.

Is that the talk track or no?

Liv Carter: Yep. Yeah, exactly right. Is to say of having, ’cause I, I had a conversation with an executive from another company about, um, I think a few months back and we were talking about RevOps and they said, yeah, we kind of struggled with. RevOps was like, okay, why? And when it came down to it, when I dug a little deeper, what it came down to was their work wasn’t really visible.

They didn’t know when something was gonna get delivered. It was, it’s in our, it’s in our sprint. We’re, we’re working on it. But if you make all that public, the backlog and the sprints. That’s not, you don’t have to worry about that anymore. They already know. And then especially very, very crucial if, let’s say that you’re working on, you know, sprint 10 and somebody brings you a request and it’s tied to a priority and you’re definitely gonna do it, but you can only slot it into Sprint 14, which is then two months from then you have to then do it in Sprint 14.

Mm-hmm. ’cause that’s where you build trust. If you’re not able to give people the timeline that they really want. You say this will be done in sprint, whatever, and then you have to push it yet again? No. If you put it in a sprint, you have to then do it in that sprint or you just lose all credibility.

James Geyer: Yeah.

That’s kind of the trade. Right. Cool. Sadly, we’re almost at time. I’m curious, uh, when is agile maybe not the right methodology for folks in Rev?

Liv Carter: Um, most of the time I think you’re gonna find if you are only fire hose. If your RevOps team isn’t yet needing to be strategic, probably you can get away with not doing this.

You can do Kanban, you know, what, what am I supposed to do, what is in progress, what is maybe blocked, and then what has been delivered. Um, if you don’t really have like wider strategic initiatives and it’s just ad hoc requests. You could just kanban is probably better for you to kind of keep track of everything that’s happening.

The other, and I’ve used it sort of in an even more adapted way, if you’re a RevOps team of one. You could still use sprints, but now there’s no negotiating research talking to yourself. So you could still do and kind of put stuff in sprints to make it a little bit more contained, but it’s probably not gonna be like true agile sprints where you are trading off and sizing and all those things.

It’s more. Then I would use it more to just sort of organize the work in discrete time windows rather than really doing full agile. You’ll still, in either case though, you still get the benefit of knowing how to prioritize better, knowing how to take into account more than just effort, and the impact you get to take into account more, so you still get the benefit of that training.

You just probably don’t need the full, complete, more complex technical setup.

James Geyer: Yeah. Makes sense. Um, this is great. I feel much more edified on the subject, sadly. We’re at time. Anything final to add though, that you wanted to cover on Agile that we missed? Or do you think this is a pretty comprehensive view?

Liv Carter: I think this’ll get most people started. The B the biggest thing is I could never, you know what, let me say this, ’cause this came up in a conversation just like two weeks ago, but try to get away from the right way of doing something. You get to adapt agile to what’s true for you and what you need to do.

It is the um, and again, like we have this, and especially I think a lot of RevOps people will have this idea of here’s the one way to do it and I need to get as close to that perfect as possible. No, stop thinking that, which took me a while too, is if your sprints, ’cause I did that too. Sprints traditionally follow kind of the Wednesday to Tuesday if you’re an engineering team.

I made it Monday to Friday, Monday and then to the following week, Friday. That’s not traditional, but it worked. We set up our sizing slightly differently than an engineering team might do it again, because we’re not delivering a product, we are sometimes delivering tasks, um, is you get to adjust it to what works, play with it, test it, and frequently do your retros.

So your retrospectives. A classic ingredient of agile, you’re gonna do those to learn what works for you, what doesn’t work. If continuous delivery doesn’t work for you, change it. If you need more or less time in inception, change it. Keep what works and change what doesn’t. And kind if you make it better all the time is crucial.

And then just keep learning. I’d still talk to Agile coaches all the time, is you never learn all of it. There’s always a different way of deploying it, so it’s just stay curious.

James Geyer: It’s kind of an agile approach to agile, if you will.

Liv Carter: Exactly. That’s a great way to say that. Be agile. About Agile. About agile, right?

Yeah, it really is. ’cause it’s, there isn’t this like, here’s the only way to do this, and you do run into those folks who have a fairly set view of how agile should be deployed. But that’s sort of, that’s not the point, that’s not the reason it was developed in the first place. It, it, it really is, allows you to create the way of working that’s gonna work for you.

And even within the same company, as things change within companies, right? As company goes from maybe startup to scale up and now you’re hit profitability and you wanna think about IPO readiness, your way of working through that probably will have to change. So it’s constantly learning, staying curious, interrogating your own work of being able to see what’s working and what’s not working, um, and just being able to let go of the stuff that doesn’t work.

James Geyer: That’s great. Liv, thanks so much for hopping on. This was super interesting and helpful. I think folks are gonna take a lot from it. So thanks for stopping by.

Liv Carter: Of course. Thanks for having me.