Dear Folks, for those interested in decision errors, Mark Mechler and I have a different take on them. I have attached a chapter from Handbook of Decision Making, Nutt and Wison (eds), Wiley, 2010, that you might find interesting.
Regards, Kim Boal
-----Original Message-----
From: Organizational Behavior Division Listserv [mailto:
OB@AOMLISTS.PACE.EDU] On Behalf Of James Howison
Sent: Wednesday, July 29, 2009 6:53 PM
To:
OB@AOMLISTS.PACE.EDU
Subject: [OB-LIST] Request for references on subordinate consensus and management risk-taking
A friend asked me today if there were any studies which could help
shine a light on a team decision-making/management issue he is
facing. Nothing immediately came to mind, but it seemed interesting
enough to share with an audience who might.
Anyone know any relevant studies, or perhaps just the appropriate
vocabulary for searching? If people reply off list (don't feel
compelled to), I'll compile a summary of responses.
Forwarded email from Alfred Perlstein:
> So, I wanted to run a philosophy by y'all and get some feedback.
>
> Some of the engineers (staff) blame management for not making
> decisions and hence "fixing things".
>
> My take on it is that it's our fault as engineers for not coming
> to a consensus to push management towards for various issues and
> solutions.
>
> Simply, if you have 10 people with divergent opinions on how to
> proceed the natural reaction of a risk averse manager is to maintain
> the status-quo hoping not to break things any further. Why? Because
> if he picks a single solution and it fails, he has a 9:1 ratio of
> people that are now complaining about him. Additionally if quizzed
> by upper management the manager can easily report that "opinions
> on a solution are divergent and have not been worked out".
>
> Is it right to blame ourselves for this?
>
> Even a true risk taking leader would probably be resigned to maintain
> the status-quo in the face of such lack on unity on his reports
> because he could not expect them to step up to implement the solution
> he goes with unless given some pretty heavy do-it-or-you're-fired
> fire-power.
>
> Additionally it even discourages a single contributor from attempting
> a solution due the expected fallout of nit picking again from the same
> group.
>
> What's your take on this?
>
> Is there a formal statement of this problem?
>
> Is there a formal solution for it?
>
> Honestly since I've been speaking this sort of talk at work and
> putting the blame back on "our" shoulders I've been able to get
> people to come to a strong to grudging consensus so it seems to be
> working. I would like to have some kind of study or something to
> back up my position on this.
>
> --
> - Alfred Perlstein
> .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
> .- FreeBSD committer
James Howison
Post-doctoral Associate
Carnegie Mellon University
http://james.howison.name