The Tool Doesn’t Do That. Now What?

One of my greatest joys at work is hearing “it can’t do that,” asking “but what if I…” and watching the answer turn into “well, yeah, that would work.”

Insert chaos energy. 🧚

This started with my first boss, who basically didn’t let me say “I can’t do that.” Sometimes to an extreme. I wouldn’t recommend every part of that management style, but the resourcefulness stuck.

My first version of vibe coding

I needed to turn GoldMine CRM data into a prioritized list of who to call.

So I learned old-school SQL queries and built call lists in Excel with VBA prioritized by relevant CRM data. My introduction to coding was recording macros, looking at what Excel generated, and figuring out how to make it do the next thing. Early vibe coding, courtesy of the Record Macro button.

Eventually, I had to learn how to limit the processing to seven CPU cores so the rest of my computer could still function.

Because apparently I also needed to use my computer while my creation was doing its thing.

The business needed a way to prioritize calls. I learned enough to build one.

The part where RevOps judges me

At another company, I used Salesforce Leads as a call tracking tool, with intentional duplicates.

I can hear you opening the comments. Stay with me.

I came into that implementation late. A lot of the work had already been built around Leads. It wasn’t necessarily the structure I would have chosen from the beginning, but it was the situation I inherited because I had done something similar at smaller scale.

So I leaned into the existing decision. A duplicate lead functioned as a “calling card.” Once it had been worked, we merged it back into the corresponding contact using RingLead.

Would I prescribe that architecture for every team? Absolutely not. There were tradeoffs. But judging the choice without understanding the implementation already in motion misses a pretty significant part of the story.

Sometimes your job is to make a deliberate decision about what you can use, what you should change, and what needs a cleanup step.

Sometimes the answer needs another tool

Right now, I’m implementing Intellistack. Secure file uploads were a requirement, and it gives me that capability.

I’ve also run into limitations. In the workflow I’m building, it can extract the data I need from PDFs, but it doesn’t handle the other file types I need the same way.

My planned next step is a Python script to convert those files to PDF, then pass them back to Intellistack for extraction. I still need to build and test it.

The limitation gave me another step to solve.

I often gravitate toward less popular tools that fit how I think and give me room to build. Flexibility matters to me. So does understanding where the tool’s responsibility ends and where I’m taking on more of it myself.

Best practice still needs context

Best practices are useful. So are questions.

What does the business actually need? What has already been built? What risk are we accepting? Who has to maintain this thing after we make it work?

I’ve learned to keep asking those questions when the standard answer falls short.

“The tool doesn’t do that” tells me something about the tool. There’s usually still a conversation to have about how we get the work done.

And yes, I will probably arrive at that conversation with some chaotic energy. But I'll make darn sure the business gets what it needs doing, done.