Managing badly against the grain

Bob Sutton (author of The No Asshole Rule) has an interesting article at Harvard Business Online on the discontinuity between the accepted wisdom regarding 'superstar' employees and the objective evidence about that wisdom. I've got family members in the HR consulting area, so I find this sort of thing interesting, but I came across this bit about the No Asshole Rule which seemed worth sharing:

“there were several CIOs who emphasized that such bosses and work climates not only drove people out, but they created environments were people devoted too much energy to avoiding blame and the wrath of others, and not enough time to actually doing their jobs”

Have you ever experienced an asshole boss or work climate? I have, at two different workplaces, and it took a terrible toll both times. Apart from the fact that it wears you down to deal with such dysfunctional people, it can influence your own attitudes, so that you find yourself exhibiting signs of being an asshole yourself, not to mention taking on full-time blame avoidance and wrath dodging.

It doesn't help that asshole behaviour usually comes from people you feel you should respect (they're senior, the cream of the crop, the respected director, the firm's rising star), which can hide the harm it does if you let it make you too self-critical (they're right, I'm not good enough, I screwed up, I don't deserve this job ...). But the truth is that if a manager criticises your performance, does nothing to help you improve it, and yet expects improvement - then they are acting like an asshole.

When it comes to looking at what managers should do, Bob Sutton suggests we look at evidence-based management. Jeffrey Pfeffer runs a website about evidence-based management and recently testified to Congress about it. He summarised his testimony into five points (re-formatted by me):

“First, organizations in both the public and private sector ought to base policies not on casual benchmarking, on ideology or belief, on what they have done in the past or what they are comfortable with doing, but instead should implement evidence-based management.

Second, the mere prevalence or persistence of some management practice is not evidence that it works -- there are numerous examples of widely diffused and quite persistent management practices, strongly advocated by practicing executives and consultants, where the systematic empirical evidence for their ineffectiveness is just overwhelming.

Third, the idea that individual pay for performance will enhance organizational operations rests on a set of assumptions. Once those assumptions are spelled out and confronted with the evidence, it is clear that many -- maybe all -- do not hold in most organizations.

Fourth, the evidence for the effectiveness of individual pay for performance is mixed, at best -- not because pay systems don't motivate behavior, but more frequently, because such systems effectively motivate the wrong behavior.

And finally, the best way to encourage performance is to build a high performance culture. We know the components of such a system, and we ought to pay attention to this research and implement its findings.”

The assertion that organisations are sending their managers to courses and drafting their policies based on what is essentially made up rules is scary. Just because we wish something were true, doesn't mean it is, and acting otherwise is plain stupid.

Bringing that back to project management, which is my personal sphere of management experience, and Ross Pettit at The Agile Manager blog just posted on Patterns and Anti-Patterns in Project Portfolio Management. The anti-patterns he mentions are worth noting, although I'm not sure I buy the conclusion that Agile Management is the answer.

A good analogy for this stuff is the carpenter that stubbornly tries to plane against the grain and is unhappy with the resulting jagged finish. It is fair enough to say that in our personal experience we may not experience a particular situation often enough to be able to derive statistically relevant rules from it, but when others have done it for us, it behoves us to educate ourselves before we act.

[UPDATE: Another carpentry analogy is that we need to learn the trade and the tricks will follow. Too often we look for management shortcuts (the tricks) rather than getting the basics (the trade) right.]

Thinking of self-education, I'm in a place right now where I'm wondering whether I'm a software developer or a project manager. I find myself reading things like The Pragmatic Programmer and dis.cipul.us and tinkering with Ruby on Rails apps at home (my breakable toys) which clearly is part of my developer persona, but I also am interested in management and love the challenge of tackling projects at a level well above worrying about my daily tasks.

Articles found via Thoughtworks' Jason Yip here and again here.