If you accept the proposition that email is broken, (and if you don’t I would be interested to hear how it is working for you) then I thought that it might be worth exploring a few options for working around the problem.
The first thing to acknowledge is that, as much as we would like to be able to, we won’t beat the spammers. Greed and ingenuity on the one hand, and gullibility on the other, means that the problem — in one form or another — is here to stay. So what can we do?
The simplest answer is to move as much of our comms as possible into other channels. How can we do this? I don’t have all the answers, but here are some of the things that I think that we could be doing now that would have an immediate impact on the way we work across the public sector.
Instant Messaging
I am amazed (and quietly appalled) that this hasn’t taken off, at least as an inter-agency tool. The amount of cruft that could be removed from the email channel by IM would be staggering. It allows you to see if the person you want to communicate is available, exchange a quick message (if they are so inclined) and you are done. If you need a corporate record, you can always save the chat to your hardrive.
Wikis
These have the potential to revolutionize the public sector. I am confident that the widespread use of wikis across government would be one of the single biggest factors contributing to the transformation of New Zealand’s State Services. Both as an internal communications tool, and as means of opening up government to more interaction with the public.
First, as an internal comms tool, just think of the number of times a day you are sent email with documents attached for your comment/QA. If all of this traffic was removed from email and hosted on wikis, we would all be more productive, there would be a better corporate record of our work and we would be better able to manage multiple comment streams on each paper.
I know that the shared workspaces are supposed to fullfil this role, but my experience of them has been underwhelming, to say the least. A basic understanding of usability will tell you that this is a case of a poorly designed product, not at all intuitive or usable. Unlike a wiki which — and this is clearly a risk — any idiot can use…
Similarly, the process of consultation with the public would be greatly improved — for those projects where this was an appropriate technology choice. See caveat above about risks here.
Blogs
I have noted before that I think blogs are ripe for internal communications in and across the public sector. This would be another terrific tool for moving traffic out of the email channel and into a space that supports more interaction and a richer level of conversation. All easily searchable and discoverable.
RSS
To really make all of this sing, every Internet enabled desktop should have an RSS aggregator. Blogs and wikis both provide easy RSS feeds, meaning you could subscribe to the blogged/wikied projects or threads that interested you and follow the feeds from your reader, instead of repeatedly checking their status in your browser. Simple, really. And cheap.
and, finally…
The final point (that I probably don’t need to make) is that, in eight cases out of ten, it is just as easy to pick up the phone or, even better, climb the stairs and have a chat with the person you were just about to email. Nothing works like, as some management gurus describe it, face time.
5 Comments
IM - Except that I can easily fake an IM exchange record. Email needs to go through a server(s) and is recorded on each. IM records are much more ephemeral at the server level. That said, I could also fake handwritten meeting notes if I was that kind of person…
Wiki = shared workspace. As you note, don’t confuse a particular product for the generic service of which it is a subset. You can structure wikis in a number of ways, with security, user privileges, locked areas etc. all you want. It doesn’t have to be wide open as a default. It’s really about management more than it’s about a tool. To work cooperatively requires buy-in to the concept of working together. We seem notoriously wedded to the concept of working individually and putting stuff out for review, which is not the same thing.
Blogs - so-o-o-o-o 2005
Could be useful but, again, it’s a matter of mindset and easing up of restictions. They could be hella useful internally though. Go on, prototype!
RSS - can be useful, but can also be the biggest timewaster.
The thing about all these tools is that they are, by default, unstructured. Corporate bodies of a certain size or responsibility NEED structure to function. They don’t necessarily need hierarchy the way the public sector has it, but that’s a result of poor management, imho.
and, finally…
all this from a man who used to IM me when we sat 10 feet from and facing each other! It is to smile ruefully…
Thanks Mark,
I think the points you raise are good ones (for the most part). The tools don’t have to be unstructured, they just allow for different kinds of structures, including ones we are not that confident with yet.
But, hey, anything to improve communications…
i’ve been thinking about wikis for here at DoL as well, but wonder if systematising them will only serve to deflate their function.
what i mean by that is ‘gatekeeping’ of information within organisations.
we also floated the idea at the IRD, on account of their highly complex information structure, but were deflated by the presence of the Knowledge Base (a page-based intraweb containing much of the current versions of practice, procedures, rules, etc), and the amount of knowledge floating around in the heads of subject-matter experts.
you could get the wiki going, but you’d have to move the Knowledge Base people into manage competeing interpretations of contemporary information, and resource constraint meant this was unlikely to happen. so, what you would end up with is a user-defined system that is actually defined by gatekeeping-tasked non-users!
so, while the system might work here at DoL, because it is a vastly smaller organisation, the gatekeeping issue is likely to remain, IMHO.
i should really ask someone about the idea tho.
Thanks Che,
I think the key is not to try and replace the existing systems (eg, the Knowledge Base) but to implement solutions that allow different stuctures - so that the wiki is managed by the users, not the gatekeepers. What you could then do, over time, is migrate wiki pages into the KB, once they have reached a level of stability, for example.
Wikis won’t solve every problem. They will alow you to deploy a lightweight, usable solution for a range of different situations, many of which are currently poorly managed via email or workspaces. And because they are lightweight & cheap, you can afford to install them at the project level and see how they work for an agency…
PS. Spam’s not so bad if you fry it lightly and eat it with eggs.