Date: | September 6, 2007 / year-entry #332 |
Tags: | non-computer |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070906-00/?p=25243 |
Comments: | 14 |
Summary: | Creating an infrastructure for managing the content you wish you had doesn't actually create that content. Another possible response to the crisis management issue I considered yesterday is to say "Okay, we need to have an official Company X Breaking News site so that people who are looking for an official response to some hot topic... |
Creating an infrastructure for managing the content you wish you had doesn't actually create that content. Another possible response to the crisis management issue I considered yesterday is to say "Okay, we need to have an official Company X Breaking News site so that people who are looking for an official response to some hot topic can find it." Except that if you look at the original problem, it wouldn't have helped. The problem wasn't that there was a response to the hot topic that nobody could find. There was no response at all because the people who would formulate that response were busy working on the problem. Having a "Company X Breaking News" site wouldn't have helped because there was no content to put in it in the first place! Generate the content first, and then worry about how to present it. And I think that once the content shows up—wherever it shows up—people will find it even without needing a "Company X Breaking News" site. Some blogger will find it, and if it really is a hot topic, then the link will spread. (And if it's not a hot topic, then the link will languish since nobody cares about it.) This is something I see a lot of: thinking that you can solve the "We need good content!" problem by creating some infrastructure to manage that content you want to have. This isn't a "Build it and they will come" thing, because there is no they. The way to solve the "We need good content!" problem is "Produce good content!" |
Comments (14)
Comments are closed. |
Speaking as a part-owner of a company that specialises in web content management software, I can only say one thing: if only our customers would realise this, instead of expecting us to fix all of their problems, life would be so much easier.
Just define ‘it’ as ‘actual content’ and you’re set. :-)
I must disagree to some extent. Back in the day I’d fire up vi to edit a page on my server. Of course I really never had much to say. But I had a server and could use vi.
But look what happened when blog software appeared? Suddenly people who did have something to say had an easy way to say it.
Touche. (In regards to my comment about yesterday’s post).
Excellent point. Good content in a reasonably accessable way will get you lots of readers. (Some big company has content that’s not easily accessible–and it’s a selling point for their service.)
I’ve heard some managers or the like say that "all we need to do is create a wiki, and all our in-house tools will be documented." Same principle, I suspect. Good content won’t magically happen, even if barriers to creating it lessen.
Good points, and good pair of posts. If only more managers from all lines of business paid attention to such advice.
I would like to point out, however, that in the example situation described there is a deficient process and unpublished content. The trick lies in identifying existing processes and infrastructure that would serve the purpose.
It’s easy to scoff at the buzzwords, but it’s not like "processes" and "infrastructure" are inherantly useless. These words have attained the status they have by meaning something useful.
Good one, Nathan!
Creating an in-house wiki doesn’t cause documentation to happen unless somebody actually has time (or has been ordered to magically find time) to write documentation.
I’d imagine that, when faced with getting Project X done or having the engineers tied up trying to document Project X (or explain Project X well enough so it can be documented by somebody else), most managers will favor finishing the project and forget about documentation until somebody raises a fuss.
Thanks Raymond. My CTO needs to read this so much that I will have to forward it anonymously.
+1 to Nathan.
Just a couple of days ago I found a technical documentation page on a corporate wiki which said, in its entirety, "I don’t really understand this. Maybe somebody else could edit this page and add some useful information?" :-)
[You have a "they" (people who had something to say).]
Ah, now the title makes more sense. I was thinking you meant that "they" were the people that would read the content that got put into whatever process. You meant the people that would create the content.
It makes sense the way you put it (where "they" is the people that create the content); it’s just not what I expected when I heard the saying. But I get it now. :-)
Seems to me this is too often a chicken or egg thing. Rush to build a site to display content that isn’t available anyway or rush to hack together a site to display content that’s been ready and waiting with no means of sharing it.
There is one good reason to build (as a company) a site for your users to exchange content. That sign is that your users are trying to do so themselves.
If they’re good developers, skip the first steps of your own internal plans and just hire those guys outright. If not, but they still manage to build a community, at least buy their community and give them some official status.
As far as the build a tool thing goes, you can always make a display widget that shows whether any high priority bugs are open on the operational bug DB (assuming you have one). I favor automatic solutions like this one – low maintenance and allows people to see when something is busted.