Most internal tools have a turnaround time of “never”

Most internal tools have a turnaround time of “never”

Angus Mitchell's photo
Angus Mitchell
·Apr 29, 2022·

3 min read

Recently I talked to my friend who works at a Series C payments company. She told me that she needed a tool for cancelling loans. I asked her what the tool looked like. It was just a dropdown and a button. I asked her how long it took. She said that she approached the engineers in December and... still a work in progress. This conversation happened in February. Everything about this seemed completely normal to her.

Meanwhile, I was sitting there thinking to myself, “This is insane. Three months for a button? In those three months, you could have gone to coding bootcamp, learned to code, and the built the thing yourself.”

But the really crazy part is that we’ve talked to plenty of other companies, and this is par for the course.

Most Internal Tools Have a Turnaround Time of “Never”

I would actually go one step further: Most internal tools never get built. They have a turnaround time of “never”. And these are simple tools! Choose a user from a dropdown, hit submit. Run a query, send SMS to each of them. Query for payments, manually adjust a few rows in Excel, upload CSV.

So what’s going on here?

It's not a question of talent. You look at these Ops people and half of them came from BCG and Wharton. And the engineers can build these tools with a blindfold on. And yet, somehow, Ops feels like they can’t get the time of day from the engineers. And the engineers feel like Ops’ requests are poorly-scoped stabs in the dark that show no understanding of how anything works.

Ops Land vs Engineer Land

We need to pause and talk about Ops Land versus Engineer Land.

Ops Land: Excel and SQL queries.

You can do a lot in Ops Land. You can make charts, dashboards, even data pipelines. Tools like Metabase, Chartio, dbt, and Zapier have pushed the boundary of Ops Land deeper and deeper into Engineer territory.

But SQL can only take you so far. At some point a task becomes complicated enough that it requires an engineer to get involved. And that’s where Ops Land ends.

At the border — at that transition from SQL to code — you can feel the tension between Eng and Ops.

Ops: “I need a button to do the simplest thing”

Eng: “I got a three month backlog, buddy”

And the problem only gets worse as companies scale

Code Accessibility

"Data Accessibility" is all about pushing the boundary of Ops Land. It’s about taking something that’s only accessible to engineers and making it accessible to Ops.

Eng and Ops face the same problem with these simple internal tools. It's a question of accessibility. It’s not quite “Data Accessibility”... It’s more like “Code Accessibility”. But it’s the same idea — how does one empower Ops to build more on their own?

The Vision

Zapier for your internal APIs.

This is a collaboration tool between Eng and Ops. It's a tool that gets out of the engineer's way, but treats the engineer as the primary author of the building blocks. It empowers Ops to start putting the pieces together themselves, which gives them a better understanding of how everything fits together. This means that when they do go to engineers for help, their requests will be more targeted and better scoped.

code accessibility.png

 
Share this