Archive
The Uselessness Of MBAs
Two of my favorite management (or anti-management, if you prefer) thinkers and doers, Henry Mintzberg and Ricardo Semler, talk about the uselessness of MBA degrees for managing people in this MIT World video. In the video, Mr. Semler interviews Mr. Mintzberg shortly after the release of Mintzberg’s book, “Managers Not MBAs“, in 2005. The interview is conducted in front of a class full of MIT MBA students.
In case you’re interested, here are some of my notes:
This will work in practice, but will it work in theory 🙂
You can’t create a manager in a classroom. When you do that, all you do is create hubris.
MBA students are taught how to apply business skills in an assumed command-and-control hierarchy, not how to be a manager. B-schools don’t distinguish between the two.
Management is craft (rooted in experience), art (rooted in creativity) and analysis (rooted in science). It’s not just analysis – which is what B-schools exclusively teach.
Earn a management position first, then go to business school while you are a practicing newbie manager.
There are no naturally born surgeons, but there are many natural managers who never went to MBA school.
The problem with being in a rat race is that if you win, you’re still a rat 🙂
In a study of Harvard MBA gradutates, 10 of 19 were outright failures, 4 had questionable records, and 5 did fine.
The notion that a generic manager can parachute in and manage anything is crazy. There are exceptions like IBM’s cookie man, Lou Gerstner, but failure is the norm.
Many managers practice “Kiss up, kick down”. The dudes who receive the kisses don’t care or want to know about the “kick down” behavior.
Without action, nothing gets done. Without reflection, action is mindless. Thus, mindful action is required for success.
Watching Closely
Please tell me what type of manager broadcasts statements like this one:
“Since there were no major accomplishments reported on this task last week, I’ll be watching this task closely.”
When I see or hear comic statements like this, I privately think to myself (but never publicly speak, of course):
- What are you gonna do to help if reported status is not up to your lofty but unarticulated expectations next week?
- Are you gonna issue more pointed and specific threats to the DICs assigned to the task?
- Are you gonna ratchet up the pressure even more so?
- Are you gonna roll up your sleeves, dive in and find out what is halting progress so you can directly or indirectly help?
What would you ask yourself?
DIC Revolt
From High-Frequency Programmers Revolt Over Pay – Forbes.com:
“Pity the programmers toiling away at Wall Street’s secretive high-frequency trading shops–places like Goldman Sachs, Citadel and Getco. They wrote algorithms that take advantage of fleeting trading opportunities and bring in up to $100,000 a day. In return, they received a fraction of the pay doled out to their bosses.”
Now some programmers feel used and are instigating a revolt. They are doing so by striking out on their own or forming profit-sharing arrangements.
Wow! A sampling of DICs has risen above the talking, whining, complaining, poor-me stage. They’ve actually taken action toward their perception of justice. Of course, the holes they’ve created at their former Wall Street greed-masters will be filled by other willing slave-DICs who will revive the whining, complaining, poor-me tradition left behind.
Strategic And Cautious
At nights and on weekends we cry out for human rights and freedom of speech, and then we go to work and become strategic and cautious about our every word for fear we will be seen as disloyal or uncommitted. – Peter Block
The above quote reminds me of many meetings that I’ve attended. In one of these watch-out-what-you-say-or you’ll-be-in-deep-shit group fear fests, the topic of a long time dedicated and highly productive employee leaving the company popped up. The frustrating and sad thing about the experience was that even though virtually everyone knew who the person was, no one spoke his name – including wimpy me. It was like an unwritten taboo, as hinted by Block’s quote above. At the time, I thought of getting up and yelling:
“Damn it! His name is XXXX. Why can’t anyone freakin’ speak it? Even though I think most of you know who we’re talking about, what harm would befall us if we spoke his name to the ones who don’t know? Why so much fear and secrecy?”
Of course, I only thought the thought and I didn’t say squat….. preferring to remain strategic and cautious.
Wishful And Realistic
As software development orgs grow, they necessarily take on larger and larger projects to fill the revenue coffers required to sustain the growth. Naturally, before embarking on a new project, somebody’s gotta estimate how much time it will take and how many people will be needed to get it done in that guesstimated time.
The figure below shows an example of the dumbass linear projection technique of guesstimation. Given a set of past performance time-size data points, a wishful estimate for a new and bigger project is linearly extrapolated forward via a neat and tidy, mechanistic, textbook approach. Of course, BMs, DICs, and customers all know from bitter personal experience that this method is bogus. Everyone knows that software projects don’t scale linearly, but (naturally) no one speaks up out of fear of gettin’ their psychological ass kicked by the pope du jour. Everyone wants to be perceived as a “team” player, so each individual keeps their trap shut to avoid the ostracism, isolation, and pariah-dom that comes with attempting to break from clanthink unanimity. Plus, even though everyone knows that the wishful estimate is an hallucination, no one has a clue of what it will really take to get the job done. Hell, no one even knows how to define and articulate what done means. D’oh! (Notice the little purple point in the lower right portion of the graph. I won’t even explain its presence because you can easily figure out why it’s there.)
OK, you say, so what works better Mr. Smarty-Pants? Since no one knows with any degree of certainty what it will take to “just get it done” (<- tough management speak – lol!) nothing really works in the absolute sense, but there are some techniques that work better than the standard wishful/insane projection technique. But of course, deviation from the norm is unacceptable, so you may as well stop reading here and go back about your b’ness.
One such better, but forbidden, way to estimate how much time is needed to complete a large hairball software development project is shown below. A more realistic estimate can be obtained by assuming an exponential growth in complexity and associated time-to-complete with increasing project size. The trick is in conjuring up values for the constant K and exponent M. Hell, it requires trickery to even come up with an accurate estimate of the size of the project; be it function points, lines of code, number of requirements or any other academically derived metric.
An even more effective way of estimating a more accurate TTC is to leverage the dynamic learning (gasp!) that takes place the minute the project execution clock starts tickin’. Learning? Leverage learning? No mechanistic equations based on unquantifiable variables? WTF is he talkin’ bout? He’s kiddin’ right?
Ego To Talent Ratio
In Scott Berkun‘s “Managing Breakthrough Projects” video, Scott concocts a metric called the Ego-To-Talent ratio (ETTR). Here’s my highly unscientific and speculative curve that plots ETTR versus position on the company org chart.
See that bozo on the chart? That’s me. Where are you?
Crisis?, What Crisis?
The other day, I heard a song on Pandora from one of my fave albums of the 70s (yes, they were called albums back then); Supertramp‘s “Crisis?, What Crisis“. The album title reminded me of orgs that emotionally panic “under the covers” when a crisis occurs, but outwardly behave as if there is no crisis. By “behaving like no crisis is occurring“, I mean that the SCOLs in charge apply whatever band aids they can in the short term to get through the crisis but don’t do anything of substance to stave off, or better handle, future crises.
When the crisis at hand passes, the heroes are congratulated and: the org structure stays the same, the people in the top roles stay the same, the operational business processes remain the same, and most ominously, the patriarchal CCH mindsets stay the same. It’s back to the same-old, same-old, business as usual.
The figure below shows what maybe should happen when crises occur and learning takes place? Someone or some group willingly steps up to positively change the structures and behaviors so that the org can smoothly navigate through, and even thrive within, future crises. In the example below, it took 2 crises to stave off self destruction, right the course, and excel in the future. Alas, the problem with the previous sentence is the “someone or some group” phrase at the beginning.
Hurd Joins The Herd
I was considering writing a blog post about the downfall of Hewlett Packard’s CEO Mark Hurd, but I decided to back off. I figured that all the credentialed and highly respected tech columnists and bloggers have covered this horror story from all angles.
So, instead of my usual rag, rag, rag…… whine, whine, whine….. toll-u-so, toll-u-so, toll-u-sow verbage, I’ve written an empty husk of a blog post. The accompanying picture sux too….
Nevertheless, I’ll be back on my high horse and raging against the machine soon.
Ray Of Light
Ray Leggiero was a great friend and work colleague of mine. Ray would stop by my cube every other day early in the morning to talk, joke, and commiserate for a few minutes about a variety of subjects. Ray was one of only two regular commenters on this ridiculous blog. Ray often challenged my views and beliefs and made me think twice about what the hell I was saying. Ray was a Yankee fan and I’m a Red Sox fan. Ray was a Republican and I am a pseudo-Democrat. Ray was passionate about all aspects of software development and so am I.
After not hearing from, or seeing the ever-smiling Ray, trucking around the office for a week, I walked over to his cube to find out why. His cubie mate told me that Ray was sick and wouldn’t be back for awhile, so I called his house. His wife, Pat, came right out and shocked me with “Ray has cancer“. She said that he was too tired and sick to come to the phone.
A week later, I learned that Ray was gravely ill and in the intensive care unit of a local hospital. The same day we heard this stunning news, a couple of other work friends and I went to the hospital to see Ray during lunch break. We were floored and deeply disheartened when we saw the state he was in. We were so rattled and shaken by what we had seen, that instead of going back to work, we went to a bar and guzzled a few beers to calm our nerves. Ray died the next morning.
The suddenness of it all was incredibly jolting and earth shattering to many people, especially Pat and his three young boys: Anthony, Matthew, and Brandon. In the span of only one month, gentle Ray went from being a vibrant, positive, conscientious, helpful person to a very sick individual engulfed by cancer. I, and scores of other people, will deeply miss Ray’s luminescent presence in our lives.
So long my dear, dear friend.
Go, Go Go!
Rob Pike is the Google dude who created the Go programming language and he seems to be on a PR blitz to promote his new language. In this interview, “Does the world need another programming language?”, Mr. Pike says:
…the languages in common use today don’t seem to be answering the questions that people want answered. There are niches for new languages in areas that are not well-served by Java, C, C++, JavaScript, or even Python. – Rob Pike
In Making It Big in Software, UML co-creator Grady Booch seems to disagree with Rob:
It’s much easier to predict the past than it is the future. If we look over the history of software engineering, it has been one of growing levels of abstraction—and, thus, it’s reasonable to presume that the future will entail rising levels of abstraction as well. We already see this with the advent of domain-specific frameworks and patterns. As for languages, I don’t see any new, interesting languages on the horizon that will achieve the penetration that any one of many contemporary languages has. I held high hopes for aspect-oriented programming, but that domain seems to have reached a plateau. There is tremendous need to for better languages to support massive concurrency, but therein I don’t see any new, potentially dominant languages forthcoming. Rather, the action seems to be in the area of patterns (which raise the level of abstraction). – Grady Booch
I agree with Grady because abstraction is the best tool available to the human mind for managing the explosive growth in complexity that is occurring as we speak. What do you think?
Abstraction is selective ignorance – Andrew Koenig
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
