Saturday, October 23, 2004

Stand Your Ground

I found this article titled Stand Your Ground over on Gamelan. It talks about not giving in when being pressured to do things in a way that's inconsistent with what you think is correct. I don't think the article is great but I thought it was worth pointing out for a couple of reasons. First, you seldom see articles on the soft side of the profession like this. Second, while I don't think you can simply 'stand your ground' to resolve contentions during the development process, the topic of how to deal with contention is worthy of some thought, both from the perspective of the developer and the development leader



The author approaches the issue as a developer, but exclusively from his area of experience which is consulting. While it may be pretty simple to just turn down a consulting project because you don't like the direction it's going, you seldom can do the same when working in house for a software developer. You can certainly vote with your feet and leave the company but that's a pretty drastic move. You can also just suck it up and do what you're told. Neither of those approaches is very palatable. The unfortunate tactic I see used most frequently is a variation on the all or nothing - take my ball and go home - strategy. Once someone makes their best case for why something should be done their way and it's rejected, they do their job but then distance themselves as far as possible from the project and those that made the decision.



The going dark strategy may be a fine solution from the developer's perspective but it's horrible for the development organization. Once it starts it's both difficult to cure and highly contagious. I think the onus is really on the development leaders to make sure it doesn't happen. As a leader, if people are 'standing their ground' against your decisions you really need to step back and understand what's going on and work to find a solution. If you can't convince people you need to at least make them understand your approach and why you're making the decision. If you have developed any level of trust with your developers that will often be enough.



I've done this long enough to have seen plenty of good leaders and bad. A couple of my 'favorite' examples of what not to do are as follows. When presented with the fact many developers don't agree with your decision, declare 'this is not a democracy!' or when asked how to deal with the dissension among the developers suggest sarcastically: 'how about some candy.'

Post a Comment
 
The Out Campaign: Scarlet Letter of Atheism