In election years past, I’ve avoided the temptation to endorse a particular candidate. This year might be different … but not this week.

But this week’s re-run from 2007 should give you a pretty good hint — maybe not of who I think you should vote for, but who you should vote against.

– Bob


I’m going to form a new political party — the Competence Party. Our platform: Competence does matter … a lot more than policy.

We’re already in the annoying run-up to the next presidential campaign. Here’s what you haven’t heard from any of the candidates: “If you elect me, I will appoint the best people to every position in government, and I define ‘best’ as ‘most qualified to effectively take care of the people’s business.'”

Here’s what you also haven’t heard: “As president, I will insist that everyone who works for me gives me the most accurate information possible — the information I need to hear, not the information I want to hear. I will base my decisions on this information. The only time I will trust my gut is when I decide what to eat.”

Anyone can present ideas that seem brilliant in sound bites and PowerPoint slides. It takes competence to make something useful happen. Most of what any administration ought to be doing is pretty much the same regardless of any policy specifics. That’s especially true if you inject competence into the process of policy formation, to weed out the alternatives that just won’t work.

If you think I’m singling out the current administration for criticism, I’m not, nor am I suggesting its predecessor prized competence more. Form your own conclusions about either or both.

This is about the next election. Based on the current round of speeches and debates, there are only three conclusions a reasonable person can draw. One is that the candidates think policy issues are all that matter — that if you’re headed in the right direction, then everything else will happen as if by magic. Another is that one or two candidates really do care about competence but are afraid to raise the issue for some reason. The third is that the candidates figure we citizens don’t think competence is important.

Nothing is more important.

If you want to join the Competence Party you have to accept the party’s platform. Raise your right hand, place your left on whatever book you want (the Competence Party doesn’t much care where or whether you worship, so long as you’re good at what you do) and vow to uphold these principles:

  • We will know what we want to accomplish, be clear in how we describe it, and know why it’s a good idea.
  • We will concentrate our efforts on a small number of important goals, recognizing that if we try to accomplish everything we’ll end up accomplishing nothing.
  • We will be realistic. We will choose courses of action only from among those possibilities predicated on all physical objects obeying the laws of physics, human nature not somehow changing for the better, and what has gone wrong in the past having something useful to teach us.
  • Our decisions will always begin by examining the evidence. And we will recognize that when our cherished principles collide with the evidence, the evidence wins. Every time.
  • With new evidence we will reconsider old decisions. Without it, we won’t.
  • We will never mistake our personal experience for hard evidence. Personal experience is the evidence we know best. It’s also a biased sample.
  • We will think first, plan next, and only then act. The only exception is a true emergency, where making any decision in the next two minutes is better than making the right decision sometime in the next several days.
  • We will never mistake hope for a plan. A plan describes what everyone has to do, in what order, to achieve a goal. Vague intentions and platitudes don’t.
  • We will sweat the details. Vague intentions and platitudes don’t have any, which is why those who stop with them always fail.
  • We will put the most qualified person we can find in every position. We’ll find some other way to reward high-dollar campaign contributors. Also, if we find someone is not able to succeed at what we’ve asked them to do, we’ll replace them with someone who is.
  • We will never blame anything on the law of unintended consequences. Our job is to foresee consequences, which we can usually do if we think things through.

No, I’m not really going to try to form the Competence Party. It’s enough of a challenge applying these principles to our day-to-day consulting work. I’m not really suggesting you join, either — you’ll have plenty to do applying them to your day-to-day leadership.

And, anyway, building a political party from scratch isn’t something I’m competent to do.

Accenture has plowed $450 million into services oriented architecture (SOA) technology. With that much in the game, couldn’t it have done better than a talking head in its downloadable video?

(Truth In Journalism department: I stopped watching after either five minutes or eternity had gone by — I’m not sure which. Maybe some graphics appeared after that. If so, it was way too late.)

Accenture divides SOA implementations into four levels. The first level is dabbling just enough that a few vendors can include you in their “The following companies use our products” logo page in their PowerPoint presentations. The fourth level has something to do with business process flexibility and becoming Fully Buzzword Compliant (FBC).

(Truth in Journalism department again: I’m working from memory. By the time the video got to this subject my eyeballs had glazed over so my recall on the details might not be perfect.)

I shouldn’t be so sarcastic, I suppose. Level Four sounds suspiciously like a position KJR adopted a long time ago: That your focus should always be on how projects will improve the business, not on implementing the technology.

There is one clear difference, though. Lots of companies follow the KJR approach. According to Accenture, no company, including Accenture, has achieved SOA level four.

But Accenture knows how to get you there and will be happy to help.

Here’s what I don’t get: SOA was supposed to make things easier.

Let’s review. First we had assembler, and assembler jockeys who could talk to business people, figure out what they needed, and churn out huge amounts of write-only code that still somehow let the business move forward.

Then Admiral Grace Hopper invented COBOL to make things easier. Which it did until someone invented structured programming to make it harder again by making sure COBOL jockeys weren’t allowed to talk to end-users anymore.

After that, Codd and Date invented the relational database management system (RDBMS) to make things easier. Once everyone got over the need for ideological purity and accepted indexing technology, RDBMSs did make things easier, too. After awhile, even relational design stopped being an interminable obstacle. Someone must have goofed here. The most likely mistake: Data designers actually talk to end-users. That’s my guess, at least.

Somewhere in here, Fran Tarkenton gave up running toward his own end-zone to avoid getting tackled and invented Computer Aided Software Engineering (CASE). CASE was supposed to make things easier, but it never actually worked, so the methodology that started to evolve around it — making sure developers never talked directly with end-users — never became important.

CASE never got fixed, probably because right about then someone invented object-oriented programming (OOP) to make things easier. OOP was supposed to be more natural than structured programming, because objects were business thingies which business people could understand more readily.

OOP would have made things easier too — if for no other reason than because unlike COBOL, OOP provided “encapsulation” which means the subroutines that were (ahem) routine to FORTRANers finally made their way into mainstream IT.

Fortunately, the methodologists came to the rescue again, giving us Object Oriented Analysis (OOA) to make things harder. Not to cast aspersions on a family of methodologies with many fine attributes, but OOA does have its drawbacks. One is that it generates enough paper to decimate the Amazon rainforest. A second is that its terminology and artifacts are impenetrable to the average string theorist, let alone merely bright business managers.

And of course, OOA makes sure developers don’t talk to end-users. OOPs.

There’s a pervasive myth that technical people can’t talk to non-technical people. In this mythic universe technical professionals only marry other technical professionals. They give birth to little newborn technical professionals, go to churches, synagogues, mosques and temples with congregations composed solely of technical professionals, and have backyard barbecues only technical professionals attend.

This must be true, because otherwise, the moment technical professionals leave the office they magically acquire the ability to speak to everyone else, only to become selectively aphasic once more when the next workday begins.

I know far too little about SOA to say what I’m about to say with such certainty: I’m willing to bet the methodologies that are starting to envelop SOA make sure developers don’t talk directly with end-users.

Otherwise, SOA would still be making things easier.