Information Technology Dark Side

Once upon a time, in a land not far away, there was a problem. It was an important problem, and not solving it would have a dramatic impact on the multi-billion dollar empire of it’s corporate ruler. A benevolent leader, eager to solve the problem, went searching for a leader, someone who could be counted on to tackle the problem with single-minded dedication. She offered him all the resources at her disposal in solving the problem. Need a brilliant architect? Done – his schedule was suddenly cleared and he appeared, ready to work. Need a highly skilled performance tester? No problem. The benevolent leader had the power to re-prioritize work with a wave of her scepter and experts, regardless of their current work responsibilities, were made available. A dream team of expert problem solvers was quickly assembled and given one objective: solve the problem.

In a similar way, physical accommodations were quickly made to ensure the success of the effort. Office space was created for the team to work in, and food and beverages were brought in around the clock to make sure everyone had the energy to focus on the problems. Solving the problem was more important than the inconvenience of making arrangements for the team.

Meetings, like the logistics, were organized around the concept that solving the problem was more important than anything else. Instead of making demands or proscribing processes to follow, concerned managers attended with the aim of removing any roadblocks preventing the team from making progress. They asked what they could do to help the team, not the other way around. Ideas were bantered about and debated openly, without regard for sensitive egos or the relative rank of the originator of the idea. No one complained that the direct communications was insensitive, disrespectful, or otherwise inappropriate for a setting involving senior management. The only thing that mattered was solving the problem.

Day to day management of the team was just as utopian. The only “progress” measured was the distance from solving the problem. Theories were created, tested, and discarded. Every time a theory was proven wrong, no one called it a mistake, not even managers. When there were disappointing moments, nobody got blamed. Instead, the discussion focused on the new understanding of the problem generated by testing the theory.

There was no standard set of deliverables the team was expected to produce. Instead, the team was asked to just do what was needed, and was given strict instruction to resist doing anything that didn’t bring them closer to solving the problem, no matter what it was.

Under such excellent conditions, you wouldn’t expect it to take long for a team to solve any problem, and this case was no different. Within a few days, the problem was solved, the team was dissolved, and the fairy tale came to an end as everyone returned to the work they had put aside.

What was this problem, you ask? It certainly wasn’t a typical project. It was a beautiful moment of cooperation, facilitation, and unification that resulted in a positive outcome. But there was nothing glamorous about the problem itself. In fact, it was a simple production support issue, with broad impact on business processes of a Fortune 500 company.

I believe behavior like this is typical when an important production system goes down. I know of a company where a single, simple service (like checking the balance of an account) is used so frequently by customers and sustains such high volume that the company measures it’s outages in thousands of dollars per minute of downtime. In a peak hour, an outage of this one simple service can result in driving over $100,000 worth of additional phone calls to their customer service center. No wonder even large organizations quickly become agile when these types of capabilities are temporarily lost!

When I think about this story, I wonder why this type of effort can’t be sustained for longer periods, or why it can’t happen in every IT project. Wouldn’t we be more successful if it could? Why do managers (including myself) so easily get distracted from the goal of facilitating progress and removing roadblocks? Why can’t we always work this way? How does “do what it takes” become “follow the process” when we switch from problem resolution to project execution?

For those involved, this event was described as a brief expedition into IT Utopia. For those of us not involved, it is a good reminder of what makes projects good.

If you enjoyed this post, make sure you subscribe to my RSS feed! Stumble it!