🐿️ Decision Point, Montana - The Insanely Profitable Tech Newsletter
Originally published 29th April 2024
On 3 June, 1805, Meriwether Lewis and William Clark climbed a hill and stared down at an uncomfortable choice. They and their 45-man expeditionary force were more than a year into an exploration of the recently acquired Louisiana Territory–land we know today as US states like Kansas and Nebraska, but which at the time was uncharted and unknown by people with white skin. Friendly members of the Hidasta tribe had told them to “follow the Missouri River” but had neglected to mention the division in the waterway the two explorers now saw below them. Should they take the smaller but deeper north fork, or the wider south fork that seemed to be going the right direction? With no guides, maps, or GPS to rely on, it seemed like an unresolvable dilemma.
What Lewis and Clark did next at Decision Point should inspire every one of you who fund, lead, or influence technology teams: they ran several parallel safe-to-fail experiments. They agreed on their goal—to decide which route was most likely to penetrate the nearby mountains and continue toward the Pacific Northwest. Then, in Lewis’s evocative but poorly-spelt journal, he recorded the imperfect indicators they decided to apply during their probes, estimating the “widths, debths, comparitive rappidity of their courants and thence the comparitive bodies of water furnished by each”. Next they sent small bands of three men each (entangled trios!) along the two rivers and up several nearby hills to scout the surroundings for a few hours. This added to their knowledge but not sufficiently to enable a firm choice, so they ran more experiments, splitting the party and sending larger forces out along each fork for a few days. Finally, when these groups returned with their assessments, it was clear to the leaders that the southern route was the more promising of the two. Proceeding in that direction, the expedition soon found the Great Falls of the Missouri and knew they’d chosen correctly.
Don’t delude yourself into thinking your tech team is proceeding along a clearly marked trail with milestones and “best practices” to follow. We’ve only managed to settle a few pockets of the vast realm of software engineering, and if you really reside in one of those frontier towns, you should just be buying Shopify or Salesforce or Outsystems, not writing your own code. If you’re reading this, then almost certainly you and your engineers operate in a domain that’s just as complex as that of Lewis and Clark’s Corps of Discovery, with unclear maps, conflicting directions, and inadequate tools–if you don’t believe me, ask them! Marching in a straight line, following “requirements” and working in rigid “sprints”, has no place here; instead you need fast iterations, frequent contact with customers, and above all, the psychological safety to treat an experiment with a negative result as a success. Would every member of your tech team say that deploying a broken code change to live customers isn’t an express ticket to a reprimand, but an opportunity for learning? For that matter, do you hold that belief? Could you?
This first appeared in my weekly Insanely Profitable Tech Newsletter which is received as part of the Squirrel Squadron every Monday, and was originally posted on 29th April 2024. To get my provocative thoughts and tips direct to your inbox first, sign up here: https://squirrelsquadron.com/
