The recent “failed IPO” of BATS has to be a cautionary tale. This wasn’t just a deal that didn’t price or trade according to plan. A software bug caused it to be withdrawn. You don’t hear that one too often.
A bug killed an IPO?
There is no argument that we live in a world of staggering speed, where competitors race to meet customer needs and time to market matters. Innovation is always factored by the ticking click, who gets the jump and the competitive advantage, when a cost center becomes a profit center. Information compounds on our desktops, the team with analysis paralysis most often loses to the nimble risk takers—but all this means is that in product development, the role of Quality Assurance (QA) has never been more critical.
I have often heard the mantra from development teams: “Better, Faster, Cheaper—we can give you any two and a half.” Believe me, I understand trade-offs. All product development is tempered by tough decisions that incorporate a series of smart and well-balanced quid pro quos. You want to cut the budget, give us more time or expect fewer features. You want to tighten the schedule, give us more capital or reduce the scope of benefits. You want an industry defining product, show us the money or don’t ask for a date.
Surely these threads have become clichés, and as such, they are not without some underlying truth. There are even schools of thought that proclaim speed over accuracy is the game-winning formula, entire companies built on this premise, hugely successful in their own right. Yet when the Decision Maker, whoever that is, makes the call to greenlight a software or product release, another question comes to mind: Is the call transparent or opaque? Said another way, are the risks inherent in the release from staging to live known to the Decision Maker, or is that person flying blind?
If the release is going live with known issues, that becomes a business decision with acknowledged acceptable risk. If a showstopper issue exists but is unknown to anyone, well, I don’t think I have ever seen that case in a going concern. If the release is going live with issues known to others but not the Decision Maker, that is a dysfunctional process, possibly the beginning of the end.
Here is the way I like to think about quality in product development: Quality Assurance is a Process, not a Department.
Like so many of the great lessons I have co-opted in this blog, this first became clear to me in hard-won experience with the magnificent QA Directors with whom I have worked over the years (several of whom reviewed this post in draft prior to publication), and second in Jim McCarthy’s brilliant book Dynamics of Software Development first published in 1995 and still a must read for any of my teams—non-tech even more than tech staff. The most critical constant of which I am aware in delivering great products to market consistently is for Quality to be owned by everyone involved in innovation—from designers to developers to marketers to feedback from end-users.
Of course every great development company will have a final step in the process called Quality Control or Quality Assurance, but it is my sense that the QA formal group is there to be the standard-bearer for Quality and rally the company around it, putting a final go or no-go procedure in place before the world gets its hands on a product, but not accepting proxy status for an otherwise poor process. A QA department is not a dumping ground, not a remote server where code is parked as a step function or convenient checkpoint in a perfunctory release approval, not a cynical target of blame. QA is the proxy for the customer, not management, and as such must have a voice that is shared throughout a company. If a Decision Maker chooses not to listen to either the process or a warning from fully objective and independent QA stewards, you get what you get.
I have always been enamored with QA teams, for their passion, for what they teach me, for how much they care about excellence. When QA is wound into the culture of a company, it is often because of the mutual and shared respect an organization has for the value of Quality as an intrinsic good that will most likely yield extrinsic rewards, but carries reward for itself in the form of realized creativity and pride. It is very hard to fake a love of Quality, and this applies to much more than software. Quality is a path to premium brands cautionary tale and premium prices in a landscape where speed and disseminated knowledge can commoditize just about anything if you let it. Quality is won when it is broadly embraced as a shared value, and then championed by a high energy team that inspires its adoption at the highest levels of management and all through the ranks. If top management does not buy this, Quality is doomed.
If top management at BATS did not know about the bug in their system—a software platform for trading equities like their own on IPO day and beyond —they did not do the hard work that is expected of them and now accept the business consequences. The downside illustrated in this real world example of an incomplete process is about as clear as it can be. To ignore or be ignorant of a showstopper in one’s own product is a reflection of a process that needs to be re-engineered. When you’re working with world-class engineers, it is much easier and far more fruitful to make sure the process is engineered correctly before the products go through it. The material cost of discovering a bug early in development is a tiny fraction of what it can cost you in the hands of the public. Give your engineers a voice and they will save you every time.
Listen to your QA stewards. If you built the right team, they are your first line of offense and your last line of defense. They know of what you speak.