"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)

I came across this list of guidelines for learning on Jason Kottke's site (via Ned Batchelder).

Post script: Dale Emery points out that this list is remarkably similar to David Bohms work on Dialogue, which has been made popular by Peter Senge and others. I'm on the road so I'm away from the actual books. Jason noted the list was from a seminar, but gave no further attribution (innocently enough, I'm sure).

Guidelines for Learning

1. Release the need to be right.

2. Welcome one another's thoughts and opinions.

3. Suspend judgment.

4. Listen for understanding, not rebuttal.

5. Make personal statements by using "I" rather than "you".

6. Clarify first what was said before you challenge someone.

7. Take time to reflect.

8. Lean into discomfort.

9. Respond first to what was said before making your point.

10. Have fun.

I'd add:

11. Make the most generous possible interpretation.

I talked to a manager a while back who described a situation where a person on her team was "too angry to speak."

"How did you know?" I asked.

"Oh, I could just tell," she replied.

Truth is, we can't "just tell" what is going on for someone else. Much of the time we make up an explanation... and we're often wrong.

If we're going to make something up, we might as well make up a generous interpretation, and act out of that.

(And of course we can always check out what's going on for the other person.)

posted by Esther Derby at 9:58:00 AM  

|

When I work with a project team on a retrospective, one of the first things I attend to is the safety of the group.

I define safety as the ability to speak your truth without fear of ridicule, rejection, or retribution. Once in a while, someone has a strong reaction to the idea of safety. Usually the response is about how naive the notion is -- and we're not at work to hold hands and sing kumbaya.

I agree, we're not at work to hold hands and sing kumbaya. And, I believe that safety is an important factor in productivity.

Here's a little story (a true story, thought details have been changed) about safety at work:

A small software company hired a new VP (I'll refer to him as Jim) to revitalize a

flagging product. Jim has a marketing and sales background and the thinking was he'd bring

a strong business focus and marketing savvy to the company.

Jim has re-negotiated vendor relationships, promised customers additional releases, and overhauled the compensation structure for both employees and contractors working on the product. He's reduce costs by not hiring replacements for people who've left and he's laid off a couple more people. The remaining members of the team have sucked up the work.

The CEO has always been a has been hands-off guy and since Jim started he's been pretty removed from the day-to-day.

The dev team has been luke-warm to Jim's changes. Some of Jim's changes make sense, but it seems like, even though he has a marketing background, he doesn't understand the market for this product.

The dev team is worried about their ability to meet the new release schedule. They're concerned about the work load, and they're concerned about quality because people are working so many extra hours to cover the extra work.

Several developers have tried to talk to Jim about their concerns. Jim gets angry and responds with phrases like, "you're part of the problem!" and "I don't want to hear about problems, I want to hear how to make my ideas work!"

The developers have been wondering if the CEO is aware of what's happening on their team. They don't want to go over the new guys head...They have an uneasy feeling he'd see it as a threat.

Last week the CEO casually asked one of the developers, Randy, how things were going. He got an earful.

The CEO was justifiably concerned and met with Jim to find out what was going on.

Two days later, Jim fired Randy for having a "bad attitude."

So much for safety.

Morale was poor before the firing, now its in the pits.

Jim (and the CEO) have virtually ensured that they won't hear anything that doesn't toe Jim's party line. The developers are keeping their heads down, and focusing on narrowly defined tasks... when they're not looking for new jobs, complaining about Jim, or pining for the way things used to be.

The developers see problems brewing, but they aren't going to raise issues or point out problems. They're not dummies...They don't want to be punished.

Safety is a business issue.

People who feel safe are more productive and have better morale.

Workplaces are safe have better information flow.

When safety goes, productivity goes down and managers destroy a crucial information channel.

posted by Esther Derby at 2:53:00 PM  

|

Yep, that's me.

One of the key ideas in Tom De Marco's book Slack is that people need a little slack in their schedules to reinvent and change. Humans who are busy all the time don't have the time/ability to reflect and create new hypotheses on how to work.

I just finished eight (8) weeks of travel. I was home 2-3 days at a time, long enough to prepare for the next gig, do laundry, pat the dog, and repack.

And I'm starting to feel it. My creative energy is down and I'm moving more slowly.

And I'm thinking about the price business pays for a relentless pace.

My current plight -- not enough downtime (slack) -- is repeated countless times in software organizations.

People are pushed to work long hours for weeks and months on end. The result is not faster progress or greater productivity. It's slower reaction time, less energy, lower productivity.

So I'm taking a bit of a break. I'm walking around the lake (no snow here yet!) a lot and giving myself time to recharge. I'll be back to regular posting after a few more turns around Nokomis.

posted by Esther Derby at 6:54:00 AM  

|

Dave Hoover has an interesting post on where to look for the source of errors, Assume it is Your Fault.

I was fortunate to learn this lesson on my first programming job (very very long ago).

We didn't have a separate test group, so we tested each others code. I was testing a program written by one of the senior programmers and discovered erratic behavior in the screen displays. When I pointed the error out to my colleague, he responded, "I'd never do something like that. It must be a problem with the blah - blah."

Of course, the problem was something he'd done. I don't remember the details after all these years; and the incident made an indelible impression -- it taught me never to assume that I couldn't be the source of the error.

Later, when I working more with people and less with code, I learned a re-frame of "assume its your fault":

No one is 100% responsible or 0% responsible in a problem situation. Look for your part in the situation, and see what you can change to make the situation better. It's much easier (usually) to get yourself to change than to change someone else. If nothing else, you can change how you cope with the situation.

posted by Esther Derby at 1:47:00 PM  

|

After this afternoon's football game my husband and I took a walk around the lake. That's what we do here in Minnesota, we walk around "the lake." Never mind that there are over 13,000 lakes larger than 4 acres; all lakes are all "the lake." But I digress.

I was making dutiful "listening sounds" until some thing he said caught my attention.

Mike Tice (head coach of the MN Vikings) has been bringing in some of the best technical experts in the field to work with his team to increase their skills. And he brought in an expert on coaching to assess how he was doing his job -- to see what he could do better.

What a concept. When the team is struggling to improve, don't just look at what the team can do better; look at what the manager can do better!

I suspect that most of the time, at least in our field, we tend to look at what's not working in team:

Do the members of the team have the technical skills?
Do they understand the domain?
Can they work hard?
Do they communicate well and get along?
Are they smart enough?

What about how the manager's actions are effecting the performance of the group?

Does the manager understand the dynamics of software development?
Can he/she set priorities?
Deliver effective feedback?
Work with the customer?
Set goals?
Create an environment for success?

I like the idea of brining in a coach for the head coach. We should try that in software.

posted by Esther Derby at 8:24:00 PM  

|

Today I chatted with yet another person who works for a company that is moving to resource pools:

Technical people fill out an inventory of their technical skills and become part of a "resource pool," made up of all the people in the organization who are not currently assigned to a project.

When a new project starts up, the administrators of the pool assess the skills profile for the project and then look for matches (well, near matches) among the resources currently in the pool.

Resource pools are appealing because they sound so logical and efficient:

Resources across the enterprise are fully utilized because with a resource pool, it's possible to match a C# resource in Cleveland up with a project in Portland. No one sits around waiting without appropriate work to do.

Resource pools are efficient because they eliminate prolonged, expensive and (sometimes) error prone hiring processes.

The only problem is it doesn't work.

Nope, it doesn't.

Resource pooling assumes that people are the sum of their technical skills.

Resource pooling ignores the mix of interpersonal skills and qualities that make up a functioning team.

Resource pooling ignores the overhead of forming a well-functioning team. You can through a group together in 10 minutes, but building a team that can work productively together takes time and attention.

Resource pooling seems to forget that geographic proximity (or lack there of) does matter. It's not impossible to have a high-functioning team that works well, but it takes thought and effort. It's foolish to assume that the apparent cost savings will be greater than the overhead costs that come with low-bandwidth communication, time zone differences, cultural differences, and so forth.

I wonder how enthusiastic the executives who come up with these ideas would be if their staff was part of the resource pool. At the end of every quarter, the management team can be put into the pool and re-assigned to the next open management job. Then the executive can draw up a skills profile for his team and go fish!

posted by Esther Derby at 7:43:00 PM  

|