Recap

Political process is a part of human and organizational behavior. To disengage from it is to cede authority to those who choose to continue to play. It is morally and logically untenable to disengage out of abhorrence to politics and then later claim that you were disenfranchised.

As leaders, however, we do have an obligation to avoid the trap of letting politics intrude on purely technical decisions. Even at the national level, we have sometimes made the mistake of letting political concerns govern decisions that were untenable on technical merit. When facts are clear, we cannot ignore them, regardless of the political consequences. Try not to violate laws of physics.

When we engage in politics, we need to encourage good politics as indicated in this chapter. We need to become wary when we see "neutral zone" behavior starting to occur. And we need to stamp out and crush, preferably through peer pressure, bad politics.^[11] Basically, bad politics corrupts the entire process by admitting as legitimate those behaviors that are clearly unethical and of low integrity.

^[11] This would be an example of good peer pressure.

Note that even "neutral" or "gray zone" practices will undermine a high-trust environment. The advantages of a high-trust environment are so great that one should seriously consider whether the allowance of "gray zone" practices is worth the risk.

We need to ensure that in all political processes or negotiations, the "polls close," that decisions are made, that the team "signs up," and that we move forward as one to implement the decision without continuing nonproductive debate.

It has been said that for evil to triumph, it is sufficient for good men to do nothing. If you fall back on the "all politicians are corrupt scoundrels" argument, I have only two words for you: Harry Truman. Truman was no technologist, but he was a superb politician and leader.^[12] This takes us way beyond the scope of this chapter, and most likely beyond the scope of the book as well. But I am constantly (and I think legitimately) concerned that software engineers' withdrawal from a process they see as political robs the organization of important input.

^[12] My point here is that Truman was a man of incredible integrity, yet he came out of one of the most corrupt political organizations in America at the timethe Pendergast machine in Kansas City. This irony has intrigued me for years.

On the other hand, politics is not always the issue. Many developers opt not to participate because we have discouraged them in the past. Many senior people have remarked to me that managers don't listen anyway. I think this is perhaps a somewhat jaundiced perspective, but if we want participation we do need to listen. And we certainly always need to separate technical from non-technical issues.

The separation of technical from non-technical issues is sometimes very easy. Usually, what we are going to do is a political decision, and how we are going to do it is a technical one. On the other hand, there can be interactions. For example, the time and resources it takes to implement a feature (the how) can affect the decision whether to do it or not, so the how influences the what. The important thing is to be sure that engineering estimates of how long things might take are honestly given, and not motivated by what people think the political consequences might be. That is a sure way to go wrong.

But sometimes even managers who are good listeners get in trouble the first time they open their mouths. How you talk with engineers is the topic of the next chapter. I've labeled it "Negotiating," because that is how it seems to both sides. In reality, it addresses communication in general between software people.