The Hungry Man Parable

I talk with lots of executives from the go-to-market side of the house who think that building serious software is as easy – and easily estimatable – as building a fence. Would that it were so.

One destructive side effect of this misunderstanding can be repeatedly changing the #1 top priority part-way through development, before there’s much to show the world but after spending significant discovery/design/architecture/development time on the previous #1 top priority. As the leadership team gets tired of interim progress reports and longer-than-expected delivery dates, they lose heart and lose trust in the “maker” side of the company. So something new becomes the #1 top priority. Scattered around the development shop are stacks of partially completed projects not being worked – aging from neglect. And $M’s wasted as we repeatedly spend scarce talent getting to half-done.

This is a difficult framing issue, which can reinforce deep-seated beliefs that engineering organizations don’t work hard, are flagrantly inefficient, or need more oversight. (Which usually makes things worse.) It’s a particularly bad strain of Dunning Kruger where engineers think selling is easy, salespeople believe enterprise software is just a SMOP (small matter of programming), and non-tech execs expect that making software is like making sandwiches.

How to communicate this? In the right setting with the right audience, I’ve been telling this fictitious story…

THE HUNGRY MAN PARABLE
A hungry man is on a street full of restaurants. Walking into the first restaurant, he is told of a 20-25 minute wait for a table. After 10 minutes, he’s even hungrier and loses patience… walking out and going to the restaurant next door. They also have a 20-30 minute wait for a table. After 10 minutes, he again loses patience and leaves… Eventually, the man dies of hunger.

Compiling the list of a company’s half-discarded initiatives can highlight that we’re busily cooking even though nothing nutritious gets served to our customers. (“Remember A and B and C and D that we dropped midway?”) Our digital compost bins are full of decomposing software.

Cost-Highlighted Variation

The cost to our company is more than failing to deliver some promised feature. We’re systematically spending the scarcest resource on the planet – the focus of our overcommitted-but-gifted engineering organization – on work we may abandon half-way through. If a development team costs $1M/year, then we’re wasting increments of $100k. And ignoring the opportunity cost of not finishing some other critical piece of work.

THE HUNGRY MAN PAYS IN ADVANCE
Our hungry man walks into a restaurant, orders a meal to go. And pays for it up front. Meal should be ready to take away in 15-18 minutes. He thinks that to-go orders should only take 6 minutes, though. After 10 minutes, he walks out in frustration: money spent, time lost, and still hungry. On to the next restaurant, next to-go order, and next written-off expense.

I’ve found this retelling useful with CFOs and others who worry about the cost of development as much as the value of products delivered. We can shift from “why is R&D so expensive” to “how do we reduce our decision-making waste?”

Build-Versus-Buy Variation

I’ve seen dozens of companies refuse to license off-the-shelf SaaS for generic non-strategic capabilities in favor of ill-conceived DIY projects. Rather than focus their (always too small) development teams on a few strong strategic differentiators, they dilute their effort building in-house versions of robust commercial products.

The biosciences startup that knocks together an SMS gateway… the training consultancy writing its own content management system… the ERP company convincing itself that Jira/ Asana/ Pivotal Tracker/ VersionOne/ Monday/ Aha!/ Wrike/ productboard/ Kanbanize/ etc don’t perfectly meet their needs, but whose devs whip up an unsupported bare-bones ticketing system over the weekend.

Often, this is driven by one outlier feature demand that’s tiny relative to building a commercial product from scratch. (“None of the major hosted email providers gives us delegated authority to set regional policy around four-factor authentication. So we can’t use Gmail or Office365 or ProtonMail. Bet it’s not hard to build our own.”) But they forget that matching those commercial products feature-by-feature will take years, requires a dedicated team forever, and ignores economies of scale: Twilio has thousands of smart people providing a complex communications infrastructure that you can use for less than 1¢ per SMS.

We might take a lighthearted storytelling approach to get that point across:

DEMANDING A SPECIAL INGREDIENT
Our hungry man walks into a fancy-casual burger restaurant that has 60 variations of beef, chicken, tofu, turkey, gluten-free and Impossible-burgers. But he’s heard that emu meat is healthier and tastier. Negotiating with the server isn’t successful. (“Hey, I’ll pay $600 for an emu burger. Just fly one of the kitchen staff to Tasmania and bring some back. I’ll wait.”) Frustrated and still hungry, he decides to invest in his own restaurant chain featuring emu burgers. Since he’s an anesthesiologist, not a restauranteur, this will be quite the learning experience.

Know your audience, though. Not everyone loves analogies or shaggy dog stories. Others may miss the intent, grab the food metaphor, and want developers to have exact recipes or fully priced-out ingredient lists before starting every new project. After all, making software is just liking cooking dinner – and my kid has mastered mac-and-cheese, so should be our next microservices architect.

Sound Byte

On the product/development side, we know how important it is to start fewer things and stick with them until we finish. Rapid priority shifts are expensive and demoralizing. But that may not be a native concept for some on the go-to-market side. Look for diverse ways to frame issues in ways that your audience will understand. (And share a meal with them when you can.)