"Theirs not to reason why,
Theirs not to make reply,
Theirs but to do and die,
Into the valley of death,
Rode the six hundred."
Lord Alfred Tennyson's epic poem is a story of a tragic defeat. Commanded by officers without a clear view of the battlefield and plagued by communication problems, the enlisted men of the light brigade were told to march into certain death, and they did. Instead of learning from this mistake, the lines above are often misquoted and glorified "Ours but to do or die."
Let's compare that military chain-of-command structure to a typical, pyramid-shaped software organization. The leadership, several levels abstracted from the work, may not have a clear picture of the situation. In healthy organizations, the line workers may present feedback, which can be used to make midstream course corrections to steer the organization back to safety.
In less-healthy organizations, feedback may be viewed as criticism or personal attack. When this happens, the organization cuts off its own ability to react and respond to change. (And change, after all, is just a fact of life in the software field.) All too often, the only employees who know anything is wrong are too scared to talk for fear of being labeled "not a team player." As a result, the entire project team, or a large part of it, may willingly and knowingly walk into the valley of death.
Yet feedback, properly aimed, certainly has saved many organizations. In fact, Kent Beck and Ward Cunningham list feedback as one of the four core values of Extreme Programming. Feedback is unquestionably good; the question is how to position the feedback for the right kind of impact. In my experience, the best way to do this is to get ego out of the way and talk about solutions.
We all know that feedback can bruise egos. For effectiveness, it must be positioned so the recipient does not feel insulted or drawn into a spitting contest. A sure-fire way to start a war is to question a decision that has already been made while it is being announced publicly. As hard as it is to do, criticism must be given in private.
Another way to foul up the works is to point out problems without offering solutions. This is a simple, natural human tendency. A discussion of an unrealistic schedule that includes a simple working system, which delivers value quickly will probably go over much better than a gripe session about how management is unfair.
It's human nature to enjoy talking more than listening. A thirty-second accusation will probably prompt a five-minute defense from the other person. Listen for the reasoning behind the defensive position. And instead of an accusation, try asking simple, open-ended questions. "What about burning the program to disk?" "What are the issues I'm forgetting?" "What does success mean?" "What trade-offs can we make?" "So, if we find bugs in test, what are our options for fixing those bugs?"
Beware. Even if your feedback is well received, and you find or fix what would otherwise have become a major fly in the ointment, you run the risk of being perceived as the "Savior" who will "put the project back on track." There is another name for a Savior whose project fails: scapegoat. Amazingly enough, personal ego contributes to this problem as well. The person that pointed out the problems in the project believes that he could run the project "better" or more effectively, and then ties his ego into the project even more tightly than the original stakeholders.
Avoiding the ego trap pays off in multiple ways. The phrase "It's amazing what you can accomplish if you don't care who gets the credit" also applies to software organizations. Point out problems with the project. Suggest alternatives. Let the people running the project adopt them as their own. You might not get the credit, but the project will be closer to back on track. After all, a career marked by project success will tend to speak for itself.
In the end, if feedback is viewed as career-self-destruction, and nothing changes when feedback is offered, you may have to hit the silk. Do you honestly want to work in that organization, anyway?
If you are a leader, the implication is clear: Don't shoot the messenger. Instead, seek out the dissenting opinion so you can achieve success. As Victor Stone put it in his article "The Rubber Stamp":
"Don't you know that a VP can get any 10 monkeys in this company together to rubber stamp just about any crazy idea? But if you want real consensus you have to dig for the opposing view because if you don't seek it early, it will find you later."
Perhaps that's a better quote to keep in mind when it comes to software projects.
Acknowledgements: Michael Kotman and Dennis Elmhirst made significant contributions to this article.
