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!