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.
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.
</UPDATE>
Thanks for the mention Marc, and a good follow up post. It’s always easier to get the cheque book out and buy something than to try and change something as difficult as behaviour though isn’t it? That basic fact will be enough to ensure that the incredibly high failure rate for most enterprise social projects remains in place.
Anyone who has kids knows that money can’t buy good behavior. It’s a lot of work on top of that.
M.
And there’s always the “bad seed” scenario…
Very well put Marc.
My current role revolves mainly around making operations more efficient while project managing the software release life cycle. In the move to agile, I have been faced with this for the last 2 years – the desired to change (behavior) and increase collaboration.teaming. (key word: desire)
“That starts with the people at the top and trickles right on down” – So true!
I hear management “talking a good game”, but see very little effort to help change. I’m often asked to make enhancement to our Agile tool hosted on SharePoint that further detracts users from actually interacting and collaborate with each-other. I spent allot of my time trying to convince folks of the (bad) behaviors such changes will drive.
I think when we started installing software like SharePoint and Lync, we thought we would encourage collaboration, but you’re right, it’s a human thing. Our goal now is to make it easier for the people who want to collaborate to do so. software is essential to that, given the mobile and separated nature of our small company. For the folks who don’t want to collaborate, at least we hope we can collect their work product for those who need it.
Hi Marc. Thank you so much for reading and linking to my article. I would still stand by my comment that ambiguity kills collaboration. One might say that innovation and collaboration arise if you just let teams alone and let them do their thing. In my experience, you need to create a super structure, and nudge teams in the right directions to achieve these outcomes. In the absence of an organizing structure, teams do not self organize.
Ambiguity absolutely does *not* kill collaboration. This is confusing the causes vs the conditions. Collaboration is in fact commensurate to the level of complexity that exists. What you need are the right *conditions* in place for collaboration to foster…
http://www.cleverworkarounds.com/2013/08/19/rethinking-sharepoint-maturity-part-1-conditions-over-causes/
Thank you, thank you, and thank you. We spend a great deal of time and treasure on “People-Ready Software” (as a popular tag line is phrased), often at the expense of “Software-Ready People.”
Even as someone raised on concepts of measurement and ROI, I agree strongly that the twin themes of serendipity and ambiguity define most knowledge workers’ days a helluva lot more than rote, structured “collaboration” in the form of automated workflows.
Mike:
Given the “K” in your former employer’s name, I know that you and I are cut from the same cloth on a lot of this stuff. Now if we could only get more of the bitheads to see it!
M.
If you lead a horse to water, she still needs a good reason, and not a small amount of nudging, to drink. Many of my clients who invest time, money, and reputation on a “great new set of collaborative tools” (regardless which ones they are, exactly) find that the instant collaboration and magical camaraderie they hoped for were in fact the products of an overly optimistic imagination (or perhaps an incredibly persuasive “tools” salesperson).
Most teams need a compelling raison d’etre, to try new collaboration tools, or they’ll quickly revert to the old way of doing things. They have to see new tools as helping them to do something they need to do anyway (like sharing key documents, or creating a shared work product of some kind), vs. doing something that’s tacked onto their very full plates.
If organizations provided their work teams with customized training as to how they can take advantage of collaboration tools, given their roles, deliverables, etc., I think we’ d see adoption take off like a shot. Instead, I see generic “tools training” offered (and quite infrequently at that), leaving people to continue to scratch their heads as to how they can use collaboration tools to do their work better, faster, or of a higher quality. So many missed opportunities, and so much $$$ being left on the table!
As some at my current company can attest, i have zero tolerance for close-minded executives or any degree of micro-management, and am an adherent to the “forced-collaboration” model. You’ll collaborate, and you’ll like it!! Far too many organizations hide incompetence behind process and bureaucracy, and I do all that i can to uncover and share knowledge and good ideas wherever they come from, regardless of age or rank. I view part of my role (in my company, and in the community) as being responsible for stirring things up, forcing people to rethink “the way its always been done.” I have been doing this too long to put up with that kind of crap.
Christian:
And your comments are the reason I, for one, would rather work with you than many others. Unfortunately, you’re an exception, as you well know.
The status quo changes slowly in most places. Systemic changes can take a generation (which is roughly 20 years, surprisingly) or longer before they really take hold. Anyone who doesn’t believe me should think back to the 1990s (assuming one is old enough) and think through exactly what is truly different in their large organization.
M.