So, these days, I’ve been on a serial-killing spree.
Last week, my blog targeted the reviled clichés — those termites creeping out of the indented grooves of your mind.
This week, I feel driven to go a step further. I am handing over a playbook to kill.
The funny thing about Experience is that you know better what doesn’t work than what does.
In the last three years, I have served clients as an Enterprise Collaboration Strategist and also worked internally as a Community Evangelist (so that I eat my own dog food) in my organization’s Enterprise Social Network.
I suppose, I know a thing or two about what works and, may be, a thing or four about what doesn’t.
Trust me, it’s an intriguing world out there — because, Enterprise Collaboration, you see, is a double-edged-sword problem. You can suffer both ways- from its failure, and paradoxically, also from its success.
For the past year or so, wizened by the painful scars of my experience, I’ve been observing and curating different patterns in which Enterprise collaboration projects get killed unconsciously, either by circumstances beyond one’s control or by wrong choices cascaded from the top.
I figure it is time to get more conscious and hand over the playbook: Do you wish to kill an Enterprise Collaboration Project ? Look no further.
1) Frame Enterprise Collaboration as a Technology problem.
If you have the license to kill, this beats every other way, hands down, because, at the face of it, it sounds so obvious. When IT departments are gung-ho about “Digital Transformation”, what else do you think they are going to do?
Research carried out by Tony Byrne and his team at Real Story Group in 2014 tells us that IT department funded 32 % of the enterprise collaboration initiatives, and also implemented 34% of them. Now, you have the license to kill, don’t you?
So, what happens when IT subverts “Enterprise Collaboration” as a technology problem?
You place the cart before the horse: You envision Collaboration platform as yet another “tool” to be deployed with pre-defined use-cases (when it should be ideally seen as an “Infrastructure” which allows users to discover the use-cases themselves) ; you perceive Adoption as a “decision” to be made (when it should be ideally seen as a “Process” to be undertaken along with the users) and finally, you start chasing the holy grail of “Engagement”.
2) Focus on the “Content” rather than the “Context” of Enterprise Collaboration
When an organization doesn’t set out to consciously create a new “context” around Enterprise social collaboration, the working life of the employees in the organization is bound to be controlled by the existing “content” — forces and circumstances of the workplace environment in which they work today.
“Sure, now with Slack and the 25 channels I need to keep track of, I’ve ended up with 25 new inboxes instead of the one I used to have!”.
If you, as a collaboration strategist, hear your clients complain something to this effect, you can know for sure that your focus so far has been myopically circumscribed by content, and not context.
You can also clearly see this in the way Corporate Communications takes the mantle in defining the strategy for enterprise social collaboration initiatives. Real Story Group’s Research [see the graphic above] also confirms that Corporate Communications department strategizes 25% of the enterprise social collaboration projects (while IT department strategizes 23%).
McKinsey’s recent survey on the impact of social tools inside an organizationalso emphasizes the significant role played by Corporate Communications in facilitating change through social technologies.
So, what happens when Corporate Communications department focuses on “Content” over “Context”?
The moot point of Enterprise Social Collaboration is reduced to killing Email. Chasing the holy grail of “Engagement” (more likes, more comments, more discussion threads), Communication professionals, in Walter Adamson’s insightful words, “relentlessly use their superior communication skills to push a message rather than the substance” to drive the adoption of Enterprise Social Networks, while they remain blithely unaware of where their Enterprise Social Networks currently stand in the hierarchy of communication channels used by the employee in his/her everyday work-life.
Sure, Enterprise Collaboration can save us from unnecessary Email ping-pong. But to say that Enterprise Collaboration is all about killing email is like saying Yoga is all about reducing weight.
[Now, you may not be able to appreciate this analogy if you haven’t had a taste of the classical Hatha Yoga. Nevertheless, I hope you don’t mind letting me go ahead with it]
Sure, Yoga can help you reduce weight. But, that’s not why we do “Yoga” in the first place (in Patanjali’s true-north sense of the word).
We do Yoga because we are driven to change our internal operating system — transforming the way we think, emote, and respond to life. Believe me, this is the possibility available for all organizations whenever they embark on an Enterprise Collaboration initiative. If they are willing to walk the long mile, they can completely change the way they are wired to think; get things done; and reinvent themselves for the future as they navigate through the uncharted waters of the digital age.
Myopic focus on the “content” is doomed to fail because it effectively decouples “Engagement” from Organizational change. And when organizational culture doesn’t adapt synchronously with the rapidly changing bottom-up “tides”of Engagement, you have a dinosaur in your hands, slowly inching towards extinction.
3) Distinguish “Work” as separate from “Life”
Among the ways we’ve seen so far to kill, this has to be the subtlest one,as it straddles deep into the psychological associations we have built so far with the idea of “work”.
Traditionally, the concept of “work” implied that we clearly demarcate “Work” from the rest of Life. As I had written at length earlier, the term “Work-Life” is indicative of the traditional mindset at play, as it clearly implies
Work happens at one place, and life, elsewhere. In other words, you are either living, or,working.
If you are from the old school, or too attached with the traditional idea of “work”, you are bound to be in conflict with “being social” and “doing work”.
How does this conflict manifest?
“Doing Work” demands you to work in, what behavioral psychologists call as “functionally fixed” ways — a cognitive bias which demands you to view objects in terms of their most apparent functions.
In a traditional workplace environment, where Emails and other Enterprise systems are designed to detect everything else apart from “work” as spam, this cognitive bias reinforces itself among people at large to perceive fellow humans — or, if you prefer the term Employees- strictly by their organizational roles, rather than as professionals in whatever they choose to do. To illustrate this bias by a concrete example, you are bound to think that HR teams cannot but do HR; Marketing teams cannot but do Marketing.
In an ideal scenario, when organizations deploy Enterprise Social Networks, you foster conditions for open-ended innovation, as the streams in the enterprise social networks, as Venkatesh Rao had put it eloquently in his Breaking Smart series “constantly present unrelated people, ideas and resources in unexpected juxtapositions”.
However, in reality, when organizations deploy Enterprise social networks, and expect employees “to be social”, conflict is inevitable, as “being social” undermines the authority invested in a “role” defined by the organizational chart.
When you are able to relate with your boss on multiple equations (beyond a boss-subordinate equation)in an Enterprise Social Network, you naturally undermine the incumbent authority in the organization to get things done.
Unless we deeply question the assumptions anchored with the meaning of “work”, we are going to be shackled by this age-old pattern which can kill all the possibilities of innovation offered by Enterprise Social Networks.
4) Divide Software Systems into Systems of Engagement and Systems of Record.
It’s in our human nature to succumb to the most logical sounding solution whenever we find ourselves trapped between polar opposites. How do we design for empowerment and also for control?
Yes, the logical answer is to split them into two, and that’s exactly what we did when we heeded to Geoffrey Moore’s advice and divided our Enterprise systems into Systems of Record and Systems of Engagement.
Now, this is a classic recipe to kill Collaboration because this advice is undergirded by the good faith that system architects of systems of record and systems of Engagement would collaborate between each other effectively to provide a unified social layer where users can seamlessly move between communities and traditional work records stored in HCM systems.
What are the patterns you are familiar from your experience which can kill an Enterprise Collaboration project? Would love to hear your thoughts!
An earlier version with 3 Ways to Kill an Enterprise Collaboration Project was published in LinkedIn.
If you liked this post, and feel like indulging me, you can check out these related posts on the same topic
Thank you for reading. Please do consider recommending this post if you found it valuable. If you like to read my posts, do click on “Follow” (at the top of the page). And, of course, feel free to connect via Twitter.