If your theory is "build it and they will come", you have to make sure there is a "they"

Date:September 6, 2007 / year-entry #332
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)
  1. Jules says:

    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.

  2. Bob Plankers says:

    Just define ‘it’ as ‘actual content’ and you’re set. :-)

  3. Peter Schoenster says:

    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.

    [That’s my point. You have a “they” (people who had something to say). If there is no “they”, then building a system for “them” won’t accomplish anything. -Raymond]
  4. Tom says:

    Touche.  (In regards to my comment about yesterday’s post).

  5. Puckdropper says:

    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.)

  6. Nathan says:

    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.

  7. Chris Moorhouse says:

    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.

  8. Cathy says:

    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.

  9. Mikkin says:

    Thanks Raymond. My CTO needs to read this so much that I will have to forward it anonymously.

  10. +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?" :-)

  11. BryanK says:

    [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.  :-)

  12. Bob1 says:

    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.

  13. Michiel says:

    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.

  14. Cooney says:

    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.

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index