Red Squirrel Reflections Dave Hoover explores the psychology of software development

[Previous entry: "Two Excellent Books"] [Main Index] [Next entry: "Timing and Rhythm"]

Raising the Bottom
Monday, April 12, 2004

Last week I discovered that Ken Schwaber has spent time as a volunteer marriage counselor. I emailed him, curious to know if/how his experiences had shaped his approach to software development. One of his insights caught my eye...

"People only change when something is dramatically wrong, forcing them to reassess. Otherwise, dysfunctionality is preferrable."

This reminded me of "raising the bottom," a therapeutic technique that is used with someone who is not going to change until he hits "rock bottom." The sooner he can realize that something is dramatically wrong, the sooner he will improve. "Raising the bottom" involves coordinating a "tough love" support system that facilitates the person hitting rock bottom and then supports him as he reassesses his situation.

I'm wondering how well this idea might map to software development teams. I think consultants can sometimes become enablers of dysfunction. Rather than helping a team feel their problems, we too often treat symptoms or overcompensate, delaying the priceless feedback that hitting "rock bottom" provides. How can we as consultants "raise the bottom" for a dysfunctional team without destroying the team in the process? Any ideas? Any experiences to share?

Replies: 7 comments

I think the idea of 'raising the bottom' is a valid one, but I think that this is only effective to the degree that the person doing the raising is trusted and to which they can effect consequences. A consultant's ability to do this may be limited if they are perceived as being 'out of family' with relationship to the team, and so not accorded a sufficient level of trust. Also, a consultant is likely accepting payment from the organization, and so there is a limit to the kind and amount of consequences s/he can enforce. On the other hand, the consultant is in a position to view with a less biased eye, and to offer suggestions to team/organization members who have trust and can enforce consequences.

Posted by Patrick Morrison on 04/16/2004

Yes, there must be trust. And it can't just be one person "raising the bottom," it is an intervention that needs to involve an entire support system.

Chris Morris and I discussed what "raising the bottom" might look like in a software development environment. For a team with a lack of test coverage, "raising the bottom" might mean speeding up the release cycle. The sooner the team feels the pain of holes in the tests, the sooner they will recognize the problem.

Posted by Dave on 04/16/2004

Raising the bottom by speeding up the release cycle can lead to not recognizing the need for better test coverage, but blame being set on the release cycle itself - in other words, blaming the person or idea that tried to make the dysfunction more obvious instead of seeing the dysfunction more clearly.

Posted by keith ray on 04/20/2004

That's true, Keith. It's similar to a child blaming his legal troubles on his parents because they turned him in for selling drugs. They believed the path he was walking would end him up in trouble with the law, so they made sure it would happen in the quickest, safest way possible.

The child will likely not experience it as "rock bottom" if the parents act alone. He will view his parents as the problem, even as he sits in a detention center, charged with drug-related crimes that he committed.

For the child to experience the "rock bottom" effect, a wider portion of his social system needs to be involved. I'm wondering what this might look like on a software development team. It might not be applicable...I'm not sure.

Posted by Dave on 04/20/2004

Historical note: Larry Constantine, a prime mover of structured design and usage-centered design, was also a marriage counselor and co-authored a book called Group Marriage.

Posted by Fred on 05/11/2004

I was excited to learn about Larry Constantine's therapy background a couple years back. Constantine's Peopleware Papers is currently at the top of my reading list.

Posted by Dave on 05/11/2004

We did something like this inadvertently at a small consulting company I had with a partner a few years back. We had an employee who was sort of coasting, and in a small shop, you can't really afford that (as we were paying a good salary). So we decided to change our company organization, and let him go. He soon realized that this had been the best job in town, and that he needed to bring more energy to his future jobs, even though they were going to pay even less that we had.

I'm not sure it would have been worth it to invest serious time and energy into raising the bar while he was still working for us. (As guns for hire, our time in the office was already overbooked taking care of clients.)

Posted by Derek on 06/28/2004

Powered by Greymatter