It is an interesting story and one that is duplicated often in many companies. The really sad part is that in the story and the replies is that management and technology did not work as a team to get the best products and profits for the customers and the stockholders. Companies that win (and winning means survive and strive) build teams where innovation (converting ideas to dollars) are the focus and blame is minimized. The fact is that both the business management and engineering failed... and the company failed.
The point being that management and engineering need to trust each other. If I came up with a great idea, I wouldn't have much of a clue as to how to market it or finance it. And I'd probably need to get assistance to do so. And trust whoever gave me that assistance to do it right.
Similarly, if a bunch of engineers (and it was not just one in this case) say they have a good idea that pushes the boundaries a bit, the marketing and finance guys need to trust them a bit to know that they are on to something that is worth pursuing, and assist them to get it to a marketable state.
IMHO, it's more the bean counters who go wrong than the engineers...but then maybe I am biased. And the bean counters seem to have a better gift for BS-ing their way out of a hole than engineers do.
DOES anyone have any stories of engineers backing the wrong horse (or just not backing the right one? It would be good to hear some.
Arthur C Clarke (I think) wrote a story about a senator who pooh-poohed a nerdy scientist who wanted money to research a new medical technique, and later needed that same treatment himself. I'll see if I can find it.
Now, I just gotta come up with a great idea... :-)
There are many stories like this except that engineers run the company, someone in the lab has the next great idea (which isn't that great after all) and the company goes bust because the engineers fall in love with the technology, have no experience gauging a market need, creating a business plan, finding money, etc. So, let's not hastily blame the MBA people. Yes, they made a mistake here, but the technology eventually triumphed, although many people lost their jobs. Evaluate each company situation on its own. I have known good and bad business types as well as good and bad engineers.
The engineer came up with an innovation that was disruptive to the status quo, that is it was completely new. At the time the market was unknown, the customers were unknown and profit potential was unknown. Any one of these would have deterred the MBA types. Many innovations do fail but enough of them succeed so that companies that fail to take advantage of the opportunities go bankrupt.
In response to MBAs making more money than engineers, I find it ironic that those who flunk out of engineering often go into the faculty of business and many then go on to an MBA.
I'd guess there WOULD be a few... Betamax, Digital audio cassette and DVD-HD spring to mind..
Most of them are superior technology trumped by cheap and nasty that almost delivers, but is a fair bit cheaper. Most consumers will go for cheaper every time, and to hell with the specs.
It's one of many of the "Management chases money, ignores innovation, goes under" stories I have heard over the years.
What I haven't heard much is a "Management chases innovation, ignores money, goes under" type of story.
Anybody got one of those?
"But hey, I guess blaming "MBA types" is so much more fun and fulfilling..."
Steve...Looking at the above story, why did the company go bankrupt? Not because of the engineer, he didn't goof off in a slack period, he used his time to push the boundaries a bit. That just leaves the "MBA types", who in my experience usually cannot see further than the bumpers of their BMWs, and even more rarely want to.
"Which would take longer: engineer learning enough finance to present a proposal with costs and return on investment; or manager with MBA learning enough engineering to understand CDDI fully?"
So how come MBAs earn more than engineers?
I'd agree that a bit of financial knowledge is a good thing to have. One of my employers gave me a bit of basic training in this once and although I have not used it much, I was eternally grateful for it.
But this does not excuse managers from not trusting technical employees and helping them look at how their ideas might benefit the company. This management didn't, and the company went bust. QED.
I see this in the company I work for now. When I joined they had the best damn network I'd ever seen, because management told the Comms dept what they wanted and let the tech types get on with designing a network that would do it. Then the bean counters came along and it's all gone to pot, because they think they can run a comms dept. We're quasi-government so we won't go bust, but if we were private sector we would.
It boils down to TRUST I think. If management trust the tech types, it will usually work well.
Maybe if the engineer, while bored, had spent a small amount of time learning how to speak to management in a language they understand, he may have found them more receptive.
Which would take longer: engineer learning enough finance to present a proposal with costs and return on investment; or manager with MBA learning enough engineering to understand CDDI fully?
Present a reasoned argument with assumptions explaining to management showing how spending $X now should lead to $Y (with Y much greater than X) does work.
just saying I need a $30,000 protocol analyser to do my job rarely works (management they tend to view it in the same way we view their "I need a BMW to do my job".)
Engineers willfully not understanding basic finance, accounting and economics is one of the reasons the above happens. But hey, I guess blaming "MBA types" is so much more fun and fulfilling...
Of course the company went bankrupt--it had MBAs overriding engineers on technical decisions. It has happened at many other companies, too. No one ever seems to learn from it though. (At least no management has as far as I have seen.)
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...