The Five Dysfunctions of a Team

My VP at work handed out free copies of The Five Dysfunctions of a Team (a leadership fable) to everyone in our department. I found time to read it right away, and the author recommends that I actively criticize various aspects of my teammates. I assume this also applies to his book.

Overall...interesting. I'm not sure I personally needed the first 200 pages of "leadership fable" that were summed up in the last 20 pages, but they were amusing, and I know they served to flush out the points and make them more memorable. I was also pleased that although the developer was cast as the villain in the beginning, he redeemed himself early on and became a team player. We're annoying, but we learn quick.

I'm not so certain about the allusion to the fact that sharing personal information with your colleagues encourages more, unintended, sharing as everyone relaxes, like a snowball, or some dung beetle of truthiness. I'm even less convinced that alcohol as a lubricant for executive team- building offsites is wise. For those of you who've read the book, yet might not remember that part, I quote, "Kathryn made a mental note not to have beer brought with dinner next time. But she couldn't deny being glad that things were coming to the surface." (p. 56).

I'm also deeply touched by the section on page 98 where an executive talks about how he doesn't hold other executives accountable, yet when it comes to direct reports, "I seem to hold them accountable most of the time, even when it's a sticky issue." I had a difficult time deciding if this was a direct acknowledgement that lower-level direct reports are held to a different level of accountability, a more stringent one, and that there's a little scale that measures accountabilty against power against the severity of the result/condemnation (for failure). Don't get me wrong, that doesn't surprise me, it's just interesting to see it glossed over rather than more directly stated in a management book. Maybe it's just such a given that it's not worth remarking on other than in passing. I only have to look as far as corporate job descriptions to understand the truth of that, because the higher the job description, the more esoteric the job metrics. There are specific, concrete, items you are evaluated for at each level. The further up those levels you travel (and my traveling has been local, but I've traveled) the more fluffy the language to describe the responsibilities. It becomes much more difficult to evaluate someone who is supposed to "keep abreast of technology" versus someone who "must finish assigned bug fixes using the project's primary language" (I paraphrase).

Page 145 showed a similar disconnect when a number of engineers were simply reassigned from development to assisting "sales reps with product demonstrations." I'm pretty sure being told that I was shifting from coding to sales demos, with additional traveling away from my family, and a sales rep collecting the comissions rather than me because I was only handling all the technological presentation issues, not the presentation itself, even though the rest of the job was identical, would annoy the crap out of me. I hope the author meant that they were offering this option to engineers, and that those that were so skilled might be compensated for sales without the aid of a sales rep, and that pay increases would be offered for extended traveling that wasn't in the original job description. But I get the impression that it's more like the engineers are just playing pieces on a game board.

And on page 159, there's a power struggle where an exec walks away with three months severence, all stock options vested, and a statement that she resigned on her own. That has so little to do with how my position functions that any tension there's supposed to be is instead somewhat humorous.

I also found the joke that "Engineers don't golf" as an instance of an executive "lightening the moment with humor" (141) to just be a reason not to joke with your superiors. Engineers do golf. They just golf on the public course.

Then again - the book is aimed at executives and not engineers, and I do recognize my VP's good intentions and what she got out of this book and what she's hoping we walk away with as regards a good team. But the disconnect between the executive level and my level leaves me hoping that the real benefit is that my execs are reading this book and benefiting from it as good teamwork on their level has, in my experience, a visible impact on the morale at my level. I prefer to think of it as "we're trying to implement this positive pyramid of team building" rather than "we think you need to work on this positive pyramid of team building." There aren't trust issues on my project team, and as far as sharing personal information, they know how to find my blog and it has a little more than which child I am (1) and what my significant childhood challenge was (tying my shoe). And while they don't have blogs, I know considerably more than that about them as well. I know we're on the same page, and that we have a functional team with perhaps a slight wavering around "fear of conflict", though even there we know enough about each other to recognize our conflicts with each other and accept them as surmountable.

But mostly I just like quoting from it when I recognize a behavior, because that's sort of annoying. I trust they already know that about me.