Kitchen Drawers, Clayton Christensen, and Beta-Testing Your Internal Tools
Written For: Engineering Managers
I used to be pretty smug about internal tools. I was an early adopter of Retool, so, you know, I was a connoisseur of sorts.
Then, to my surprise -- and joy, but also disappointment when I realized how dumb I was (ugh, again??) -- I discovered people who were building internal tools at a totally different level.
Obie in Ops needs an internal tool.
Enrico the Engineer writes the business logic to solve the problem. He deploys his code, but now he has a problem: how does Obie access the program?
(Note: I'm using "Ops", but Obie could be any other breed of non-engineer -- Analyst, CSM, PM, whatever)
(Second note: When I say that Enrico writes "business logic", I'm talking about a runnable program. Anything ranging from a serverless function to an API endpoint to a script in a container.)
If you had asked me a year ago, I would have said that Enrico has three choices.
- Do nothing
- Build an interface
- Stash it in an existing interface
Since then, I've talked to a lot of companies about how they build internal tools. Some are worse, some are better. As you'd expect, a lot of the variation is explained by whether or not the company has their shit together.
So, as someone who thought they had their shit reasonably well together, I was surprised to discover outliers -- companies that are way better at building internal tools. They have an entirely different way of thinking about internal tools. One that identifies the problems with the status quo and (keep reading) presents a better alternative.
|Option||Doesn't Scale Because...|
|Do nothing. When Obie needs it run, Enrico will manually run the task||If the company grows, Enrico will find himself underwater with requests|
|Build an interface||Obie will be overserved/underserved|
(I'll explain below)
|Stash it in an existing interface||Creates tech debt in the "kitchen drawer"|
(I'll explain below)
Look at the situation from Obie's point of view. Most of the time, he wants a tool as quickly as possible. He doesn't want the interface to be a total dumpster fire, but it doesn't need to be a piece of art either. The exception is that one tool that Obie uses all the time. That tool actually deserve a nice interface.
At most companies, Obie does not get what Obie wants. To borrow Clayton Christensen's terminology, he's either underserved or overserved.
Overserved: The company builds a beautiful internal app for every single tool. Great, but Obie doesn't care if the interface is a 6/10 or a 10/10. He just wants access to the tool as quickly as possible.
Underserved: The company stuffs new tools wherever without a second thought. They never upgrade anything and the user interfaces are a disaster. Obie's workday is a slog through confusing interfaces.
Learning From the Best
They're rare, but I've talked to companies that have two interfaces for internal tools. I'll call them the Minor League interface and the Big League interface. The Minors interface is quick and dirty. Engineers use it to put internal tools in front of Ops as quickly as possible. (At one company, this interface was a Slackbot.) The Bigs interface is a custom-built website. It is reserved for the most important tools.
Back to our boy Enrico. After he deploys the code, he delivers the new tool to Obie using the Minor League interface. Obie uses it for two weeks. The interface isn't great, but he and Enrico are still working out the kinks, so it's not a big deal. After a month, it's obvious that this tool is important. This tool gets promoted to the Bigs, and Enrico polishes it.
Under this system, Enrico doesn't waste time on stupid tools. Obie is no longer over/underserved. Obie is properly served.
Tech Debt in the Kitchen Drawer
Next question: How does Enrico organize the long tail of Minor League tools? Keep the answer in mind. Now ponder another one: How do you organize the long tail of tools in your house?
For most companies, the answers to the two questions are the same:
That drawer didn't start out as a mess. It started out as 1 pen and 1 chapstick that didn't belong anywhere else in the kitchen. Then the next random thing went in there, and then the next one...
Software is no different:
Enrico: "In a perfect world this would be deployed as a serverless function, but you know, we have that internal site wired up to that API, so screw it, I'm just gonna stash this script in a new endpoint and call it
/internal/random/run-report-generator. We'll figure out a better solution later."
Then, that happens 100 times, and boom! You have your kitchen drawer.
Kitchen drawers create technical debt. In the example above, the script belonged in a serverless function. Enrico shoehorned the code into an API endpoint. Why? Because the backend isn't really decoupled from the front end. There is enough setup, configuration, and glue code to make the API the path of least resistance.
Flank Is a Beta Testing Platform
What is the perfect setup?
- Two interfaces: Minors and Bigs
- Measure usage. Only promote the most important tools.
- Keep the Minor League "drawer" organized by decoupling the interface from infrastructure
- Easy-to-use interface for our poor friend Obie
Hopefully you see where this is going. We're building an out-of-the-box Minor League interface. Flank (that's the name of it) gives Obie a "Run" button for programs in the cloud. It saves Enrico the hassle of building an interface.
(Hey Angus, uhhh, this is your subconscious, listen, maybe you shouldn't use an analogy that compares the product to the Minor fucking leagues? Emphasis on word "Minor". Just a thought. Okay, point taken, but I'm just being honest, and the fact is that engineers don't want to waste time on the Minors. They have more important things to do! Also, if it makes you feel any better, Flank has an awesome interface, so it's better than the Minors!)
Flank also solves the kitchen drawer problem. It abstracts over infrastructure, turning all code-running services into "tasks". Serverless Function? Container? All equals in the eyes of Flank. That decoupling (plus a well-designed interface) keeps the kitchen drawer organized.
Put it all together, and what you have is a beta-testing platform for internal tools. Enrico deploys, and Flank immediately delivers the program to Obie. Flank measures usage. Usage informs Enrico's priorities. It's a better way of building software. One with tighter feedback loops:
I owe the kitchen drawer analogy (and a very clear articulation of the value prop) to the one and only Tim Getsch