I Killed My Ops Manager’s Best Work (For Now)

My ops manager built something that is brilliant, and I told him to shelve it. And here's why.

We're in the middle of a very heavy lift project right now. We're re-engineering our entire onboarding process and our recruiting offer. You know, so everything from the moment where a client says "yes" to the moment where they have a salesperson or an SDR that's going into the fractional sales management program. And so that's either onboarding the rep that they have, or it's recruiting—which is one of our offers. And re-overhauling that process... there's a lot of moving pieces, but it's our primary constraint right now, and so it's the only thing that we're working on.

And in one of the early planning meetings, my ops manager—who by the way is brilliant, tech nerd, really really smart, very creative, very proactive, and you know so if we're building anything in tech, AI automation, whatever, he's our dude—so he comes to one of these early meetings after hearing kind of what we were struggling with and what we were doing and seeing the original beta version of the new process, he actually just went and built a custom platform to run that process from.

And he gave us a full demo and it's really cool. I mean, it's got where you can see people in the onboarding process, it's got the recruiting pipeline stuff baked in, it's got a number of things that do genuinely help—one being transparency between onboarding manager and the recruiting manager and then the fractional sales manager. Like, everybody can see where this is at. And the demo was really good.

And I said, "This isn't what we need right now." And we've got to table it. And it's not a "no," but it's a "not now." And there were three reasons for this.

The first was: you automate things last. When you're rolling out a new process, the first question that you've got to ask is, "Are we ready to systematize this and automate it?" If you study people who've been serially successful—I read a lot about Elon Musk—once you've built a few billion-dollar companies, I think you've kind of shown you think differently. It's not completely random, it's not complete luck; there's some thinking behind it. And a lot of serial entrepreneurs—Alex Hormozi talks about this, too—they share a fundamental belief, and it's that you automate and you systematize things last.

Elon actually used to be a disciple of automation, and he thought automation just by the nature of efficiency and leverage was the way to go with most things because your output-to-input ratio is just higher when you don't have people doing something—you can automate it. But what he learned, and then I keep relearning, is it's really a trap. Because here's what happens: you start focusing on systematizing and automating the process, and you stop asking whether this is even the right process. And so you're not asking, "Hey, does this have steps that we don't even need?"

So instead of trying to make doing everything more efficient, we should be asking, "Do we even need to do that?" Is it necessary? Are there things that we should just be deleting and eliminating rather than automating? And what most companies do, and what my ops manager was about to do, is see a big complex problem and they identify a need where systematizing or automating would improve efficiency or transparency or consistency—whatever it is—and they jump straight to, "Well, then how do we systematize this?" Because they're asking the question of, "Well, will this scale?" Which I get—I used to ask the same question—and so you start engineering for scale before you've even proven that what you want to do actually works.

And that's a challenge, but there's a second layer to this: once you systematize something and once you automate something, you immediately become less flexible. If you roll out this new process and you roll out the platform with it—in our case, with all the automation tied into it and all this development—it's cool, looks great, but I promise you there's no way that process is perfect. It's a brand new process, there's too many moving pieces; there's no possible way that that could be perfect on our first run. And it's going to require a lot of iterations. Like, we're going to have to run through that process and change it and tweak it and make those adjustments.

But once it's been systematized, once it's been automated, you start building a reluctance to make changes to the stuff that needs to be changed. There's like a sunk cost fallacy that gets baked in because changing things is harder than it should be. Say we roll out this platform, we've got this cool pipeline, we've got all these cards that move and... well, if we say, "Okay, hey, we actually should do this," well, somebody on the team is going to go, "Well, that means we have to change that whole platform and probably break 27 automations and..." and you go, "Well, maybe we just leave it. Maybe it's good enough."

And that's why automating something can actually lead to a less efficient process because you leave stuff that shouldn't be there in the first place or overall inefficient processes because the execution of each individual task within that process feels more efficient. And the only way, I mean, when you go in to fix something that's broken that's been automated through and through, one of the first things you do is un-automate it to... "Alright, what breaks? What's necessary?" It's part of the process. You just don't want to do it to begin with. Like, I'm all for automation, I'm all for systemizing things—I work in a system's brain—but I've also learned the discipline of ensuring that automation is something you do last, and systematizing it is something you do last. You make sure it works first.

The second reason was kind of a "buy versus build" approach to things. Before you go vibe-code a new system for your business—like some proprietary system—and that might be because you love coding, it might be because you love the dopamine hit of seeing something that you built work right away, or sometimes we do shit like this because we're creatively avoiding the shit that actually needs to get done. But before you go vibe-code your new CRM or your new PSA or your new ERP, whatever—stop and ask, "Should I buy or should I build?"

Building software right now is super easy. I just built my son a spelling bee app in like 40–45 minutes and it's a mobile app, it's pre-loaded with different voices, it's got all the words baked in, use it in a sentence... like, building that was easy. And it's easy to convince yourself that if something is built for you—like in our case, this platform—that it's going to be better because it's going to align with our processes and it's going to be tailored to exactly what we need, so by default it should be better.

