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 
|
Thursday, September 29, 2005
How do you spell "Productive"?
It seems that every few months I have a similar conversation: Someone asks me how to give feedback to a difficult person. This week the conversation was with a manager I'll call Toni. "What is it about this person that makes it difficult for you to give him feedback?" I asked. "He gets defensive, and he can't admit mistakes. I don't want to upset him and have him leave though; he's our most productive developer," Toni said. "How's his code?" I asked. "He really cranks out the code -- he's an order of magnitude more productive than anyone else on the team. The trouble is, is code is so complex that the other guys have trouble understanding it. And he gets impatient with them. He feels like he shouldn't have to waste his time explaining his code to people who aren't as smart as he is." "So what do the other guys who have to work with his code or maintain his code do?" "They really struggle, because the code is so complex -- I mean this guy is brilliant. He can hold 15 thoughts in his head, where most people can only hold 7, so they have a hard time understanding his code," Toni replied. "So the way he writes code makes everyone else on the team less productive?" I asked. [Long silence.] "I never thought of it that way...." (Some how the feedback problem changes at this point.) | Monday, September 19, 2005
And now, a word about mind mapping
Via the Innovation Tools, an explaination on how and why mind maps work on Between Seeing. ...since we've just been talking about using mind maps and charting to interact with written material. | Documenting Requirements Jerry Weinberg sums up a discussion on what is desirable in a requirements document with this statement: The thing that I want most in a requirement (whether it's in a document or in somebody's head or gut, is understanding. I want to customer (goal donor and gold owner) to understand what it is they're asking for, and I want the implementors to understand what they're being asked to produce, and I want the two understandings to be the same. So, as a means to that end, I want the requirements to be expressed in a mutually understandable manner, and I want the requirements process to be executed in a manner that demonstrates that understanding, and fosters it if it doesn't currently exist, and corrects it if it slips away. As far as I'm concerned, any process that does this, any documents or whatever does this, is just fine with me. And any one that doesn't, is not fine with me. You can read the whole discussion on the AYE wiki here. And, if you want to learn more about building an understanding of customer requirements, here's my article on customer interviews. | Friday, September 16, 2005
If you live in the Twin Cities (MN) area and would like to experience the book charting technique described here, my friend Cheryl Kartes will be leading a group book charting on Monday evening, September 26. The book is Presence: Human Purpose and the Field of the Future by Peter Senge et al. More info here:BDFlyer.pdf | Wednesday, September 14, 2005
Thinking and Reading (sometimes together)
Rachel reports on a different way to read a book based on Tony Buzan's work. I've used a similar method called Charting to read articles and books. Actually, I'm not sure "reading" is the right term, because Charting feels more interactive than normal reading. When I chart a book, I'm creating a picture of the structure and content of the book as well as actively pursuing insights for practical application. Here's how a quick version of Charting works: Scan the book for clues about the structure. Lay out a preliminary picture of the structure on a piece of paper. Read the opening paragraph of each chapter. Then read the first and last sentence of each paragraph. Read the final paragraph of the chapter. Note 3-4 key insights or ideas in the chapter. Give the chapter a new name based on your key insights. Once you've done this for all the chapters, look for common themes or shifts among the chapters. Show that on the chart, and give those theme names. Create an image the holds the overall meaning of the book for you. Answer these questions: Write a short critique. I may go back and go into more depth for parts of the book that intrigue me. When I do this, I repeat the basically the same process for the chapter, looking for the structure of the chapter, noting key ideas in each section, etc. I also use Charting for group book studies. Each person takes a chapter or section and uses the Charting process for that section. Then the group comes together and shares the pieces, discerning overall structure and themes. This is a way for everyone to get an overall picture of a book, generate discussion and provide a road map for people to selectively delve deeper. (I have friends who applied this method to get through their college course work.) Here's a chart I did for an article: 
(I learned about Charting from my ICA pals.) | Monday, September 12, 2005
Thinking Together
When I went to school, there was a lot of emphasis on learning to think well on our own. That's a critical skill, and we won't get far without it. And, when we start working in teams, we need to be able to think and solve problems as a member of a group -- to think together. Alot of the work I do is helping groups think together. So I've developed my facilitation skills, learned about group process, and how groups work and think together. And I'm always looking for methods and exercises to use in retrospectives, planning, problem-solving and other group processes. Last week I came across two new (to me) sites: IAF Methods Database (via Jon Jenkins) has a growing collection of methods for planning, sharing information, generating ideas, and reaching decisions. It also has methods for intervening when things are stuck or running amok. The other (via Diana Larsen) purports to be the definitive source for Idea Generation Methods. It has lots of idea generation methods (though I cannot confirm that it contains "all known" idea generation methods as the title claims). Have fun! | Friday, September 09, 2005
Building Trust
In SD PEOPLE & PROJECTS email newsletter, Amit Asaravala reports on the results of little survey on what managers do to build (or destroy trust): ... respondents who said they trust their managers praised them for being honest, fair and open-minded: "I may not always like what he says, but I know he's giving the answer 'straight up.' I can count on his bar being high, he's predictable and he backs me and my team up." "She is honest -- both with good news and bad news. While she does do some politicking that I don't like, it seems to be necessary. She doesn't stab people in the back." "I feel my manager strives to keep both my interests and those of the organization in perspective during the decision-making process." "Explaining why the decision was made and usually involving me in the decision-making process gained my trust." "[My manager is] open, communicates, is respectful of others, and has given me no reason to think that they're not trustworthy." This is consistent with my experience. People don't expect their managers to be perfect. They do expect to be treated with respect and to be treated as adults -- capable of making decisions, understanding others' decisions, and handling bad news. People expect that their managers have to live within corporate realities -- but not roll over at the first push from senior management. They expect their managers to consider the interests of the team and advocate for them in the face of un-feasible requests. PS: If you want to learn more about how managers build trust and provide value to the team and the organization, check out Behind Closed Doors: Secrets of Great Management, available now in PDF and soon in hard copy from the Pragmatic Bookshelf. | Wednesday, September 07, 2005
Nicer *is* Smarter
Over on Jerry Weinberg's SHAPE Forum, there's a discussion on what we've learned about XP over the last few years. One of the themes is that success depends on the human interaction skills of the people involved. (I guess we could say that about any method.) So when I see techies wearing T-shirts with slogans like "I'll be nicer if you'll be smarter," I think we're missing the point: Nicer is smarter. People who are pleasant to work with --people who have developed their human interaction skills -- get more done. They contribute to the positively to morale and to the bottom line. Sure there are competent jerks -- and we work with them when we must. But given a choice most people would prefer to work with someone who is competent and pleasant. And some research shows that given a choice, people will choose working with a less competent, but pleasant co-worker over working with a competent jerk. (Plus, being pleasant is free.) | |