Speaking Truth to Power
In the current issue (November 2006) of Better Software magazine, Norm Kerth has written an article regarding Speaking Truth to Power � How to Break Bad News to Those Who Can Crush You. Norm is well known for his book on Project Retrospectives, published in 2001, which is still fresh and resonating well within today's Agile teams as the guide on how to run an effective and powerful project review.
In the article, Kerth discuses 10 principles that help to guide your interactions with power in delicate situations. I'll simply list them to give you a flavor for the content �
Principles:
- Know more about the issue than anyone else in the organization
- Grow a small number of like-minded allies
- Initiate a grassroots effort to begin educating a wider base of colleagues
- Practice before going on stage
- Make sure your goal is to help the organization rather than to attack individuals
- Claim your personal power
- Timing is critical. You need to choose an effective time to speak truth to power
- Be respectful
- Offer options, including the "do nothing" option
- Be humble and egoless
Now I'm a big fan of Norm and his work. However, these principles strike me as being a bit "old school." There is an overwhelming implication that the principles apply to us (team members, colleagues, the powerless, etc.) in dealing with them (management, "the man," the all-knowing, the powerful, etc.) when it comes to the inner workings of things in technical organizations.
The reality is that we'll detect broken things—things gone awry or about to go awry—that management won't be privy to and really don't want to hear. You see, management is often bent on hearing good news only—they often operate under the self-deceptive notion that all projects complete successfully on time, on budget and with the obligatory celebration.
If there is ever a need to burst through that bubble of nirvana, than one needs to proceed very, very carefully. (I almost envision Elmer Fudd making this point :-)
However, if you turn this view around and reframe it as a situation in a metrics-based organization—one that values visibility and team-based empowerment—then the entire article changes.
In this case, everyone has the visibility to see the data that would surround and reflect the situation. Not only would it be visible, but the team and the organization would be reviewing and analyzing their performance transparently, in real-time, and determining next-step progress. If something shows up that is a concern, mostly everyone should detect it—or at least more than a single voice or small, lonely group.
So if we have energy to devote towards change, I would encourage everyone, instead of learning how to Speak Truth to Power, to drive ourselves, our teams and our organizations to more clear visibility into organizational metrics. To learn how to invest in real-time analysis of our project and personal metrics—reviewing our trends, and reacting to our actual performance.
And when we detect an issue that needs attention, we shouldn't worry so much about how we say it. Instead, the very nature of our model is metrics-driven insights that lead to pretty much self-evident performance, issues, adjustment, and then issue resolution.
So let's revisit Kerth's principles from the perspectives of (1) a metrics-driven development organization and (2) from an Agile, self-directed teams. I think it will fundamentally change things and we'll do that in the next post.
Continued in a future post...
Previous Post:
Redirecting Lost Time — Towards Impact
Next Post:
Speaking Truth to Power, Continued
