Protecting your blind side in IT

I recently argued that everyone has a blind side. When people or organizations miss important threats or opportunities--ones that are perhaps obvious to you--it's easy to think badly of them, to assign blame. My goodness! Why ever could they not see that coming?! Idiots! But it's not simple to avoid being those idiots.

I've dealt with department managers with unimpressive budgets who truly "get it." And I've worked with international governments and captains of industry who wouldn't recognize a clue if it dressed up as Colonel Mustard and bludgeoned them with a lead pipe in the conservatory.

In my experience, truly incompetent individuals and outlandishly oafish organizations are the exception. What I usually find are intelligent, well-meaning folks who can't see what they're missing--not because they're stupid, lazy, or in any other meaningful way blameworthy--but because they're focused on other tasks and looking the other way.

Last week, I promised to share some techniques for dealing with the blind side. I wish I could say "Combine a pound of black beans, a quart of skepticism, three eggs, four product evaluations, and a dash of focus group feedback in a large mixing bowl; stir until creamy; pour into well-greased pan; and bake for an hour at 325 degrees." But it's not like that. Improving your perception and handling of things that are over the horizon, camouflaged, latent, or visible only in the "negative space" (i.e., what's missing rather than what's there)--those are skills to be learned, not recipes to be followed. Nevertheless, I've used these these techniques with excellent results:

Admit It, Move On People tend to be embarrassed by, thus defensive about, their blind spots, weaknesses, ulterior motives, errors, and failures. Ego drives us to pretend they don't exist. But when you're pretending something isn't a problem, it's hard to do much about it. So get over it. Accept that you have significant weaknesses, fears, and other assorted ugly bits--that there's an often large gap between where/what you are and where/what you want to be. Getting over shame and blame and getting your ego out of the way lets you get on with the real work. If it's not your ego in the way, help whoever's ego is in the way to get out of it.

Simplify Ruthlessly "Because it's complicated, it fails." The more complex a thing, the more moving parts, the more dependencies, the more special cases, the more likely it is to fail. The more likely it is to have failure modes that are difficult to discern, much less eliminate. The more complex, the more likely enemies are to find ways to exploit its weaknesses. Products with 37 great new features and slides extolling 15 points of product goodness convince no one. Whether it's a strategy, message, integration plan, product design, user interface--it doesn't matter. Simplify in a ruthless, continuous, disciplined way.

Voice of the Consumers Everyone asks "How can we make it better?" It's stunning, however, how often it's answered primarily from the perspective of those executing the project, not those who will eventually consume, use, or buy its results. "What do customers want?" "How does this fit into their processes, culture, expectations, problems, and daily lives?" "How does this address their needs and wants, hopes and dreams, fears and concerns?" These questions are often answered in glancing ways, then used to justify what the product team or marketing wants. And then the product is designed, packaged, and sold around what the producer can do, or thinks is its competitive advantage--things essentially irrelevant to consumers. It's counterproductive. Always go to the voice and needs of the consumers.

No One Consumer The consumer? No such thing. Don't think, talk, or design as though all users, customers, and prospects are the same. Industry to industry, geography to geography, company to company, business unit to business unit, individual to individual--the differences are vast. Two companies, in the same industry, with headquarters across the street from each other, can have completely different approaches to IT, design, logistics, R&D, and virtually all other aspects of their operations. Even within one company, the needs, wants, and interests of an end user are different from those of a supervisor, the business unit vice president, the CFO, and the CEO; and these differ from those of a help desk operator, a system administrator, an app owner, a CIO, and so on. When you hear "How can we make it better?" ask, "For whom?" When you hear "What do customers want and need?" ask, "Which customers? In what industries? In what geographies? Following what operating model?" Be specific about whom you're talking about, and what their use cases are. I like to establish "personas" to identify and encapsulate different points of view. Then we can work to make the project appealing to each of the stakeholders, on the terms relevant to them--not create for a large, messy, undifferentiated glob. (Nor is there a need to commit the opposite sin, segmenting customers, markets, and needs to distraction.)

Systems are Holistic No modern complex product, application, or business process is an island. They're all interconnected with other systems, with their users, across networks to other applications and databases and data feeds, to other business processes and company requirements, to skills and patterns of investment and supporting ecosystems and a few dozen other things. If you care about a project's success, you must evaluate it relative to the interconnected network of influencers and stakeholders in which it will live. But that complexity can be overwhelming. So I try to establish a structured evaluation scheme. For example, I ask: How will this product effect the Company, its Customers, its Competitors, and its Compadres (partners)? There's nothing sacred about four Cs; if a particular product category needs to have Retailers, Telecos, Developers, or some other group evaluated, add them in. But similar products all get the same categories, which helps establish a consistent evaluation with broad, predictable coverage of the relevant factors. This helps you not miss things.

Listen Beyond Don't just listen to what people say. They live in their current worlds, facing their today pressures, with products and skills acquired some time ago. They are often manifestly unable to evaluate how they would feel if things were different. A few years back we interviewed data center managers about virtualization and automation. Most were lukewarm to downright hostile--yet today most are eagerly remaking their operations around just such products. Truly great products like cell phones, text messaging, the Internet, x86 virtualization, and Facebook? No one wants them--right up to the moment that everyone wants them, and cannot imagine living without them. You must listen for and discover latent needs and intent, which are far more important than the verbatim responses.

Plan to Fail Pilots are taught to "plan to crash"--not because they ever want to crash, but because thinking about crashing sensitizes everyone to the potential causes of failure, helping to avoid them. Planning helps make sure that you've got the best training, the right safety equipment, the most robust procedures, and the most useful cautions before you embark. It means you're as prepared as you can be to avoid problems, or to mitigate them if, God forbid, something goes wrong. I find that project teams, working feverishly toward completion, often haven't had the time or energy to consider "What if this fails? What if no one does that? What if both things happen at once?" It's amazing how much more robust a project plan can become after the team reviews a few failure scenarios.

Plan for Serendipity Much of our discussion has been around threats, failure, risks, and gotchas. The fear factor is what most often triggers project reviews. But I regularly also find previously hidden connections, advantages, and opportunities. Stay loose and open to a positive upside. Many highly successful products are, after all, not at all what was first envisioned.

Most of my practice is concerned with finding patterns of success, not failure. The need for the occasional post mortem is a reminder that we study failure modes primarily to avoid them. Being sensitive to failure modes and patterns not only motivates us to diligently look for what lurks in the negative space, it also motivates us to do so.