Too much salesmanship, not enough stewardship

The title and inspiration of this blog comes from Chapter 6 of John Bogle’s book “Enough: True Measures of Money, Business and Life”. In this chapter, Bogle laments the fact that the finance industry has “become largely a marketing industry, engaging in a furious orgy of product proliferations” in which “We pander to the public taste by bringing out new funds to capitalize on each new market fad and we magnify the problem by heavily advertising the returns earned by our hottest funds”. What should be happening instead, he says, is the practicing of “values rooted in the proven principles of long-term investing and of trusteeship that demands integrity in serving our clients” … “helping investors to make the uncertain but necessary judgements”.

An immediate parallel springs to mind with the world of IT and software product development. Historically I think it is fair to say that IT has very much been guilty of unilaterally hatching new schemes and strategies in isolation from the customers that they serve, and then attempting to foist upon them what it perceives to be the latest and greatest solutions.

An arbitrary list of a few such “new market fads” (to borrow a phrase from Bogle) which immediately come to mind include structured methods, relational databases (remember SQL being originally heralded as an end-user query language?), object-orientation, use-cases, data warehousing, service-oriented architectures, incremental development, RUP, cloud-computing, Agile, Scrum, Lean, Kanban…

Silver Bullet

Even where there is potential business value and merit behind the original intentions (and invariably there is at least some), the mode of adoption and implementation all too often smacks of IT taking an “us improving stuff for them, whether they know they need it or not”.

One anonymous war story might serve to illustrate the point. In the early days of “iterative / incremental development”, more than a decade ago now, I was witness to an IT Director standing up in front of a room full customer representatives and basically announcing that “because we in IT have bought into the benefits of iterative development, from now on all our projects will deliver new releases of products to you every three months”. There was, of course, uproar. The customer was only too well aware of the pain and disruption that a new software product release entailed. If every project was doing this all the time, all they could see was that their business would be in a fairly permanent state of disruption.

The principle of frequent delivery of value through working software is of course essentially a sound one. Until we deliver we are all cost, no value. Only when something valuable has been delivered does the “Return” side of the “Return On Investment” equation even start to clock up. But beyond this extremely sound guiding principle, everything of this nature should clearly be based on collaboration and negotiation between customer and supplier, not based on unilateral decision and arbitrary dictat. (Are there periods when certain types of software releases are just plain bad (e.g. EPOS at Christmas, insurance applications during the annual renewal season)? What is the minimum viable product that even can be countenanced, and is also considered worth the cost and disruption of its release?)

All of which is based on just one war story illustrating just one case-in-point, but the underlying challenge is deep and significant, and that is the need for “IT” and “the business” to be dissolved into a truly synergistic and collaborative business relationship, along the lines of permanent and ongoing custodianship called for by Bogle.

Clearly at route there is actually only one organisation, one business, with one mission, which might be along the lines of delivering value to customers through world-beating products and services (each and every one of which will inevitably in this day and age have at least some critical element of embedded software or IT support involved).

A key part of this is clearly breaking down barriers and short-circuiting communication lines between the customer and the supplier. The principle underlying the agile manifesto that “Business people and developers must work together daily throughout the project.” provides a perhaps slightly simplistic, but largely effective maxim that starts to point the way. But even this, if adopted as a dictat can be made part of the problem, not part of the solution (“We have decided to adopt Scrum, so you will provide us with empowered Product Owners, that will spend time every day …”).

Part of the concept of custodianship is being “in it for life”, so again, the Product Owner can’t be treated as someone we pressure into signing on the dotted line before the project and the Product Owner chuck the product over the wall and head off to challenges new, leaving the real business users and customers to go figure.

So, in summary, Bogle’s call for custodianship over salesmanship in business and finance very much rings true for IT as well. What it forces us to consider is the pressing need for a genuine dissolving of the separation between “the business” and “IT” and a recognition that there is only one business, that IT and software is an integral part of today’s organization, including its customer product and service offerings, and that there are no “IT” projects as such, only “business projects”.

Related content