Technology Should Enable, Not Enforce

We spend a lot of time—an inordinate amount of time—talking with people about how to lock down permissions inside of knowledge management tools.  How to make sure Contributors can’t publish.  How to make sure Candidates can’t edit or approve.  How to make sure Readers can’t write.  It goes on and on.

Why?  Why this fixation about controlling permissions?

Just to be clear, if someone at work wants to do something bad, they can.  You give them all kinds of tools for mischief:

• A telephone they could use to yell at customers or make prank phone calls
• Web browsers with access to forums, where they could post proprietary and derogatory information.  (Not to mention the other inappropriate things that can happen inside web browsers.)
• Email clients, where they can send almost anything to anyone…including, by the way, the contents of a knowledge base article

But mostly, most of the time, most employees don’t abuse your trust.  And in the rare cases they do, you do what you have to do to deal with the situation.

So, for the record: don’t lock down your knowledgebase more than is required by regulation and statute.  Explain to people what they should and shouldn’t do, and trust that they’re not going to go looking for trouble by pressing “publish” buttons you don’t want them to push.  (It’s hard enough to get them to press the buttons you do want them to push, right?)

I don’t want you to think that our position is based in some kind of namby-pamby granola sense of corporate Kumbaya.  The costs of getting this wrong are as serious as a heart attack.

• Implementation costs.  As I said at the outset, we spend time on this because it’s in more-or-less 100% of the initial requirements for every knowledgebase implementation we’ve seen.  This drives implementation dollars, time, and risk.
• Maintenance costs.  Every time a Reader is hired, every time a Candidate is licensed, every time a publication process changes, the tool’s identity model needs to reflect each user’s rights and privileges appropriately.  Provisioning users becomes a big job. If you have one hundred or two hundred users, this is a serious pain.  If you have one thousand or two thousand users, or more, this represents a huge barrier to scalability, especially globally and across business units.
• Usability costs.  Inevitably, the ways that lockdowns get implemented in a tool involve extra clicks whether you have permissions or not.  Each click represents a serious barrier to adoption.  Don’t believe me?  Ask your support engineers.
• Trust costs.  If you treat me like someone who shouldn’t be trusted, well, then, I’ll probably act that way.  As Barry Schwartz passionately argues,  rules and bureaucracy result in a lack of communal wisdom.  Stephen M.R. Covey points out that lack of trust slows us down.  None of this is what we need in our knowledge program.

Given how hard KM efforts are, why make things any harder on ourselves…especially if we’re fighting a losing battle?  Look, unless your name is Kim and you live in a palace in the northern part of the Korean peninsula, you simply can’t control what your people share.  Give up your illusion of control, make sure the right thing to do is clear and easy, and deal with the unfortunate exceptions only when needed…and they mostly won’t be.

Turkey’s Twitter users found a way around their government’s temporary technology controls (which relied on hacked DNS entries).  You just don’t need to go there with your knowledgebase users.