Restructuring IT: The Detroitification of IT

In previous installments of this series on restructuring IT, we looked at how IT has adopted industrial practices as it has gone in pursuit of scale. As a result, IT bears striking resemblance to Detroit automakers. Let's look at some common characteristics.

Sub-Optimal Quality

Detroit suffers its periodic crises of quality. There was a joke that made the rounds during the 1970s that you know you have an American car when you get the factory recall notice in the mail. In much the same way, industrial IT is notorious for low technical quality of what it produces.

Long Time-to-Market

Detroit has excessively long product development times. It takes years to go from idea to availability. Former Chrysler CEO Lee Iacocca famously went on a tirade when he wanted to see what the LeBaron would look like as a convertible. His design manager told him something to the effect that they first needed to do a scale model, then a wind tunnel, then the prototype, so they’d have it for him in about 6 months. Iacocca’s reply? “Just take a chain saw to the roof!” How many CEOs look at their IT department and ask, “why is it so hard to get anything done in IT?”

Too Much Leverage

Detroit got by for so long because it could “pull demand forward.” Very few people pay cash for their cars. Instead, they finance their purchases. They're buying a car based on future earnings, not on their accumulated savings. Think about what happens in industrial IT, in terms of capability. There’s far less supply of “bankable capability” than there is demand. Instead, the industrial IT model looks for capacity. It puts people new to the IT industry in a position to put code on the line, learning as they go along. In effect, the industrial IT model borrows against future capability development. There’s even a few firms that have bet their entire business on this model.

As my colleague Greg Reiser pointed out recently in a webinar we produced for cio.com:

The extreme case of this are the large IT outsourcers that have rapidly grown over the past 20 or so years. Many firms that have actually bragged about their ability to add over 1,000 new professionals per month! Now while I can comprehend the ability of the US Marine Corps to add new soldiers at that rate, I personally cannot comprehend how a professional services organization can effectively add, develop and assimilate knowledge workers at such a pace. So I am not surprised when clients of these firms complain about the shallow depth of talent assigned to their projects. Remember, although the Marines put all recruits through a rigorous 12-week training program, every single one of those recruits is still just an entry-level soldier at its conclusion. It can take years to train and groom people for more challenging roles. Why should you expect different for software engineers?

Producing Solutions People Don't Want, but Have No Choice But To Use

Finally – and this one is arguably a bit of a stretch – Detroit has suffered eroding market share for many years. In many cases, they’re turning out cars people don’t want to buy, year after year. Increasingly, the people who do buy the cars are the people who have to buy the cars. E.g., they’re people who are in the automotive ecosystem. Sound familiar? IT stands up solutions that business users don’t want but have no choice but to use because they're in the corporate ecosystem.

A Troika of Trouble

There are three factors accelerating the rate of Detroitification of the IT industry.

1. We have a capability shortage. For one thing, we’re not developing “heroes” in sufficient numbers to prop up this system, the folks who can jump among silos to do the unperformed tasks lost in the handoffs that happen in specialization. For another, IT isn’t the destination employer for people that it once was. (And by the way, neither are automakers.)
2. We’re overloading on “situational complexity.” To get something done in most IT shops a developer has to be fluent in an esoteric landscape of existing systems, policies and procedures. Somebody might be the smartest developer in the world, but they'll make no impact unless they invest time in mastering the esoterics. That’s not attractive knowledge for somebody to acquire, because it’s not portable. There's not much value in having “I learned all the weird stuff necessary to get things done in this specific functional area of company x” on a resume. It’s also a frustrating experience, as very often the people alleged to have the right information aren’t really authorities themselves.
3. Quality is assumed. Solutions delivered today are laden with technical debt, but very rarely is anybody looking for it. Apply metrics over just about any codebase in just about any company, and the odds are that you'll find at least one of the following: excessive complexity, excessive duplication, poor encapsulation or excessively long methods.

An increase in situational complexity, plus an increase in technical debt, combined with a decrease in total capability gives us exponential growth of people expending effort but showing little in the way of business results.

We should obsess about results, not scale. Scale is useless if we can’t get stuff done.

We’ve had a look at the problems with industrialization. Next, we'll look at how we can reorganize IT for results.