Re: The Management Myth
Posted: Mar 30, 2010 11:25 AM
I always like your stuff. "Thinking in C++" has always been one of my main referrals when folk ask how to get into programming. I also passionately feel that non-agreement is the spice of innovation and discovery -- In other words it is (imho) healthy to not agree with each other. This is a particularly good thing when one considers philosophy and science.
I grew-up on science and engineering (I consider engineering; applied science), I thrived on philosophy ... And I graduated in mathematics (in computer science, oy ve). I was part of teams that take care of small and cool things in my country and more interesting but less cool things internationally (eg. like voice mail or your banking).
Later I graduated in business (MBA) and marketing (MMkt) -- I specialised in 'innovation and technology'; I will add my personal interest in things like systems analysis/design, business process engineering and project management which I trained in (too) ... These skills only 'work' after a few years in the trenched (imho). I recognise what you describe in this article, and who are the people you want to refute . . . Human beings?
'Management Science' has so far created the good bad and ugly from: TQM (Honda, Boeing, Volvo); ISO9000 (most NGO, government, pharmacutical, and military organisations); SixSigma (GE, 3M, Intel); Logistics and Supply chains (Amazon, UPS, FedEX); ISO Risk Management (WHO, (US) DOD, (UK) MOD, EU), BPM (IBM, Microsoft, SAP, , even Model Driven Architectures (and things like OASIS) to NGO-s like FairTrade Oxfam, and EarthHour.
The key message in 'management science' is make it science. ONE top ten 'management science' top performer would be "Save the Children Fund", whom I've supported since 2001 -- How many of Matthew Stewart's champions have papers published in the Harvard Business Review (which is a world class peer reviewed journal). 'Save the Children' has seminal papers published in the HBR and in reprints -- Life saving, Open Source, business processes. You and/or Stewart would find it difficult to refute Oxfam's record in governance or management science also, I believe.
However, because I feel solid ground beneath my feet, concerning the Steward book, I would like to comment on what others have already identified as 'science' versus 'philosophy of science'.
Your blog's description puts the Stewart book in the 'philosophy of science' camp -- Identifying issues of rhetoric or logic and ignoring substance (or discounting substance, to be fair[/]). One day, when I find a blog site I can trust, I want to start a blog on "How Writing Software Improves my spiritual Sense of Grace".
A real management consultant is either an expert in an industry or kind of business (eg. retail, mining, etc); a systems analyst or engineer; or an experienced person (in that industry) like a: project manager, lawyer, CPA (accountant). Lots of skills are transferable -- There is No doubt. 200 years of econometric research show us that transferable skills require knowledge of 'on the ground dynamics'.
While 'on the ground dynamics' should be a no brainier, it means you can know everything about baseball but not what the wind is like, hot how the pitcher's hangover feels, or an umpire's venereal itch, etc, etc. on the day. I think Bruce wrote about dynamic code recently -- Same thing basically.
After my 2nd review of this column, to be honest; I wanted to 'defend' what I saw a my ground as an~ systems analyst. My best mentor is a Naval Architect and my dad was a Marine Engineer. If you saw 'Titanic', you probably get why I felt that getting the WHOLE dynamic picture is valuable.
Responsing to the Eckel blog (not necessarily Stewart, because I haven't digested these things) ...
* When I studied Chinese language, business and culture; I took time to compare the business culture and social dynamics using my two favourite models -- "Conflicting Values" framework and "Social Distance" (derived from Hertzberg).
* I / we used these tools to compare western and eastern cultures. Emerging industrial infra-structures with mature ICT frameworks. I can add too that in my personal dealings with people from Thailand, India, Singapore, Malaysia, China, Korea and Japan versus (say) USA, Hawaii/Alaska, Mexico, Peru, UK, France, Finland, Norway, Greece, Germany (EU places) .... There IS a difference in 'management science' (or Business Process Engineering) across local government areas -- Forget country or cultural distinctions.
* A few simple things are consistent:
-- RoI: A $1 brings you a Return (say: $1.50 out)
-- Employee engagement: Is 'Sally happy' (0-5) now? Is Sally feeling excited (0-5) by her work?
-- Personal value: Is my job making a difference (0-5) in the world at large?
-- Are my parents and children proud?
* Quite many sad things are also true; around issues of influence, corruption, politics and power that have only one link to science through the pathology of neurosis and pathology. Here I like to tell folk to go hire: "The Smartest Guy in the Room" (ennron dvd).
* About Business Processes and ICT -- I've been to the shows: Vegas, Hannover, Bonn, New York, ... talk with 'operators' (customers).
-- People usually ask for he same thing: Will it work? Will it do what I SAY? That's got nothing to do with systems analysis.
-- Systems analysis says we can do what you did last year Faster/Cheaper/Less humanely -- No problem.
* TQM says we can (instead) ...
-- Do what you did last year Faster/Cheaper/more humanely -- with benefits.
I shall stop here, because -- People in mainstream ICT don't yet have real experience of 'management science' per se.
Nor should they because 'management science' a concept applied to replaceable human units (process workers, wet backs, etc.). One day robots and machines will do that job and the programmer will be the management science person - BUT. If culture SHIFT-s ... I still don't see people allowing programmers that power((???))
Grady Booch (UML fame, [paraphrased]): You can't hide complexity you can only make middle-ware (systems), which can reduce the apparent complexity.