“If I had asked people what they wanted, they would have said ‘faster horses,'” Henry Ford famously said. The lesson is clear: Your inner muse is a more reliable source of information than all the market surveys you can afford.
What Ford didn’t say was, “If I had listened to people when they told me what they wanted, I’d have offered a new model instead of insisting the Model T was all they’d ever want, nearly wrecking my company with my stubbornness.”
The world is more complicated than the simple stories we prefer.
I understand that speed and agility beat size and strength. Everyone knows this is the central truth of the modern business age.
What I don’t understand is why, if everyone knows this, mergers and acquisitions are so popular. And I understand even less why so many companies tell the FTC they can only compete if they merge, because they need to be huge to get enough economies of scale to compete.
While we’re at it …
I’ve been told, over and over again, that we long-ago left the industrial economy behind, replacing it with either a service economy, an information economy, or some combination of the two.
The proof: We’ve sent most of our manufacturing offshore to China, turning it into … an economic … superpower …
Hey, wait a minute.
It’s hard to escape the conclusion that the big and strong, who don’t care where they manufacture so long as it’s cheap, are acting like Uri Geller, using misdirection to point the rest of us in the wrong direction while they keep the serious money for themselves.
I figure it this way: The age of the dinosaurs belonged to the big and strong … the dinosaurs. The mammals used their speed and agility to be too nimble to catch.
To me, that seems like a more accurate metaphor for the world economy.
Speaking of what we’ve been told over and over again that doesn’t line up with How Things Really Work, here’s an example that’s closer to home: Nearly every published application development methodology.
Look closely at their applicability to internal IT. You’ll find the same flawed chain of logic: (1) It works for developing commercial software -> (2) The software internal IT builds is just like commercial software, only simpler -> (3) Therefore, using these same methodologies will make internal IT phenomenally successful.
Two problems: First, where commercial software developers generally develop software (talk about your blinding insights), internal IT generally buys commercial software whenever it can (otherwise there would be no market for the commercial software developers — another blinding insight) and integrates each new package into its application portfolio.
Package integration is, of course, just like application development, other than being entirely different.
That’s the first problem. The second is the nature of the product. For a commercial software developer, the product is software (and the blinding insights continue unabated). For internal IT? Not hardly. Installed software, no matter how well it runs, is by itself worthless.
For internal IT, the job isn’t done until workgroups throughout the business put the new or improved software to productive use. Most internal IT organizations are in denial about this point, and have been for decades, because … all together now … the commercial methodologies stop when the software fulfills all requirements and meets all specifications.
If these IT organizations were, instead, convents, they’d go by the name “Our Lady of Perpetual Argument,” because that’s what always and inevitably happens following “successful” project completion: An unending argument as to whether the software meets the specifications, whether the specifications were right, and whether the business manager’s face looks more like a potato or a radish.
As if any of this matters.
Contrast this situation with what happens when internal IT figures the job isn’t done until the software is in productive use: The arguments become discussions.
Arguments are, in any business setting, for losers. Arguments are about winning and losing, and if IT and a business division argue, one will lose. That means the whole business loses no matter who wins, because either way the business will have spent time, money and effort implementing software that isn’t in productive use.
Discussions, in contrast, are about solving shared problems. In this case, the shared problem that the new software doesn’t support what the business intends to do. As is the case in any discussion, both sides win or both sides lose, depending on whether, working together, they succeed.
It’s the difference between “win/win” and just winning.