Information Hoarders

I make no secret of my love for Seth Godin and his amazing insight into the world. Besides being a marketing genius, he’s like Ockham’s Razor in getting to the essence of a problem. Take today’s posting, which really resonated with me, because it seems to reflect my own frustration with a common problem in IT.

If your project or organization depends on knowing things that other people don’t know (but could find out if they wanted to), your days are probably numbered. Ask a travel agent.

So all you “so called” engineers and developers who hide and hold critical information about the infrastructure as tightly as Scrooge McDuck hoards his gold, be warned. Hiding information doesn’t make you irreplaceable, it only makes you disliked and unpopular.



  1. Christopher Hayre says

    Equally frustrating are the Information Avoiders—those with little appetite or concern for learning new things.

  2. Derick Winkworth says

    Sometimes it’s not about information hiding. Sometimes infrastructure is complicated and trying to explain it in one sentence sound-bites doesn’t work. Nevertheless, those that expect everything be explained in two seconds get frustrated and accuse you of information hiding.

    • says

      But in two seconds one should be able to direct the requester to a big stack of network diagrams and documentation. Otherwise, what happens when you get sick, take vacation, have a kid, etc?

      • Derick Winkworth says

        These should be on a shared drive somewhere. Even so, in a complex environment, it’s not always obvious *why* things are the way they are, and it’s usually not true that everything is documented perfectly. This is not information hiding, and could very well be the result of not having enough time.

        • says

          The “why” is very much the kind of thing, along with the “what” which should be documented. I worked at $gigantic_ISP when I was a young engineer, and I ran across a document by Jason S, called “routing principles of AS ###”, which explained why things were the way they were. I learned from that document not only how to write such a document (it was well written) but that such a document needed to be written.

          Documentation need not be perfect, but it should exist, and it should be continuously be improved. Also, the people working on the system should be willing to answer questions about it, even if they seem stupid or trivial- because sometimes they really *are* good questions, other times it’s essential for training, and the rest of the time it’s good practice for the other two.

          • Derick Winkworth says

            There’s a lot of “shoulds” in there. In a perfect world where people aren’t worked to death in ever-shrinking shops all of this would happen.

          • ijdod says

            Also, let us not forget that even if something *is* documented, this doesn’t always mean you can find it when you need it. I have yet to see a documentation set which allows a skilled outsider to find all the required information. Best I’ve seen is a very strict approach, where once you know the system, you can find most things.

          • Christopher Hayre says

            What about using something like a Wiki or some other sort of documentation repository to help make the information more accessible? I’d argue it’d help the “can’t find when needed” issue.

        • Christopher Hayre says

          +1 to this. Some places also have systemic documentation issues. Ex. Culture of low-to-no doc.

          Disagree in re the shared drive though. Something more flexible and extensible should be used.

  3. Fernando Montenegro says

    True, but let’s not forget about the opportunity cost of acquiring such information and the different friction aspects of doing so. Travel is a good example: sure, there are cheap tickets around, but do you want to a) spend the time looking for them and/or b) subject yourself to any restrictions associated with them?

    I think Godin addresses this with “provide enough non-commodity service and customization that it doesn’t matter if the ideas spread. ”

    Bringing this to our world, the guidance should be: understand that your value is delivering infrastructure/functionality, not merely information. Act accordingly.

Leave a Reply

Your email address will not be published. Required fields are marked *