The fail-fast idea is the iterative prototyping of our time, though I find the older term preferable. Implicit in the failure idea is that you succeed now and then, and it’s only to get to the successes that we seek fast failure. If it ain’t gonna work, let’s be done with it and try something else.
This brute force approach feels familiar because it’s human nature. Winston Churchill made that point when he told aides, “You can always count on Americans doing the right thing — after they’ve tried everything else.”
It was a left-handed compliment because, welcome as getting the right solution was, the approach was often extremely wasteful. Any entity without nearly infinite resources would quickly discover that it couldn’t simply reset the bowling pins just to knock them down in a new way.
Something happened between Churchill’s time and today that makes trying “everything else” more acceptable, and it is seen very clearly in technology development. In software, generally, and CRM very specifically, we’ve routinized experimentation through iterative development, and getting it wrong is now nearly free.
We use codeless definitions to specify business processes and the systems to support them and let code generators do the heavy lifting. It’s not like we’re building the records management applications that ran life a decade or two ago.
These generators bring together process flow, multiple data sources, and, most importantly, integrate machine learning and intelligence engines that elevate routine data management into information delivery and manipulation assistants.
That’s all well and good, and these technologies have been around for a while in forms that have become increasingly easy to use while lowering costs. They have made a significant contribution to making the cost of experimentation nearly free.
Along the way, we’ve also discovered that even when we’re wrong, we rarely see complete failure. Instead, we see bottlenecks that can be fixed in the next iteration that can happen as soon as making a change to some definitions and clicking on a button.
Still, there’s great inertia in the technology customer base to adopt the technologies that enable all the fast failure. Some of this might be semantic or at least cultural. Who likes to earn a living based on failure or to report a failure with a positive spin to the boss?
Certainly, the economic upheavals of the last few years have made us more attuned to the need to experiment quickly with solutions that match the demands of the moment. The shift to working from home/working from anywhere certainly put our rapid development tools to the test.
One of the more impressive efforts happened at Salesforce, which shelved most of its planned development agenda at the beginning of the pandemic in favor of building applications for the moment.
It was a great effort that showcased the inherent power of its platform. But Salesforce was not alone, and among the companies I work with, like Oracle and Zoho, there are similar stories.
Resistance to Change
Now the question becomes: Why isn’t everyone doing development this way, and why aren’t we all redeveloping our systems using new platforms that will enable us to shift our businesses on a dime? Two reasons come to mind: (a) we don’t perceive the need, and (b) there’s an inherent resistance to trying new things, even in tech
No doubt there are business processes, especially in the back office, where the rate of change is low, so applying the new technology won’t do much good. But resistance is a genuine concern and not because organizations don’t want to make the effort. It’s that they can’t, or they think they can’t: they don’t have time, budget, or whatever.
That resistance makes up a core of latency in every marketplace — latency that gets motivated by some often unpredictable event that can cause a stampede. A heretofore-unknown virus strikes the world, and we suddenly must reconfigure the ways we have worked for decades. But such blindsiding is the exception, believe it or not. If you know what to look for, you can often see a challenge coming from a long way off.
Even in CRM, where the zone has been flooded with applications, we still see far-off challenges, and we still reach for spreadsheets instead of modern development tools to plug a hole.
This was brought home to me about a year ago when I read a report from McKinsey in a related field. The report showed that most organizations surveyed used spreadsheets to do supply chain planning and that the dominant application for the purpose, from SAP, was already scheduled to sunset.
Confront the Spreadsheet Mentality
Perhaps the recent pandemic put such a strain on those supply chain spreadsheets that many organizations have teams building modern applications to plug that hole. Maybe others are content with what they have, waiting for some lousy scenario to play out before they act.
But the supply chain is just one tiny aspect of business IT these days. The questions begged here run along the line of: Is the spreadsheet still your favorite application development tool? Should it be?
We put spreadsheets to use when there was nothing else, and without databases behind them, they have marginal utility though we keep turning to them. The truth is that we don’t know what the next information challenges will be to our businesses, and there will never be a better time to prepare.
Ditching spreadsheets for more modern technologies that will enable the fast-fail rapid iteration that business demands today would help all of us to customize further the process support we took out of the box a while ago. It will also help us fail fast if you’re into that kind of thing.