Depending on the business expert I’m listening to and the day of the week, I know three truths:

1. Good employees who work together as a team outperform great employees who don’t.

2. Good employees with great processes outperform great employees with bad processes.

3. If an employee is irreplaceable you should immediately fire that employee.

From first-hand observation I know that when it comes to Information Technology organizations:

  • Great employees can and do overcome bad processes.
  • Great employees can and do overcome lousy managers.
  • Great employees can and do pull along mediocre teams.
  • Making one or two great hires is the most critical step in turning around an underperforming organization.
  • Well-designed processes can be pretty useful, too.

Which is to say, if you want an organization that works, you’ll get more leverage from hiring great employees than from any other single effort you can undertake.

Great employees can overcome organizational deficiencies to deliver useful results. They can’t, by themselves deliver a great organization. That takes a lot more.

The question of what makes a great organization tick is rife with superficial thinking. The usual approach is what you might call the “Tom Peters Fallacy”:

  1. Find a great organization.
  2. Identify a trait in that organization you like.
  3. Decide that this trait is what makes that organization great.
  4. Declare that this trait is the panacea for all other organizations.

As far as I can determine, there is no one characteristic that by itself can make an organization great.

Well, okay — there is one: excellent leadership. That only works because I define “excellent leadership” as “Doing everything required to build a great organization,” thereby begging the question.

So … what is required to make an organization great, as opposed to simply functioning?

Leadership: A great organization does start with strong leadership, in a non-question-begging way. If there’s no direction — no focus, no goals, no plan, no definition of excellence, no clearly stated expectations for employees to live up to; no alignment of purpose and standards — the employees will keep things going, but not much more than that.

Great employees: Not every employee has to be a superstar, although all must be competent. Great organizations do need enough top-notch performers to demonstrate that high standards are achievable, not theoretical.

Focus on achievement: The definition of “great employee” has been diluted through too many managers reading about “emotional intelligence.” Employees who are focused on getting along will concentrate on how irritating their colleagues are. Employees who are focused on achievement will value their colleagues’ contributions and ignore their eccentricities.

Teamwork: Just as the definition of “great employee” can’t ignore the importance of serious technical ability, it also can’t ignore the importance of working and playing well with others, and of providing leadership in the trenches.

Willingness to innovate: This is IT we’re talking about. Information technology. The field where if you can buy it, it is obsolete by definition. IT organizations and everyone who works in them must be willing to try new technologies, processes and practices … and even more important must be driven to constantly find improvements to the ones already in production … or they stagnate.

Willingness to not innovate: “State of the art” means “doesn’t work right yet.” Most of the time, the work required of IT is best achieved by extending what you have, not by chasing whatever is being hyped in this year’s press releases, aided and abetted by publications hungry for advertising revenue.

Evidence-based decision-making: Great organizations make decisions through the use of evidence and logic, not wishful thinking and listening to one’s intestines.

You’ll note the usual buzzwords are notably absent. Governance, ITIL, CMM and all the other processes and practices (I used to call them Processes and processes) that are supposed to lead to inexorable success don’t, in fact, lead to excellence.

Excellent IT organizations do have them. Even more important, they are kept in their proper place — as useful tools that help employees be as effective as possible.

The best woodworkers have band saws, coping saws, lathes and routers in their workshops, and not just hammers and chisels, but their tools aren’t what make them the best.

Great IT organizations are the same. They practice good governance; follow consistent application maintenance, enhancement, design and testing methodologies; adhere to clearly defined change control procedures; and otherwise avoid making things up as they go along.

Their processes and practices are important. They are, however, merely the signs of a great IT organization.

They are not its cause.

The story of the Brooklyn Bridge — in the late 19th century the longest and largest suspension bridge ever attempted — is as dramatic as any fiction. As chronicled in David McCullough’s phenomenal The Great Bridge (1972) it has heroes, villains, excitement, setbacks, and ultimately triumph.

Engineers were the heroes, starting with John Roebling, the greatest bridge-builder of his time, who conceived the bridge, served as architect, and organized the effort to charter a bridge company.

Also his son, Washington Roebling, a Civil War hero who in his mid-twenties took over as Chief Engineer on his father’s untimely death. It was Washington Roebling who worked out every last engineering detail, and who recruited a fine engineering team to oversee the work — a team that, with only one resignation, remained in place for the fourteen years required to build the bridge.

A third Roebling was as important: Emily, Washington Roebling’s wife. When a severe case of the bends ruined her husband’s health (brought from too many hours breathing compressed air under the river, overseeing installation of the caissons on which the bridge rests), it was Emily who turned his dictated instructions into detailed written specifications, worked personally with the engineering team, reported progress and challenges back to her husband, and in general acted as second-in-command throughout most of the project.

The politicians of the day were the villains. Boss Tweed and his New York political machine were the most publicly detestable. The most vile, though, were board members who awarded the cable manufacturing contract to a crony who then delivered, quite deliberately, defective steel wire to the construction site.

No summary can do the book justice. Read it. When you’ve finished, you’ll understand that today’s politicians are nothing new. That doesn’t mean their lack of public courage is any more acceptable. It simply reinforces what we already know: Engineers create things that are new; politicians repeat the same old patterns, century after century, ad nauseum.

In the 1970s and preceding decades, the United States invested 3 percent of GDP on infrastructure. Since 1980 we’ve spent one third less and our infrastructure is deteriorating. It’s a pattern that is, by now, familiar: Politicians sell taxpayers on the idea that tax cuts are free. We just need to eliminate waste and be smarter about priorities.

Here’s another pattern: Bad logic about risk.

According to the Star Tribune’s investigative reporting, the engineers who last inspected the 35W bridge in Minneapolis prior to its collapse identified 52 steel beams at risk of cracking. They were sufficiently concerned to consider condemning the bridge, and recommended emergency measures to reinforce it.

Shortly before the project began, though, the same engineers reviewed their emergency measures and decided they carried too much risk of their own. The non-engineers who set policy in cases like this decided this meant doing nothing (ManagementSpeak: Developing “a more cost effective approach”) was a fine course of action.

One more pattern: Bad math when it comes to risk.

Imagine the risk of the 35W bridge’s collapse was 0.001%. That’s sufficiently remote that few would worry.

We know, though, that about 100,000 bridges have been rated the same or worse than the 35W bridge before its collapse. That would mean we have a 10% chance, every year, of another catastrophic bridge failure.

We don’t know the actual risks. If anyone does turn bridge ratings into probabilities of failure, it’s well hidden. One wonders why.

What does this have to do with keeping the joint running? Everything. You deal with the exact same challenges every day:

  • Do more with less: Most CIOs have been handed budget cuts, then told there’s plenty of money — they just have to eliminate waste and set more effective priorities.
  • Bad logic: Bridge engineers aren’t the only ones who find flaws in proposed solutions, only to be told that if that’s the case there’s no problem to solve.
  • Bad math: An easy-to-handle example illustrates: If the risk of one server failing is 0.01% on any given day, the situation sounds manageable. Unless you have 1,000 servers in your data center.

Here’s why it’s relevant. Your job isn’t to be right about all of this, then to say I-told-you-so when something goes wrong.

It’s to establish strong enough working relationships throughout the business to be persuasive, to communicate risk and its consequences accurately enough to prevent its turning into reality.

Much harder.