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 |
Wednesday, August 27, 2003
Tuesday, August 26, 2003
Engineers are humans
Ned Batchelder sent me a link to his post, Engineers are People. I really like the way he compares emotions and hunger. Emotions are like hunger Imagine workers weren't allowed to eat lunch or snack during the day, and hunger was considered a weakness that should be suppressed. Hunger would become a huge issue. Tensions would grow, and tempers would flare. Workers would constantly be struggling with their shameful hunger. The workplace would be a mess. Now put "emotions" in place of "hunger", and you understand the modern workplace. Both hunger and emotions are natural parts of being human; we wouldn't think of asking people to check their hunger at the door. (We wouldn't, would we?) I wrote about this a while ago and in an article on stickyminds.com First Things First. Ned goes on to offer some advice for managers: Here's some quick advice for managers on treating engineers like people. What to do with a bad employee If an employee is doing a bad job, do these things until the situation gets better: Ask him to improve. Ask him if he needs help. Ask him if everything is alright. Repeat these last steps a few times. Let other people in the company know that the situation is getting bad. Get someone else to repeat these steps a few times. Tell him he's going to be fired if things don't get better. Do it all again a few times. I'd add a refinement: When you ask the engineer to improve, tell him what success will look like. Give him specific examples of the work or behavior that isn't acceptable. Provide specific examples of what is acceptable. Agree on how you'll measure success. More on Managing a Struggling Employee here. More on providing effective feedback here, and in the current issue of my newsletter (send me an email w/ surface address, and I'll send you a copy.) Chris Morris comments via email: I like to think of emotions as 'nerves to the soul'. The nerves in my skin give me feedback on interactions with my body; emotions give me feedback on interactions with my beliefs. Yes, indeed. Our emotions are an internal feedback system. | Tuesday, August 19, 2003
Get it on paper
Johanna Rothman writes about the importance of a written job offer on her Hiring blog. Yes, get the offer in writing. And pay attention to how the offer process goes. A friend of my recently went through a protracted process where the hiring manager would offer, then waffle. They'd talk, then he'd change his mind. They'd agree, then he'd withdraw the offer. By the time my friend called me, she was frantic. She needed the work and wanted the job. "What's it been like going through this process?" I asked my friend. "I feel jerked around!" she responded. "I don't trust anything this guy says." Consultants have a little saying: As goes the contracting, so goes the contract. (Originally from Peter Block, I think, but all my books are packed right now, so I can't check.) I advised my friend to look for other options. I bet offers isn't the only place this guy waffles. | Monday, August 18, 2003
A story about changing monoculture
Tim Bacon cites another cause of monoculture: Monoculture emerges very quickly in software development teams that impose a 'standard' IDE and OS, that use a predictive (not adaptive) lifecycle process, or where developers are expected to work the same hours on rigid pay scales in cube farms while adhering to a dress code. I suspect that in some cases monoculture comes about through unawareness. Other times it's a conscious choice: I worked with an organization that formulated their hiring and promotion policies to create a uniform, stable culture. They generally hired people right out of college, and promoted from within. The corporate culture was inculcated every step of the way... And for a long time, the company achieved what it wanted: stability, predictability, orderly succession. Then the market changed around them, and they needed to create different products and serve their customers in a different way in order to survive. unfortunately, the majority of the people only knew how to do things one way. Management shifted their policy, and started hiring middle and senior managers from outside the organization. Clash! Many of the "outside" managers left after a brief tenure -- impatient with the (glacial) pace of change. Many of the "middle generation" of employees, those who had been there for a while but still had 25 - 35 years left before retirement left, too. The culture did eventually shift, but it took nearly 10 years. Here's the irony: the new wave brought in to make the company more "nimble" found that the old wave weren't eager to follow the new way of doing things. So they established standardized technology, processes and created a multilayer oversight organization to make sure that people do things the new way. The culture is different in lots of ways -- it's not as warm, not as easy-going. But it's still a monoculture, just a different monoculture. | Friday, August 15, 2003
LeGuin's Law
Steve Norrie points us to LeGuin's Law from Jerry Weinberg's More Secrets of Consulting. It's a great quote from Ursula LeGuin's The Left Hand of Darkness: "When action grows unprofitable, gather information. When information grows unprofitable, sleep." My little exposition on LeGuin's quote (originally in STQE) is here. | Monday, August 11, 2003
How to ask for help
A friend of mine is learning to ask for help. He's a smart guy. He's been successful in the corporate world, and before that he was successful in school. And that might be part of his difficulty. We are taught that asking for help is a *bad thing.* Asking for help is a sign of weakness or incompetence. Asking for help means you haven't been able to figure it out on your own. Asking for help = admitting failure. So I came up with some ways for my friend to ask for help that invite another point of view without admitting failure: Can you walk through the alternatives with me? I want to be sure I've covered the important points. I need another option for this problem. Will you explore the situation with me and give me your opinion? I want to check out my thinking on this. Will you play devils advocate? I'm a little stuck on this. Will generate some additional options with me? Can you point me to some resources [related to this one thing]? I haven't done this before. Will you walk through my thinking with me? How do you ask for help? Paul Leclerc sent this answer via email: "By being humble enough to ask for it. The other day, I asked our resident Java guru a very simple, very basic question. It was something 'any Java programmer should know'. I told him I had a stupid Java question and just asked. I expected to be laughed at but he was actually quite humble himself and answered without making me feel stupid. Now I know how to ask for help. Just ask." | Friday, August 08, 2003
monocultures
James Bullock commented on an earlier post, The Delegation Test that one of the pitfalls for managers like Renee is that they often "Create a monoculture by hiring / keeping people who do things exactly the way they [sic] would." This is a hazard for any manager, not just micromanaging managers. Many people have a tendency to gravitate to people who are similar in values, background and outlook. I heard a story about a research team that was a type-monoculture -- everyone on the team had the same MBTI type. They were all bright and creative. After a year they had a ton of great ideas.... but nothing concrete and no plan to achieve anything concrete. And I've heard managers say (really!) that they hire people who think like they do, but aren't quite as smart -- a prescription for failure! Who will challenge the managers thinking? Who will come up with new ways to do things? A healthy range of perspectives is critical for a well-functioning group. That said, look for people who can adapt to the culture of the organization and team. | Thursday, August 07, 2003
You really can't do more with less
The other day I was talking to a friend who is trying to accomplish the work he used to do with a staff of three with just himself and one other (junior) person. "We're all stretched so thin that if one person takes a day of vacation, it's a disaster," he said. He'd taken a day off. And it was a disaster. More and more of us are being asked to "do more with less." I really dislike that phrase. It's meaningless. HBS Working Knowledge offers this article: Understaffed and Overworked: What Now? Let's begin with what you shouldn't do: "The sure recipe for failure is to suck it up and try to do it all," says Isabel Parlett of Parlance Training, a Santa Fe, N.M., firm specializing in business communications. "You'll burn out, your team will resent you, your reputation will suffer, and the work probably won't all get done anyway." When you're asked to do more with less, don't suck it up. Prioritize relentlessly. Decide what you won't do. Re-evaluate what "good enough" means. Work 40 hours a week. Don't fall for empty phrases. | Wednesday, August 06, 2003
Dialogue or Debate?
Brian Marick posts this note he wrote asking for friendliness and civility in a mailing list debate. I'm with Brian. Debate is an argument between opposing points of views. Debaters support their own position and focus on weaknesses in the other position. People in debate seek to prove their point and disprove the others point. Debate favors those with the best debating skills, not necessarily those with the best ideas. Some one wins and some one loses. Dialogue is an exchange of views and supports people thinking together. People in dialogue seek to understand the others point of view, and are open to learning from it. Dialogue allows additional options to emerge. People in dialogue may not walk away agreeing with the other person, but they know more about the other person, and understand more about why they believe the way they do. In the long run, dialogue is more likely to shift opinion than debate. | |