All Posts in Office Politics

|In: Leadership|Last Updated:

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.

Comments

|In: Business Ethics|Last Updated:

Among the many books I’d like to write but probably won’t, Selling Strong Engineering To Executives is high on the list. I probably won’t write it because even the best techniques aren’t reliable enough to be worth codifying. But you have to try.

Regular correspondent Jon Lee pointed out the relevance of the Challenger disaster to this topic. Richard Feynman, the Nobel Prize-winning physicist, was on the Rogers Commission that investigated the tragedy. His personal observations are worth reading in their entirety. A very short version goes like this: NASA’s engineers assessed flight risks to be 1,000 times greater than the managers who decided whether missions should fly.

I’ve coined a term for this mathematical transformation: Direct Reduction In the Value of Engineering Likelihoods (DRIVEL).

NASA’s managers were, and probably still are under tremendous political pressure to get the shuttle in the air. People being what they are, they persuaded themselves the engineers were exaggerating the risks. They rationalized their DRIVEL with this “logic”: “It hasn’t happened yet.”

Publicly held corporations justify bad decisions with DRIVEL too, and they do it all the time. Every professional project manager knows this, because every one has been put in charge of at least one project whose launch has been delayed due to executive dithering but whose deadline, scope and budget remain fixed.

If it’s an internal project, the executives rationalize the DRIVEL by telling themselves the estimators padded the original schedule (guaranteeing, of course, that they’ll pad the next one). If it’s an outsourced project, they rationalize it by telling themselves it’s someone else’s problem — the company contracting to perform the work.

The contracting company applies similar DRIVEL to its computations, because it gets the revenue now. By the time the future gets here anything can happen — everyone in a position to blow the whistle can find a way to get promoted out of harm’s way or hired by a competitor. If the project manager or account manager protests, you know what happens. That’s right — the senior decision maker says (all together now, with feeling): “If you can’t do it, I’ll find someone who can.”

It’s always the same equation: Sound career management trumps sound engineering.

You’d think those responsible for the health of the organization would take steps to keep DRIVEL out of the decision process. You’d be wrong, because … and this insight is crucial to understanding the situation … in most large organizations the owners don’t want them to.

That isn’t the case in companies with a single owner or whose ownership is closely held. Those owners run the company, make the decisions, and will be around to be damaged by the fallout of bad engineering. Privately held corporations have their flaws, but DRIVEL-driven decision-making isn’t often among them.

Government certainly isn’t like that. We citizens have come to think of ourselves as government’s customers, not as its owners. We want the best deal, that’s all. When it comes to the public sector, many have given up entirely on the concept of a healthy organization. Few consider government’s health to be their responsibility.

In this, they are exactly the same as the owners of most publicly held corporations. They, the shareholders, don’t think as owners do either. Their stock is just a commodity, to be bought low and sold high. The board of directors and chief executive officer, who run the company on their behalf, are their agents, obliged to subordinate personal preference to the shareholders’ will. And we wonder why many are paid enough in one year to retire. (It would be interesting to compare the level of DRIVEL in companies whose shareholders care more about dividends than growth. I’d guess it would be lower, but I have no evidence either way.)

The situation isn’t entirely hopeless. Many Wall Street analysts do pay attention to planning and decisions that pay off in the longer term. They have to. Today’s profits and the next-quarter forecast are already reflected in the stock price. It’s longer-term planning that will cause a share of stock purchased today to be worth more in the future.

It is possible to sell superior engineering to executives. It isn’t easy, and you just have to remember: The engineering itself doesn’t matter to them. In the end they only care about four issues: Increasing revenue, decreasing cost, reducing risk, and how achieving one or more of these goals will affect them personally.

That’s how they define strong engineering. Your job is to help them recognize it when they see it.

Comments