But to do that, have you factored in the ongoing development costs? Have you factored in ongoing maintenance? And this is not even if you're selling the piece of software—like the changes that you're going to need to make as technologies evolve, which is doing faster than ever right now. And the software companies that are doing this really well right now, they have a head start, they have a massive head start. So say you're vibe-coding your new CRM, well Salesforce is out there developing, so is Close.io, so is HubSpot. These other big companies have huge development teams, they've got some of the best talent in the world and some of the best data in the world on what actually needs to be built and what doesn't work and maybe why it doesn't work. Well, that's effectively who you're competing with—again, even if you're building the tool internally.

And something a lot of people don't think about is when you build your own thing, you have unlimited optimality. Like, you can make that software do almost anything that you want it to do. Sounds cool, but unlimited optimality actually makes decisions harder, not easier. When you can build anything, deciding what to build is more challenging. When you have parameters, when you have boundaries and you have limitations, it can be really helpful—it can create focus. So if I want to make this thing work within the boundaries of the software that I bought, then at least I have some limitations to start with. If I can just custom-code anything that I want... oh my gosh, sounds cool, but optimality can be a trap.

Then you've got key-man risk, right? The person who built it is kind of the person that's got to maintain it. They understand everything. So you go run around and you've vibe-coded your PSA, you vibe-coded your CRM, you vibe-coded your CS system—all these acronyms—but you vibe-code all this stuff, but then whoever coded that gets hit by the beer truck tomorrow, then what? If it's you, well now the business is more dependent on you—not what you want. In my case, if it's my ops manager, well shit, now I've got to go hire a developer every time that I want to make changes to my processes.

So before you build, I would evaluate what is actually on the market, you know, go demo some stuff and see what is missing from the leaders in the space already and then determine, "Hey, does building our own thing that will fill the gaps—that will plug the gaps on that—is that a net-net positive and is it enough positive to offset the risk of everything sitting on your own platform?" Because what happens when Lovable doesn't get funding or what happens when whatever tool that you're using underneath goes bust? Are you prepared for all of that? So, buy versus build... I think the math in terms of comparing the best tool on the market and then what we've built, and you go, "Okay, yeah maybe there are some gaps, but are there enough gaps that it makes sense to go try to compete with them?"

The third reason is just opportunity cost. And this is the one that kind of seals the deal for me. Even if the buy versus build math works for you, even if building your own thing is marginally better, then the next question you've got to ask is, "Is this the highest leverage use of that person's time?" Of that resource that I have that can build that? And if you're technical, maybe it's you. In my case, it's not—it's my ops manager.

You know, so but here's the thing: I have an AI sales coach that I want developed. We, and I think there's a huge opportunity for it, I'm in a unique position to be able to leverage a lot of the data that we have, and we have other opportunities to incorporate AI throughout our entire business and into our offers and even what we sell. So was custom-coding a whole new CS platform for the customer journey—is that the best use of my ops manager's time? I would argue no, but we didn't do the assessment. We just think, "Hey, that's a cool tool, we should just use it." But no, there's an actual cost to that because it means something else is not getting done. And so I say it's not even close because I want the other shit done, right? There's more value in that and a lot of people skip that step. They go straight to "Can we build this?" to building it and they don't ever stop... "Should we be spending our time on this versus something else?" The marginal benefit that we get from proprietary software, is it enough to offset the gap from something established? Okay, is that still the best use of the time to close that gap? And many answers you're going to find that it's not.

So here's what actually happened: this wasn't a hard "no," it wasn't even a decision as we're talking about this with my team on buy versus build or opportunity cost. It was just simply: "Hey, before we jump in with this platform, we've hit pause. Let's go through the process, let's do what actually matters right now, let's fix the actual constraint." When we work through that, then we can start to ask: "Is this ready to automate? Is this ready to further systematize? Do we know enough about this process and how effective it is—not just from our standpoint by the way, from the customer's standpoint and from the delivery standpoint—do we have everything that we need to have the confidence that now's the time to lock it in?" Now's the time to focus on optimizing the efficiency and the execution of it instead of making sure it's the right process.

And then if so, as we start to do this, have we done our proper buy versus build evaluation? Have we looked at the various projects that we have on the list right now and what the opportunity cost is of doing that one versus the other one? And the answer to all three of these for us was no. So for now, we focus on implementing the process by doing it manually, or just run it, measure it, look at what's working, look at what doesn't, and then determine once we've got it dialed in, "Okay, now how do we systematize it? Now how do we automate it and then which platform should we be doing this on? And does it make sense to use our resources?" Those are the other questions that we would then get to, but it's not going to solve the constraint right now.

So that was a real-life example of how we're applying some of what I'm learning, what I share on the podcast, in my own business, and I thought it would be helpful to share with you. Hope it helps. Adios!