insights you can use |
|
|
"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)  Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) 
Archives April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 April 2006 March 2006 February 2006 January 2006 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 Contents (c) 2003-2006 Esther Derby I also publish a quarterly newsletter for people who manage in software organizations. If you'd like to receive the newsletter, drop me an email. It's on paper, so please include surface coordinates - name and full address. 
Syndicate this site (XML) 
Links 
|
Tuesday, October 18, 2005
People who lower productivity
In a recent post, I described a situation where one "brilliant" person is actually reducing the overall productivity of a software team. He's writing lots of code, but no one else can figure it out. He claims that his teammates are just too stupid, and he's got his manager convinced he's an order of magnitude more intelligent than the rest. Here are the three ways I usually see this play out once a manager decides to call the hostage crisis. Some times the person hasn't learned yet that elegant complexity is not the goal when writing code that other people will work with--and that writing comprehensible and as-simple-as-possible code is actually more challenging than writing a tangled mess that (sort of) works, as long as no one touches it. Mentoring and coaching on design and technical skills can help. It's a matter of maturing in the craft. Other times the person doesn't realize the impact of his or her behavior. Many of us in the software field value "smart" over anything else...to our detriment when we actually have to work with others to produce results. Feedback (describing the behavior and the impact of the behavior) and coaching (building collaboration skills) can help here, too. And then there are the people who are actively withholding information and/or making it difficult for other people to succeed. They are convinced of their own brilliance and believe that exempts them from the irritations of normal commerce. When a person like this isn't willing to change, terminating employment generally is the most effective counter measure. If this seems harsh, step through the consequences of allowing the situation to continue. Or think about what happens when the indispensable person decides to take a hike (or gets hit by a bus). Sure, it takes some time for the other people to get up to speed, but the resulting situation is almost always more satisfying for the team and healthier for the company (in terms of risk and cost). | Sunday, October 02, 2005
Taste Test
You can read an excerpt from Behind Closed Doors over at Daniel Read's developer.* While you're there, aslo check out the classic Places to Intervene in a System and the afterward by Don Gray. | |