As more senior leaders begin to understand the power of social learning, more and more businesses are willing to invest in collaborative tools. It’s almost impossible to stop the momentum of the latest and greatest until cataclysmic failure occurs or a newer/shinier object is introduced, so hopefully that means we will not only see the introduction of more social learning tools, but also see higher adoption by employees. I’m going through the process now, so that’s why it was interesting to read what Deloitte’s John Hagel had to say about social software adoption.
… three models of adopting social software: (1) bottom-up through teams who use them, without permission, to support what they are doing (2) targeted deployment by an enthusiastic executive (3) massive deployment, which risks backlash. What is missing, he said, is metrics that matter and differ according to who is using them and for what. Senior executives are interested in financial measures, middle management in operating metrics and the front-line in performance metrics. – courtesy of http://www.thesmartworkcompany.com
Most organizations implement a combination of these ideas, but rarely to the strategies rely on the intersection of the three. I’ve seen the “if we build it, they will come” strategy fail, but understand that without formal communication and support, the number of people we reach within an organization is capped from the start. I’ve also seen passionate leaders try and fail to get buy in from both ends. Neither the business nor the user wants to give. Personally, I think successful adoption actually rests in the overlap between (1) and (2) with an established platform (3) for scalability and security. Hearing the collective voice of the employees in an organization and learning from their experiences is crucial for the adoption of a new tool/process, so the idea of merging executive support without restricting the users (letting employees know the idea is fully supported at the management level) is one worth exploring. Under the desk, makeshift solutions will never go away and even if the executive level adopts the solution, applying process and metrics to the nimble solution will kill its benefit.
Ultimately, providing the platform/support/architecture for employees to leverage social collaboration is a requirement, but tying the success of that system to metrics or limiting the evolution of the system shouldn’t be. These systems fill a void and improve effectiveness, whether it be in accuracy, time management, access to the right information at the right time, or else the employees wouldn’t have spent their own time building the solution. If a tool is used by ten or fifteen people, but saves hundreds of hours or improves the quality of a customer response, how can that be tracked?
The solution I’m currently trying to implement sits directly in the center of all three adoption models. My organization is hoping to build a complete skills inventory that can be leveraged to foster talent, retain our best people and also ensure the business won’t suffer during any labor struggles or emergency outages. I wholeheartedly believe this initiative is needed. Not knowing “what we know” or “don’t know” is a limitation that results in wasted training dollars, poor customer service, increased travel expenses (sending a known expert to a location to solve a problem) and potentially unnecessary hires. These are huge concerns, but for the employees in the trenches, they are second to being at a customer site or on the phone and not having access to the right answer.
An informal “talent” sharing system that allows employees to search team members through our collaboration platform and create loose ties and open informal communication channels seems like the perfect answer. It doesn’t matter if I know “Employee A” or that employee knows me. What matters is that I need help answering a question about one of our products and a positive customer experience relies on that potential informal communication. Sure, I can scan documents or web sites – and lets assume the taxonomy is monitored and accurate, which is probably isn’t – but who knows how many .docs/.pdfs/.html files are sitting in our document repository? If we provide the tools – in this case a micro-blogging client that provides access to an ever expanding network of experts and a real-time communication channel, perhaps a people search in SharePoint linked directly to Communicator (that shows status of who is and isn’t available) – the organic adoption of the solution should follow. This solution relies on the executive support – namely the platform support and availability – but depends on the employees that use it and how effective the solution actually is.
But how can you judge the success of the tool? The solution shouldn’t re measured as a success simply by the number of hits or searches, but by how essential those using it religiously feel it is. More importantly, what happens if the requirements change? The development model of the tools need be more flexible. Obviously, we can’t give the kids the keys to the house and let them throw a party, but knowing that these grass roots solutions are built out of necessity and usually improve the process for a business unit, the ability to evolve with business requirements is essential to the continued use of the tools. IT compliance is needed – we can’t have these tools running queries that shut the network down – but the rigors and financial constraints of new development will cripple the tool and once that grass roots user community loses faith in the tool, the tool is useless. Providing a stable, scalable architecture on an Enterprise wide platform requires executive buy-in, but the benefits of giving the users a sandbox to build and test new ideas will ultimately save money, save time and improve employee communication. Essentially everything social learning has been preaching for years.