There's Always a Customer

We ship some pretty crazy things when we think that customers aren’t watching. You’ve seen them: the mysterious scripts underpinning critical systems, or the Craigslist-chic GUI that gives the support team its superpowers. Take off the shackles of usability, security, and future support, and just see what we can build.

The results lend themselves to a fun little game that I like to call “spot the root cause.” The rules are simple: when you encounter an internal tool, ask yourself “why?” When you finally track down an answer–likely an internal-only interface buried a bit deeper down the platform–ask “why” again. Keep unraveling the thread until you arrive at the original, distant-past decision marked “for internal use only”. Well done! You’ve spotted the root cause.

Three Little Costs

If we know where the journey ends, why embark in the first place?

Internal-only has its allure. When we stop building with customers in mind, we can cut corners and develop at a breakneck pace. But “quick and dirty” has a nasty habit of auto-correcting to “unusable, maintenance-deferred.” Only later do we recognize the unexpected costs that a cavalier approach to quality tends to incur.

The first we notice is time. Even hacky programs take time to write and debug, let alone (perish the thought) to maintain. Next come their users, ticking away the minutes frustrated by quirky interfaces and the complete absence of documentation. For developers and customers alike, time spent wrestling against arcane tools means less time delighting customers, shipping world-changing products, or watching the kids grow up at home.

The second cost is reuse. Internal tools don’t break customers, and–in the best case–the internal ecosystem can be a valuable incubator for new technology. It’s important, however, to recognize the distinction between a tool used internally and one built for internal use. Is the tool maturing with an eye to eventual generalization? If not, it will eventually need to be thrown out and rewritten.

But the biggest cost of building for internal use are the opportunities that get shut out. Every tool is a potential product. It addresses a problem shared by at least one of the other seven billion warm bodies heating the atmosphere. Sharing isn’t just a nice thing to do: it’s also potentially lucrative (in social capital, if not revenue). Few of us are going to follow Tiny Speck and drop everything to follow an internal tool, but neither should we ignore opportunities our own needs uncover.

A Little Respect

Foregoing internal tools doesn’t mean a blank check to prototype in production. It’s simply the recognition that everything has a customer. We don’t have to be fanatics about it (it works for Amazon, of course, but then most of us aren’t Amazon) to reap the fruits of a little self-respect. We wouldn’t sell a lousy tool to our customers, so why inflict it on ourselves?

The next time you win a game of “spot the root cause”, take a good hard look at the problem unraveled before you. Could someone else’s open-source tool obviate it? Or could this be the start of a solution to someone else’s problem? I bet it could.

Let’s make it official. Here are some nice, shiny digital stickers ready for the sticking on your (proudly) open-source tool. Use them anywhere!