I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

I work for ThoughtWorks, the global leader in software delivery and consulting.

Friday, August 21, 2009

Restructuring IT: "Too Big to Fail" Doesn't Equal Success

By going in pursuit of scale, we’ve created an IT function that is “too big to fail” in many businesses. Companies depend on IT – many can’t operate without it – yet they don’t really understand it.

The result is moral hazard. Moral hazard is the proverbial “heads I win, tails you lose” scenario: a person takes boneheaded risks knowing that if they turn sour, somebody will come to their financial rescue. There is tremendous concern that we're witnessing this in financial markets today: banks bought high-risk collateralized debt obligations with borrowed capital to juice returns, only to need the US taxpayer to intervene to rescue them when the value of those assets collapsed and the market for them dried up. The moral hazard of the situation is the disincentive for the banks to be prudent risk-takers in the future: if a person knows somebody will bail them out, there's no reason not to take boneheaded risks again.

This describes IT. We stand up massive projects that fail more often than not. When they fail – 6 out of 10 times mind you – the business sponsoring the initiative bails it out. And there’s no downside risk: those people who were bailed-out continue to hold down their jobs because “they’re the only ones who know the system.” They might even get promoted. This creates moral hazard in IT, as it builds in the expectation that success of the project is optional.

This is the result of industrial thinking. IT defines highly specialized roles that assume people perform repetitive tasks. This allows IT to scale by hiring armies of people, each into a very narrow position, making people expert at one very specific piece of the solution chain. Unfortunately, it also makes the success of a project an abstract goal for each person, and success of each person a relative goal. Restated, in the industrial model each person is less responsible for success of the project, and solely responsible to show that they did exactly as they were told.

Think about an IT project a long-jump team, staffed not with one person who can jump nine feet, but nine people who can jump one foot. Clearly, the results aren't going to be the same.

This is why we’ve hit the limit with industrialization. Industrial IT assumes people are automatons performing specialist tasks in a repetitive fashion. That assumption is diametrically opposed to our business partners' perceptions of IT as a source of innovation. An industrial approach that values specialization and repetitiveness implicitly stifles innovation, invention, initiative and leadership. It bleeds out creativity. I had a colleague tell me the other day that two people on a team he was working with would sit and stare at the wall until told exactly what to do. Once done, they'd go back to staring at the wall. That’s industrial IT in action, and it's devoid of innovation.

We've seen this same industrial phenomenon in other professions. For example, when professional sports leagues expand, the quality of play goes down. Consider baseball. When Major League Baseball expanded a little over a decade ago, players posted outrageous offensive statistics. The reason? There were a lot of pitchers in the major leagues who weren't really "major league." They were just people hired to fill the roster, to hold a spot in the rotation. On the days those people would pitch, the team managers would hope only that they wouldn't hurt them, more than they had any hope that they would actually help.

We have this in IT. They’re called “net negative” people. These are people who create more work for people to do than actually solve the problems we need them to solve. Analysts who write requirements that need to be substantially re-analyzed before they can be turned into code, developers who write code that is of such poor quality that it needs to be rewritten before it can be released to QA, or testers who execute test scripts without being able to pass or fail them because they don't really understand what it is they're testing in the first place all create more work for people to do than they contribute. Overall, they're "net negative" to the project.

Businesses will be restructuring for quite some time. That amplifies the risk of a late-stage project failure to IT, because project bailouts are less likely in this business climate. To come to terms with this new environment, IT needs to be less concerned with industrial scale, and more concerned with bottom-line results.

Before we get into the details of how we need to restructure IT, we'll first take a look at the similarities between the state of mature industrials and the characteristcs IT is showing today. We'll also look at the factors that are accelerating IT toward the same fate as the US automakers.