Monday, June 16, 2008

Enterprise 2.0-- working in the open

A week doesn't go by where I don't hear from some administrative group who wants to work in a wiki, but wants their work to be private. When this happens I almost always tell them, "Then a wiki isn't for you. If you want to collaborate with a small group where no one else can see it use Google Docs." When I say this they almost always respond, "We dont mind people seeing it, but we don't want them to see it until it is more polished." Of course, that defeats the whole purpose of a wiki where the values that are "baked-in" declare that everyone, no matter what their role, has something of value to contribute. If you mess with the values you break the very conditions which allow the tools to work in the first place. I personally don't believe you can be a little 2.0. I think it's more binary.-- you are or you aren't. Which is why I think most enterprise 2.0 efforts will fail. You have to believe.

I am a huge believer in workstreaming technologies for this exact reason. I've talked to several groups struggling with distributed work teams in the last few weeks, and in every instance the missing ingredients were the workstreaming capabilities, and because it's all blurring, the associated lifestreaming technologies.

Which brings me to this Coding Horror post: Don't Go Dark. I'm thinking there is much that old-school management can apply to their jobs that has been learned from the agile software development world:

Don't go dark. Don't be that guy in the room. Hiding your code until it's "done" may feel safer, but it isn't. Sharing your ongoing code with your coworkers is scary, much less the world -- but it also results in feedback and communication that will improve your code and draw you closer to the project you're working on. And isn't that why we all write code in the first place?

That advice doesn't just apply to writing code it applies to everything that we do. It's why wikis work. It's why I tell people who want to work in the dark in a wiki that they should use something different. If you aren't ready to work differently don't think for a minute that the enabling technologies will work for you.

As they say, transparency is the new black. Step one in moving to agile management is to stop being a scaredy cat and to start working in the open.


SusanSD said...

Here, here my good man. I agree, but there are times you'll need to work collaboratively on a wiki, but in private too. For instance, a group of us were working on an acquisition, and we needed to limit the collaboration to a "need to know" subset of our community. Wikis are great for private/public collaboration.

Kevin Gamble said...

I agree that there are a few unique circumstances that require you to not work in the open. I think there are fewer of these circumstances than more. My fear is that once the ability to hide is built-in-- that it will soon become the default.

I think you're better off leaving the wiki alone-- leaving it pristine--and selecting a completely different tool when the circumstances warrant it.

This is mostly coming from my own experiences over the last three years. I know that it may be different in different organizational cultures. Not one size fits all...

I do so appreciate your comment!


Jenny Mackness said...

Hi Kevin - I have come here via a tweet by Harold Jarche. I am interested in your post because I have a different experience of wikis. I use wikis (pbWorks mostly, but also Wikispaces) extensively for research and project work. I have never really thought of them in terms of public/private, but more in terms of a place to gather resources and discuss them. I blogged about how I use them here - . Some of my wikis are 'open', but most are by invitation only, and the ones that I value the most are the ones that are 'closed' and that I use for research purposes (working with just one or two people), which are only open to the research team. And for me Google docs and wikis don't compare. They have different purposes, but personally for discussion and editing of writing, I prefer wikis. I think I work in a different context to you, so that may be why I see how wikis can be used differently. Context is key, as they say :-)

Kevin Gamble said...

Jenny, what you are describing is not a Wiki by definition. You are describing using a wiki as a Content Management System. it certainly can be used that way, just as an automobile could be used to pull tree stumps-- not necessarily its intended purpose.

"While a wiki is a type of content management system, it differs from a blog or most other such systems in that the content is created without any defined owner or leader, and wikis have little implicit structure, allowing structure to emerge according to the needs of the users."