He neatly explains why traditional, say, "reasonable" management does not work in IT:
- Objectives are a way of saying prove to me first that you know where you are going before you go.
- We’ve come to believe too much in metrics and accountability.
- There’s no systematic way known how solve ambitious problems. (Otherwise they would have been solved already.)
For example, the original Google Search project succeeded, exactly because none of this was around. Traditional management only works for repetitive processes. Organizations that revolve around traditional management are incapable of innovating.
> There’s no systematic way known how solve ambitious problems. (Otherwise they would have been solved already.)
Such as social networks for cat videos and the like?
Come on, let's stop embellishing IT. Most of the times, we choose not to be systematic or thorough because we are divas. We like to think we're more special than we actually are, that we're too "conceptual" for metrics and that our horizons aren't clearly defined. This is - most of the time - BS. We just happen to have been dealt a good hand (working in IT, nowadays) which allows us to harness the large demand to our egos. IT professionals aren't artists or the like; they should be as systematic as other engineering fields.
The physical world is much less flexible and forgiving than the world of software. A civil engineer can't say "this beam will break every week, so I'm just going to put a robot next to it that will attach a new been when it does". But you can do the equivalent with a process that crashes.
The greater flexibility of software implies a different set of management practices.
I think that when the Manhattan Project was started, physicists knew that it was possible, in theory, to build a nuclear bomb. It's just that no one knew how to manufacture it. Going from "we know it's possible" to "built" is more amenable to a systematic process than going from "is this even possible?" to "built". I think the article is talking about the latter. iPhones were firmly in the realm of science fiction fifteen years ago. It would have been very different to systematically try to create one. Whereas in 2007, it was apparently possible, just no one knew it yet.
It's very rare that in our industry someone goes in without even knowing if a thing is theoretically possible.
Uber knew they could do GPS tracking and send messages to phones.
Apple knew they could integrate a mobile phone chipset with a PDA one, and put some software on top.
Google knew you could index web pages.
None of these things were fundamentally hard problems on the scale of nuclear fission or landing men on the moon. There was little risk beyond some money, and it was largely a case of taking existing technology and putting it together in new ways. I'm not trying to claim these things didn't take some imagination and skill to develop, but to claim they were potentially impossible is overstretching, sometimes as an industry I think we just need to get over ourselves a bit!
No, I'm not arguing that. I'm arguing that they knew an atomic bomb was possible before they started. From what I've read, no one in the phone industry thought something like an iPhone was even possible. I read a story that said that when Microsoft's phone engineers heard the iPhone announcement, they said, "that's impossible! It would have to be practically all battery." They disassembled one when it came out, and sure enough...
I think the argument is that the iPhone (and other innovations) required a leap in creativity, not science or engineering; it's those leaps that power many of today's technology companies.
Did they actually have a system, or where they throwing large numbers of incredibly bright people at it and giving them pots of money to play around with?
Management Accounting techniques are generally based on knowing what the process is, or what the output looks like, ideally both. I would suggest that the atomic and space programs have involved many problems, at various recursive levels, where the process to follow, and what success looked like, where unknown going in. Research & Development is one of the classic cases for where Management Accounting techniques are consider useless or counter-productive.
Please don't use projects such as the Apollo or Manhattan program as examples. These projects are huge and have considerable amounts of money and man-power behind them, which most IT projects nowadays don't have.
I did a quick check on Wikipedia and the Apollo program cost in 2005 dollars $170 Billion dollars.
I believe the problem with IT is that vendors have sold management that their solutions will solve all their problems with little effort or man-power. The do more with less mantra has been oversold.
The Manhattan project also came to my mind as a counter example and I was disappointed it wasn't addressed in the book.
It could be the exception that proves the rule. Internally you might be able to say it was heavily research driven. And the global resources and brain power attached to the project were unprecedented (https://en.wikipedia.org/wiki/Manhattan_Project). Plus there was the motivation of a truly existential level threat. Even given all that it still could have failed.
For some reason I didn't think of Apollo in the same way. Maybe I'm missing the boat on that one.
- Objectives are a way of saying prove to me first that you know where you are going before you go.
- We’ve come to believe too much in metrics and accountability.
- There’s no systematic way known how solve ambitious problems. (Otherwise they would have been solved already.)
For example, the original Google Search project succeeded, exactly because none of this was around. Traditional management only works for repetitive processes. Organizations that revolve around traditional management are incapable of innovating.