What To Do not How To Do

A fine line exists between business people and IT people. Business people should tell the techies what they need and how the process should be performed. Business people should NEVER tell the techies HOW to do their job.

I witnessed a business person state: “You heard what we want. We don’t need documentation. We need you to just start coding it.”

Would you want to live in a house that didn’t have clarification of understanding what you want? Do you want to live in a house that a builder builds just based on you verbally explaining what you want? With all the money spent, don’t you want checkpoints to make sure things are going as expected?

Everyone has filters. Everyone hears and stores information differently. Putting a few “documents” in place lets the two sides see if they are blinded by the “curse of knowledge” (a term described in the Made To Stick book by Chip & Dan Heath). Are you not saying something because you asssume it is generally understood? Did the techie stop listening or did he misunderstand something because of his previous knowledge.

Don’t take the chance. Insist that things be documented and review the documentation. Filters get clogged and the wrong information doesn’t always make it through. Architectural documentation is a stepping stone to ensure that what you say, is what you will get. It also gives you an opportunity to tweak.

The techies are right on this point. Let them document before coding. Read and approve it before anything is built. Otherwise, you’ll be living in a house of straw and a hurricane is on its way.