As promised, here is the post that support the workshops that I ran today at the E2EF event. Many thanks to Ross Dawson for inviting me and everyone who participated. The topic was policies and guidelines. There are four questions that need to asked here:
- Why do we need social software policies in the first place?
- How should we develop those policies?
- What should be in them?
- What next? This question deals with deployment and monitoring.
Why do we need policies?
Things go wrong and people do things they regret. Public mistakes with social software tend to be splashed across the newspapers. Mistakes inside organisations are more easily covered up but they can still result in lasting damage. Things that can go wrong include:
- Individuals fighting destructively in public. There should be nothing wrong with constructive debate but arguments and abuse can alienate people and ruin relationships.
- Individuals inappropriately releasing confidential information.
- Incorrect information being shared and acted upon.
Rarely are these acts carried out maliciously. Mostly it’s due ignorance and thoughtlessness. Policies should remind staff of the behaviour that you expect of them.
Policies also play another role – which is placating managers worried about social software deployments. The things that can go wrong listed above are often voiced as common fears by managers. Enterprise 2.0 is all about changing the balance of control and initiative in an organisation and this can scare people. Good policies reduce that anxiety.
How do we develop these policies?
How you develop your policies is as important as the policies themselves:
- Many hands make light work. You have hired smart employees. Enterprise 2.0 is all about collaboration. So why don’t you get your employees to help draft what these policies should be. IBM used a wiki to allow its bloggers to draft their own guidelines (which you can view here). Senior management can reserve the right to make changes of their own – either while everyone else is drafting or at the end. Of course this means that if you’ve involved people up front, you should think twice about throwing out everything they’ve done.
- Use what you already have. You should already have policies around internal comms, privacy & confidentiality, IP usage, etc. So use ’em as the foundation for your social software policies. There should be no inconsistencies between these – otherwise people could get into trouble while trying to do the right thing.
- Use the tools. Wikis are very good tools for collaborative policy drafting.
What should be in them?
This may be the easiest bit. There are three areas that you will probably cover:
- Be sensible. If the wiki says “work in progress” do not assume that the information in there has been vetted. Use your judgement in what to post about.
- Be nice. Don’t abuse people. Use your own identity. Be constructive.
- Be legal. Don’t breach copyright. Don’t break confidentiality.
Have a look above at the IBM example or the ones for Intel & Powerhouse Museum. Most examples are about public use of social software but theycan be applied to internal situations. Beth Kanter has some sensible comments as does Joitske.
What next?
You now have your policy. If you have involved your staff earlier then this will make deployment much easier – because they will already be engaged. There are other things you may consider doing:
- Use specific examples in explaining the policy to people.We like the concrete above the abstract. “Andy posted dirty jokes in the comments field of Stacy’s blog. They are good friends so Stacy didn’t mind. So why might this have been a bad idea?”
- Focus on discussing borderline cases. Employees will generally know that selling confidential information to a competitor is bad but may need some help establishing where the boundaries are.
- Include a section on appropriate behaviours as part of any technology roll-out. If there is no formal training to be provided then at least flag the policy when staff first access the tool.
- Incorporating a session on the policy in training for new hires.
You’ll need to review your policies over time so build in timeframes for doing this (e.g. after a month, after 3 months, then every year). We give software releases numbers so why not policies?
An important idea that emerged out of today’s discussions was the importance of giving positive examples (& role models) not just negative ones. You don’t want to snuff out the inspiration.
That’s what I think. What do you reckon?
Innotecture 