The Tech Team Isn't Your Problem. Dependency Is.

There's a vending machine I still think about.

I was managing IoT vending machine operations about 10 years ago. Part of the job was calibration. And calibration meant going through each machine, adjusting each component, one part at a time. It was slow, repetitive, and consumed an entire day every time we had to do it.

The frustrating part wasn't the time. It was that the pattern was obvious. Anyone who had spent enough time around those machines could see it. The calibration sequence wasn't random. There was a logic to it. And if there was a logic to it, there was probably a way to automate it.

I raised it. It went into a list. The list went into a backlog. The backlog went nowhere.

So I did something about it myself.

I knew some Python. Not good Python. Broken, Googled, Stack Overflow-stitched-together Python. I spent weeks in failure cycles, getting error messages I didn't understand, fixing one thing and breaking two others. It was not a clean process.

But eventually, something worked.

Calibration time dropped from a full day to about an hour.

Not because the tech team finally got to it. Because the person closest to the problem got tired of waiting and figured out just enough to fix it.

The Queue That Never Moves

I've spoken to enough ops managers, founders, and business leads across India and the Gulf to know that my vending machine story isn't unique. The details change. The frustration doesn't.

The internal tool that's been "in the pipeline" for eight months. The approval workflow that still runs on WhatsApp because the proper system never got built. The report that someone manually compiles every Monday morning because the dashboard was deprioritised two sprints ago and never came back.

This is the reality of how most businesses operate. And it's not because anyone is incompetent.

Tech teams aren't lazy. They're just playing a different game. Their priorities are shaped by OKRs, by roadmaps, by what leadership can point to in a board update. Customer-facing features move metrics. Internal tools don't show up on anyone's scorecard. So they wait.

Meanwhile, the ops team builds workarounds. An Excel sheet becomes load-bearing infrastructure. A WhatsApp group becomes the de facto approval system. Institutional knowledge that should live in a tool ends up living in one person's head, and when that person leaves, it leaves with them.

The people who understand the problem most deeply have no ability to fix it. And the people who have the ability to fix it are busy building something else entirely.

That's a structural problem. And for a long time, there wasn't a clean way around it.

What's Actually Changed

When I cobbled together that Python script 10 years ago, I was an outlier. Most people in my position couldn't have done it, and honestly, most people shouldn't have had to. It took weeks of painful trial and error just to produce something barely functional. The barrier to building anything was high enough that most people correctly decided it wasn't worth trying.

That barrier is gone now.

AI-assisted development tools have fundamentally changed who gets to build software. You don't need to know Python or JavaScript or how to set up a development environment. You describe what you need in plain language, and the AI helps you build it. Not a prototype. Not a rough sketch. A working tool.

The procurement manager who needs a vendor tracking system. The HR lead who needs an onboarding checklist that actually connects to their existing tools. The ops analyst who needs a live dashboard instead of a weekly Excel report. These people can now build what they need, in days, without writing a single line of code themselves.

This is not hype. This is what's happening right now in teams that have figured it out.

But Here's Where It Gets Serious

When more people can build, more things get built. And not everything that gets built is built well.

There's a version of this story where the democratisation of software development is an unqualified good. Everyone builds what they need, tech teams are freed up for the complex work, and companies become more agile. That version is possible.

There's another version where people build tools that handle sensitive data with no access controls, where a script a founder wrote at midnight is running on live customer records, where nobody knows who owns a tool or what it actually does.

That version is also possible. And it's already happening.

Spider-Man's uncle put it plainly. With great power comes great responsibility. It's a line from a comic book, but it's the right frame for this moment.

Building your own internal tools is now genuinely within reach for non-technical people. That's exciting. It's also a reason to be thoughtful.

Here's what building responsibly actually looks like in practice.

Know what data your tool touches before you build it. If it's touching customer records, financial data, or anything sensitive, that needs proper access controls before it goes live. Start with read-only tools, dashboards and reports, before you build anything that writes to a database or sends communications.

Loop in your IT or security team, not to build it for you, but to review it before it goes live. Their job shifts from builder to reviewer. That's a reasonable ask and it protects everyone.

Document what you built. What does it do, what data does it touch, who has access, and who owns it when something goes wrong. If the answer to that last question is "nobody", that's a problem worth solving before you launch.

And treat it like a product, not a one-off project. It has users. It will break. It will need updates. Someone needs to own it.

None of this is complicated. It just requires intention.

Stop Waiting for the Queue

The tech team was never really the answer to your operational problems. They were just the only option you had.

That's no longer true.

The ops leaders, founders, and business builders who figure this out, who learn to identify their own problems clearly, build solutions quickly, and do it responsibly, are going to have a real advantage. Not because they've become developers. But because they've stopped being blocked by a system that was never designed with their problems in mind.

Ten years ago, I spent weeks struggling through broken Python to save one day of work. It was hard, and messy, and I was one of very few people willing to try.

Today, that same solution would take an afternoon. And you wouldn't need to know a single line of code.

The tools are ready. The question is whether you're willing to pick them up.