The technologist’s classic blunder

Engineering types like software developers are inspired by a sense of the possibilities inherent in building things.  This inspiration is forever leading them into a classic blunder that offers up hardship and regret—and an opportunity to learn a powerful lesson.

Interestingly, this problem is not a technical one, but rather a mindset. 

The blunder

This blunder may be the single greatest source of failure and disappointment in the work of software engineers and other technical types.  Not long ago I rewatched the classic movie, The Bridge on the River Kwai and was amazed to see the mental error enacted by none other than Obi Wan Kenobi actor Alec Guinness.  In honor of this, I’ve taken to thinking of it as the Bridge on the River Kwai problem.

The error in question is the tendency to undertake technological efforts without their proper context, allowing them to become ends in themselves.

This seemingly innocuous proclivity is frightfully pernicious.  As you’ll see in a moment, it is harped on relentlessly by successful founders, who have learned the lesson through painful experience. 

If you can learn to spot this happening in yourself or others, you can head it off and spare yourself a lot of suffering.  Perhaps.  Maybe if you’re a dyed-in-the-wool coding type, it’s a thing you really just have to go through to learn. 

If you do find yourself at the tail end of this experience, bemoaning the lost time and effort, be heartened:  You are in really good company.  You learned a lot of skills.  You have mastered the core lesson: pay attention to the end user, always.

Even if you already know the problem, it always helps to remember.

Steve Jobs fell for it

Just in case you think I’m exaggerating the kinds of people who fall prey to this blunder, here is Steve Jobs talking about doing so himself.  He says, “you’ve got to start with the customer experience and work backwards to the technology…. You can’t start with the technology and try to figure out where you’re going to try to sell it. And I made this mistake probably more than anybody else in this room. And I got the scar tissue to prove it.”

Scar tissue.  That’s pretty graphic. 

I can readily empathize with the wounds.  I’ve fallen prey to the River Kwai blunder in ways small and large.  I’ve walked off as a coder too far from the business needs on some projects, attaining technological excellence that did little to validate its cost. 

I’ve wandered far off into the wilderness as an entrepreneur with an idea, only to finally stop, look around and wonder: Where am I?  How can doing so much good technical work lead to such disappointing results?

Once you are enraptured with the possibilities inherent in an idea, and you start feeling the gap close on the ability to actually pull it off, it’s easy to just sit down and start making it happen. 

There’s nothing inherently wrong there … yet.  It’s good and right to take action immediately on inspiration.  One of the greatest success thinkers of all time, Napoleon Hill, points at the importance of taking action: have an idea, take action, keep trying based on what happens.  That’s the core formula.

But as a builder of software, you must find a way to incorporate the feedback from users, living human customers, into the third phase of the cycle.  You should hold it in your head, and you probably need a partner who can do it better than you.  You must validate that you are building something people really need.

If you don’t, you’ll start building elaborations that aren’t warranted. You’ll fix bugs that are unimportant.  You won’t really know if your original idea was a good one.  Maybe it was.  Probably it was, if you’d fine tune it with some feedback. 

An archetypal journey

Steve Sewell, founder of Builder.io, in a recent talk we had made this point in offering tips to startup leaders:  “The primary one from my learnings is: Be religiously obsessed with customers.”

He went on to mention the entrepreneurial classic Lean Startup, whose core premise is formalizing the customer feedback loop into the essence of the business. 

It’s worth looking further at Steve’s story. It’s illustrative, archetypal really. 

“I left my job and started working on [the project]…. I put a whole year into it and I had built various versions…. I picked my head up in December and I started showing it to potential customers … I realized within about 10 minutes that I had missed the mark in a couple of huge ways … foundational decisions that I made so early on were not going to work … this was going to be a non-starter … they’re not going to adopt the product. It’s not what they need.”

I heard what Steve was saying and I thought: yeah.  A subdued, knowing yeah. 

“I was so disappointed and I only had another year of runway … only one more shot at not making that mistake … I decided I’m doing this fundamentally differently. I’m going to do the tiniest thing to get it in somebody’s hands, and I’m not going to do a single thing until they tell me they need it.”

And I thought, “YES!”  There’s the founder’s rebirth and redemption. 

You can see the outline of the whole process unfold right there: got idea, got excited, got to work, forgot to validate, got burned. 

Why do engineers DO this?

The reality is, if you are a coder, you probably just plain enjoy coding.  You have an association of pleasure with confronting imposing technical challenges and overcoming them.  It’s a bit of an addiction, really. (This addiction is the source of other issues: I’m looking at you, work/life balance).

This isn’t to deny that the ability to focus, and focus intensely, with a kind of exclusionary attention isn’t useful at times.  It is.  Especially in working through thorny technical brambles, we sometimes need that superpower, it really is the only way through.  But we have to keep that work harnessed to the greater context and purpose.  We must repeatedly assure ourselves that we are bushwhacking towards the peak, not the precipice.

Going off-piste can deliver some valuable skills and experience, including, prominently, how to avoid it in the future.

Build backward from the experience

Guillermo Rauch, Vercel’s founder, echoes the importance of staying on target when he says  “we have always been very focused on the customer experience. We built backward from the ideal experience that we knew developers wanted.”

As a serial founder, we can imagine that Guillermo has had this lesson worked deep into his entrepreneurial DNA. He highlights the customer experience as a key component, and I’m going to say with confidence that this focus is a chief driver in Vercel’s rapid success. 

As an engineer, now hear this: it can be just as much fun to build something that people really are using as a purely engineering project. And, it’ll keep the VM’s online while you do it!

Really, you want people to use what you’re building.  Users are not just a frustrating distraction.  You must find a way to incorporate them into your bubble of technical fascination.  Don’t be Hendrix in a basement never playing out.  Set your guitar on fire at Monterey.

Back to the bridge

Spoiler alert:  In the movie The Bridge on the River Kwai, a group of British soldiers is captured by the Japanese during the WWII occupation of China.  The prisoners are tasked with building a bridge to aid in supplying the invaders.  One of these prisoners is an officer named Nicholson, played by Alec Guinness.

Naturally, the British soldier’s main objective is to survive and resist the occupiers.  They are prisoners of war in a gruesome conflict; building the bridge is a project counter to these efforts.

In spite of this, the purpose and meaning bestowed by the bridge exert a power over Nicholson.  It gets to the point where some of his fellow prisoners are in a position to sabotage the bridge, and he acts to prevent them.

Of course, our typical software founder or engineer isn’t faced with quite such stark and perilous circumstances.  In the case of the movie, maybe the ideal bridge is one that is built just slowly enough to prevent reprisal, until help arrives.  The bridge isn’t the point; its requirements are.  It is a means to an end, like all technology.

In the last moment of the film, Nicholson kills his fellow British officer and suddenly comes to his senses.  He utters in disbelief, “What have I done?”

He fell prey to the most classic engineering blunder of all time: putting the engineering ahead of all else.