But I Don't WANT To Work With You!

In the April edition of the Communications of the ACM, Peter Dennine and Peter Yaholkovsky discuss an interesting topic: just how do you get a group of people to stop thinking about "me" and start thinking about "we"? They are talking in broad generalities; however, it did get me thinking about how this can be accomplished in IT departments & teams.

Messes are defined as large, complex, problems that appear at first glance to be unsolvable. Really big messes have a special name: "wicked problems". Peter & Peter point out that the only way to solve problems like this is through the use of collaboration. Collaboration is defined as a working together synergistically. Here in the 21st century, this should be easy to do, right? We've got blogs that talk about important things, wikis, IM, and cell phones. How hard could this be?

Well, it turns out to be quite hard. Most of the collaboration tools that we have turn out to be pretty poor at enabling collaboration. Things got even more complicated when researchers did some testing and found out that you and I don't really like to collaborate. When we are working on a wicked problem in a group setting, we first like to use authoritarianism, then competition, then finally collaboration. Researcher Nancy Roberts says it best when she said "People fail into collaboration." So why do we do this? Two guesses: first, we seem to think that we can win in every negotiation by standing our ground. Secondly, we have a hero culture - we look for a hero to arise and solve the problem. If they solve it, they'll get the credit so why make the effort because you're not going to get any credit.

In IT we seem to encounter more than our fair share of "wicked problems". What can we do to encourage collaboration within IT teams when our very nature resists it? If we adopt a three stage process for dealing with wicked problems, we can solve them together: design, collaborate, and follow-through. The design stage simply requires us to identify all of the affected parties and what questions that they need to answer. Hosting a meeting where a moderator leads the team through a series of follow-through steps can cause collaboration to occur. Basically, you want to state the problem, have everyone discuss it, have folks start to throw out ideas, and then when people start to refine the ideas offered by others, that's when you'll see the real collaboration start to happen.

The authors finish up by asking one last intriguing question: how far up can you scale this approach to solving wicked problems? They've shown that it can work in groups of 50-200 people. The open question is if it can be scaled up beyond that. From an IT perspective, it doesn't matter because that size works well with departments or specific project teams.

In the end, collaboration happens when a team or department comes together to create a solution to a wicked problem that takes care of everyone's concerns at the same time. It sure sounds like we should be trying to make this happen just a little bit more often!


Tags: authoritarianism, collaboration, competition, problem solving

Fix It & Forget It? Nope, Doesn't Work For IT

If, like me, you actually enjoy reading the 100+ business books that get published every year then you are probably well aware of what I like to call "the silver bullet syndrome". In any given business book, the author generally describes a problem, documents the approaches that had been tried to solve the problem, and then finally gets around to describing the solution that finally saved the day. You can pick your favorite management strategy: TQM, Black Belt, Just In Time, etc. and there are multiple books that basically tell the same story.

That's why when I was leafing through the Theory & Practice section of the Wall Street Journal, my attention was caught by an article by Phred Dvorak titled "Experts Have a Message for Managers: Shake It Up". The gist of the article was that management practices that solve a particular problem at a given point in time can eventually turn on a company. This has some significant impacts on IT teams.

The article goes on to say that if you keep doing the same things over and over, even if they made you a great department at one point in time, then they will eventually lead to problems. The reasons for this dire eventuality is because you can develop tunnel vision, start to resist new ideas, stop experimenting, start to build silos, and stop being able to adapt to new changes. Dang -- I though that if I could only find & read the right book, then all of my problems would be solved.

It turns out that the experts recommend that in order for an IT department to succeed in the long term, you need to set up processes & procedures that naturally cause tension and collaboration at the same time. Having both of these conditions present at the same time will help keep the department open and able to change. You have to be careful to mange both of these -- too much of either will result in a workplace that nobody wants to be a part of.

Ok you say, so how can this be done in my IT department? You have many choices: reorganizing the department is a quick and dirty way to shake things up quickly. How about telling everyone that their job descriptions are only temporary. There is the IT classic: give different managers different goals (reduce costs, produce twice as many products). Separating tasks and making mangers dependent on each other in order to complete projects will also introduce new challenges.

At the end of the day I guess we are all just a little bit like zoo animals. We can get very used to what works when it is working well. We say that friction is bad, but it turns out that we all need just a little bit of conflict in our lives in order to keep us engaged in what we are doing.