There is a saying: “To err is human. To really screw up, you need a computer.” We can find any number of examples that seem to prove just that.
> In April of this year, when Toronto Maple Leaf fans tried to order their playoff tickets online, “technical problems” denied them access.
> A few years ago, BlackBerry users across the world couldn’t use browser, email, and text services for days because of system issues.
> In 2011, The US government abandoned a virtual border fence project they’d already poured $1 billion into. One of many technical difficulties: cameras were unable to differentiate between vegetation and people
But here’s the thing: to really screw up, you need people!
All Problems Are People Problems
We talk about people vs. system issues, but when you get down to it, they all circle back to the people who are charged with designing, developing, implementing, and executing the technology or systems. Let’s take a look at the BlackBerry issue. RIM said a core switch failure in its infrastructure caused the service outages in Europe, the Middle East, Canada, Africa, Latin America and India, and a backup switch didn’t function as it was supposed to.
This wasn’t the cause of the problem. It was the symptom. Who designed the core switch? Who built it? Who installed it? Who tested the backup switch? Who was responsible for developing the infrastructure? Who couldn’t figure out how to install a new switch or come up with a solution? Granted, technology is complex – but it shouldn’t outpace our ability to use it, especially if our organization is built around and dependent on it. When you dig down, you typically find your way back to a group, a team, or an individual who somehow created the situation.
The question is what do you do about it? There’s a two-pronged attack:
1 – Find out the root cause.
The cause is not a faulty switch or a buggy software program. Who is involved with the problem?
2 – Build an A team.
If you surround yourself with A players, a lot of these problems won’t exist. And if one should pop up, they will find it, solve it, and tell you about it later. If, as a CEO or C-level executive, you are going around trying to find root causes of these problems, it’s typically because you have B and C players. They are the ones creating the problems; they can’t figure out how they happen; they can’t solve them.
The CEO is not the chief problem solver. What I hear frequently is, “I’m in my office, putting out fires.” But very few fires start from spontaneous combustion. Most fires start from some employee lighting a match or fanning an ember. If you say, “I’m in my office, putting out fires,” what you are really saying is, “I don’t have the right people working for me.”
Often, technical problems are merely symptoms of your real problem: a team of too many B and C players. When you have an A team, you’ll find that your system and operation problems are much fewer and further between.