A Taxonomy of Internal Tools
(If you haven't read the high level overview, Simple x "Never" = Insane, you might want to start there.)
A Taxonomy of Internal Tools
Most definitions of “internal tools” are too broad. The typical definition is something like “bespoke software to support internal operations”.
But what about tools that…
- Trigger deployments
- Show month-over-month revenue
- Automatically run payroll every week
Technically, all of those examples fit the definition, but I don’t think anyone would consider DevOps, simple dashboards, or backend code to be “internal tools”.
"Ops-in-the-Loop Apps"
We need three additional criteria:
- The end user is a non-engineer (Ops or CSMs)
- An engineer is required to build some part of it
- It’s not completed automated
It’s a mouthful, but it would be more accurate to call these tools "Ops-in-the-Loop Apps"
A Moving Target
Consider that:
- Once a task can be completely automated, the engineers automate it, and it ceases to be an "internal tool".
- Once a task can be solved by an off-the-shelf product, everyone starts calling it “that Metabase dashboard”, and it ceases to be an internal tool.
So "internal tools” are a moving target. They exist at the ephemeral boundary between Ops Land and Eng Land. They provide a solution for problems that are a pain to automate, but can't be done completely manually either.
The Hierarchy of Internal Tooling Needs
Where is that boundary now? Roughly, where the task outgrows SQL and has to be solved with a little bit of python or live behind an API endpoint. That’s when the engineer gets roped in.
I think about Ops’ needs like Maslow’s Hierarchy. A Hierarchy of Internal Tooling Needs, if you will. Right now, most “internal tools” live at Level II of the hierarchy, but they’re pushing into Level III.
As the off-the-shelf tools tackle more and more problems, the business (and, by association, the Ops department) looks to tackle problems that, while conceptually simple, are slightly too complicated for SQL.
