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 May 2007 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 
|
Thursday, December 23, 2004
New Years Resolutions for Managers
Friday, December 17, 2004
Measurements for managers
Every so often, I undertake a personal measurement project. I set myself up with a little grid printed on a piece of paper. I keep the paper right next to my computer and track where I spend my time a couple of weeks. I usually track 1/2 hour increments. At the end of two weeks, I look at the data. Based on what I see, I make conscious choices about how I'm spending my time. I'm almost always surprised by some thing in the data. I started doing this when I was working as a manager. Here are some of the things I looked at when I was in that role: Knowing where my time went helped me make choices to spend my time on higher value activities. What other things would you look to discover how well you are using your time? | Monday, December 13, 2004
More on separating pay from performance
In the last few weeks, "Agile" performance reviews have come up on one of the many lists I (sometimes) read. Since I've been thinking about this a lot lately, I piped up suggesting that traditional performance evaluations aren't actually helpful. My suggestion didn't get much response on the thread, but one person wrote me off-list to ask how to distribute bonuses, if not based on performance. Here's how I responded: "...let me start with the ideas that underpin my thinking: Focusing rewards on individuals works against collaboration. If competition is the desired end, then individual rewards work, though often to the detriment of team goals and even corporate goals. I'd look at what is behind superior performance in your group... is the person truly outstanding based on objective data and in the assessment of peers? or is his situation different? or is there something else behind exceptional performance? I've seen people who look great because the work *against* their peers, by withholding information, refusing help, etc. Some people *are* exceptionally gifted. Studies in our field show huge productivity differences between the best and worst programmers (Weinberg, and Lister/DeMarco have done work on this). If you want to do something for outstanding performance (based on data, and understanding of what is behind the outstanding performance), recognize that their market value is higher, and move them to a higher pay grade. You could divide the bonus pool equally, or give it as an equal % of salary." I'd add this: It seems to me that we've come to confuse performance reviews with feedback. Somehow the review process is supposed to give people information to help them improve. But ranking, rating, and performance evaluations are judgments not feedback. Once you pronounce a judgement, people are less likely to hear whatever feedback you have to offer. The fact that I don't think performance review/rating are helpful doesn't mean I think companies should pay good money (and give raises) to people who aren't doing their jobs acceptably. When people don't have the skills to do the job, and they have the capacity and desire to develop the skills in the timeframe necessary, work on building skills. A person who is not doing his/her job and is not interested in improving does not have a very high market value. Why pay them at all? Move them off the team. Oh, dear. I'm on a rant. | Tuesday, December 07, 2004
Retrospectives on Agile Projects
I'm in Portland this week (its raining) working on a book on retrospectives with Diana Larsen. Last evening, we met with the Portland Retrospectives Group and asked what questions and issues they would like see covered in a new book on retrospectives. Some of what we heard were topics we'd planned to cover, and some we hadn't thought of. Which made us curious... What are the topics and issues would you like to see covered? What are the challenges you are experiencing with retrospectives on agile projects? What themes keep coming up? Do you have any great stories? We'd love to hear them. Send me email. :-) | Friday, December 03, 2004
Are your questions helping you?
If you've followed this blog for a while, you know I'm interested in questions. Which questions come first? How does the wording of a questions effect the response? So I was attracted to Marilee Adams' book Change Your Questions Change Your Life and picked it up to read on a recent plane trip. It's an easy read and makes a worthwhile point: the questions we ask -- of ourselves and others -- shape our possibilities and options for action. Adams' says there are two basic paths we can take in the questions we ask, Learner or Judger. Judger questions are questions like: Learner questions are questions like: Learner questions open up possibilities, Judger questions close down possibilities. We all go to Judger questions sometimes, but when we catch ourselves in judging, we can switch to Learner questions -- and experience a different outcome. I've tried a few little experiments with myself asking different questions. The questions I choose really do influence my mood and my outcomes. | |