What if we called it herbal IQ juice?
Highly organic friends of mine routinely disparage my coffee drinking, telling me how unhealthy it is to quaff vast quantities of the caffeine and other chemicals it contains. But if a health food store sold the same stuff as a natural infusion that increases alertness, they’d be recommending it to me, don’t you think?
How you communicate a concept has a lot to do with who accepts it and who rejects it. Which gets us to the issue raised last week — what causes management DRIVEL (Direct Reduction In the Value of Engineering Likelihoods) in response to the recommendations of their technical experts.
It’s time for equal time: The root cause isn’t always management ignorance, stupidity or short-sightedness. Sometimes, it’s that when explained by engineers, Benefit Language is Awfully Thin, Horribly Elucidated, or Ridiculous. (BLATHER). Engineering BLATHER is a major cause of management DRIVEL.
Think back to the early days of the World Wide Web. Marketeers put up websites with blithe disregard for engineering discipline. Getting new pages up quickly trumped such minor considerations as testing, server reliability, or security.
I know from first-hand experience that many IT professionals sat on the sidelines, sulking at such disrespect for quality engineering. They presented their BLATHER to the marketing director, and the marketing director ignored them.
Marketing directors might not know much about engineering, but they do understand that in their world, when faced with the old quicker/cheaper/better trade-off, quicker usually comes first. They viewed their discussions with IT the way a film director might react to recommendations for professional plumbing and electrical work when building a set. It’s just a bunch of BLATHER.
Let’s be honest with ourselves. Bullheadedness is something of an occupational hazard among professional engineers. Many ignore Louis Sullivan’s famous dictum that form follows function, instead considering quality engineering to be an absolute characteristic with intrinsic value. If anyone challenges The Rules, engineers of this persuasion commiserate with each other regarding the sad ignorance of the unconverted heathen, never once considering the possibility that they’re applying their Rules to situations for which they aren’t suited.
Even among engineers who understand that Hollywood sets call for different engineering standards from factories, factories from office buildings and office buildings from domiciles, many still rely on BLATHER to explain what’s required for a project to succeed. They find to their dismay that it’s rarely convincing.
Which brings us to an inviolable rule of communication: At least one party must learn the perspective and vocabulary of the other.
Sophisticated managers, willing to take the time to learn how engineers think and speak, are able to penetrate engineering BLATHER to understand why the recommendations of the engineers matter. They’re the minority. Luckily, the perspective and vocabulary of management are sufficiently simple that engineers who want to can learn them in … well, in what’s left of this column.
All you gotta do is connect your engineering requirements to one of the “Big Four” management evaluation criteria: Increased revenue, decreased cost, reduced risk, and career impact.
Take an example: Microsoft Access and why it’s not the right tool for building production-grade IT systems. Many IT professionals will tell a business manager who’s interested in using it that it’s just a toy, inappropriate for a production system — trust me.
Faced with that impenetrable BLATHER, the business manager contracts development of the system … in Access … to an outside contractor who builds the system at a tenth the cost of IT’s estimate.
An IT professional who’s as interested in being persuasive as being right will take a different approach: “Access is suitable for small or prototype systems only. If this project succeeds, too many users will be hitting the database, which means the system will slow to a crawl. You’ll want us to add more features and functionality, which means the system will slow even more. And the database will grow, which means … yes, that the system will get even slower. That means that instead of increasing productivity, you’ll have a lot of employees twiddling their thumbs waiting for the software to respond, which will cost you a lot more than you’ll save by building the system in Access. Even worse, Access databases become fragile when they get too big, which means that if you’re lucky we’ll have to take the system offline fairly frequently to repair the database, and if you’re unlucky you’ll lose data.”
No matter how much you avoiding engineering BLATHER, you won’t entirely eliminate management DRIVEL. Nothing will.
But at least you won’t cause it to increase. And that’s a worthy goal.