Angus Mitchell
Flank Memos

Flank Memos

The Hierarchy of Internal Tooling Needs

Subscribe to my newsletter and never miss my upcoming articles

Written For: Tech Investor

I know this has all the smells of a non-sensical pseudo-intellectual overreach ("MASLOW? Have you heard of him?"), but it's actually a decent framework for explaining this problem that's popping up at tech companies.

Non-engineers need little bits of software ("internal tools") to do their jobs. By "non-engineers" I mean analysts, operations personnel, CSMs, and all the other people who keep companies running by fixing an endless stream of problems. (I hate "non-engineer", but I haven't found a better word.) Over the last 10 years, their jobs have evolved. The simplest way I can explain it is: read-only => read/write => execute.

Frame 1.png

I'll give you an example -- an operations worker at a logistics company. Call him Obie. Obie in Ops fixes all the problems that the computers can't fix on their own. If some truck driver fat-fingers a tracking number, Obie fixes everything behind the scenes.

Back in the stone age (say, 2010), Obie read tracking numbers off a screen. Then, he evolved. He started correcting tracking numbers. Now, he corrects them in sophisticated ways. This is what I call Level III.

Frame 3.png

It's not enough to update data in a spreadsheet or a database table. These days, Obie needs to run powerful programs.

There are two ways to think about this problem. One is to ask, "How do we empower the Obie to write powerful programs himself?" Normally that question is a codeword for, "How do we dumb down programming?" That's the world of drag-and-drop low-code tools. That line of thinking is a little utopian if you ask me. It presumes that everyone should be a software engineer. (An idea perpetuated by, shockingly, software engineers)

I'm attracted to a different approach: Let the code be written by the software engineer (he is, after all, the professional coder), and instead focus on streamlining every other part of the process.

Level III

Why, in 2020, are companies finding themselves at Level III of the Hierarchy?

Backing up... Most programs run automatically, either on a schedule or in response to another programmatic event. But in some cases, a human has to click the "Run" button. This happens when something goes wrong in the real world, and the non-engineer -- the guy living at the boundary of the real world and his company's IT systems -- has to fix the problem:

  • Flagging fraud in response to a payment
  • Correcting a datapoint in response to an earning release
  • Adjusting an ETA in response to inclement weather
  • Kicking a user off a platform in response to bad behavior

You think of tech companies as pushing further and further into the digital world. And this is true. But really, they're extending their tentacles in all directions, and that creates more contact with the real world. More exposure to that boundary.

Early internet marketplaces were hands-off (Craigslist), but those opportunities don't exist anymore. Now marketplaces have to interface with the world of atoms (AirBnB, Uber). Payment companies have always existed at the boundary, but now their tentacles stretch even further, tackling more complicated problems. The same is true of logistics.

Operational Graph.png

Flank

More and more companies live at the boundary. There, they find themselves at Level III on the Hierarchy. Unfortunately, there isn't an out-of-the-box solution to the Level III problem. So that's what we're building. We're calling it Flank, and it's simple. Flank gives non-engineers a "Run" button for programs in the cloud. It saves software engineers the hassle of building an interface for their teammates. And by providing an easy delivery mechanism, it unlocks second-order value -- rapid prototyping and tighter feedback loops. Check out our 1 minute demo video to see what this looks like.

Feel free to shoot me an email at angus@flank.cloud, or, if you want to chat, hop on my calendar!

 
Share this