Collaboration is About Behavior, Not Software

Supriyo B “SB” Chatterjee (@sbc111) shared an excellent article on SPYam last night from Adi Gaskell’s (@adigaskell) blog.

In the article, Adi says:

If only it was that simple. The reality is often very different however. The reality is often that most organisations are not collaborative at the moment. Employee behaviour has been ingrained through years of reinforcement, that salary and promotion are intrinsically linked to individual performance.

Changing behaviours at work requires changing the environment that surrounds people when they’re at work.

Image from Adi’s post

Big thumbs up on this one. Collaboration is a result of a culture that encourages it; culture is a sum of the individuals in the group. Most organizations tie their incentives to things that actually discourage collaboration (stack ranking, anyone?). We can implement every system in the world and people who aren’t encouraged to collaborate, won’t. This is one of SharePoint’s dirty secrets: it can’t solve anything that people don’t truly want to solve.

One of my biggest beefs with most SharePoint installations is the strong desire for workflows. We don’t do workflows for ourselves (generally), we do them *to* others. Collaboration isn’t something we force; it must be a natural step in the work process. By putting too much rigor around work, we end up discouraging collaboration. We’ve removed the back currents and eddies in the flow where serendipitous collaboration can occur. Note: I have no beef with workflows for highly repetitive, non- value add tasks, like submitting expense receipts or approving a document. If there’s any room there for collaboration, please tell me about it.

This is nothing new. The knowledge management movement in the mid-nineties suffered from similar constraints. We’re still outgrowing the command-and-control structures that were so successful in the 1950s. Those militaristic management styles work pretty well in manufacturing or assembly work, where consistent unit production is the goal. With knowledge work, there are many intangible work products like effective meetings, project management (not project measurement, which is often the tacit goal), or effective content generation.

So if you or anyone you know think that installing some software will change your company’s ability to collaborate, think again. It’s going to be a very long haul for you with a lot of wasted time and money unless you focus on the underlying incentives and motivations at the same time – or even ahead of time. That starts with the people at the top and trickles right on down. “Thou shalt collaborate” is a death knell for the very goal it espouses. “Let’s talk about how we can encourage collaboration” is oh-so-much better.

<UPDATE date=”2013-09-03″>

Pankaj Taneja wrote another take on this in his post The 3 Pillars of Collaboration, which I culled from the comments on Adi’s post.

To me, policies are good as fall backs in case of issues and can set the tone for how collaboration might work, but too many constraints quash collaboration.

I would disagree that “[a]mbiguity is the greatest enemy of collaboration”. Ambiguity is a given in life. Collaboration happens where and when it makes sense, as long as we don’t prevent it. That prevention can come from the way we implement technologies or structure incentives, but it can also be caused by an abundance of policy. A certain amount of undefined leeway is crucial to good collaboration, and that requires trust, not rules.