How would I create a technology standards document for my company?

Question

I'm a Director of Product Engineering for my company. My CEO has asked me to create a technology standards document, explaining things like the technology we use, our policy on adapting to new technology, and design standards like percent of code covered by unit tests. I've never had to do something like this, and I've spent a significant amount of time searching the web for examples, but I haven't found any at all. The closest I've found are documents describing technical specifications for an individual product. However, I'm trying to define this for the entire company. Can someone provide examples of how this document could be formatted/organized, and what the typical content would be? Thanks!

Answer 1

You should probably think about why you're being asked to write the document. Is it something intended to aid your engineering and product development process? Is it part of the due diligence package that potential investors will receive? Are you trying to achieve some sort of process certification like ISO9000? Is it simple mission-statement jargon-laden fluff that will serve no real purpose?

Off the top of my head you might want to talk about:

• using appropriate technology
• how selection and purchasing decisions will be made: on a defensible engineering basis?
• keeping abreast of accepted community best practice for the technologies we deploy
• identifying and using the best tools for the job in order to improve developer productivity
• your attitude to open-source solutions (maybe OK, provided they solve the problem and the legals are checked out; you may wish to include policies on the more common open-source licenses)
• your development processes. Do you use a formal methodology (waterfall/agile/scrum/extreme/TDD/...) or something more ad hoc? What about development workflow? (I mean bug tracking, control of source code commits, release procedures and so forth.)
• do you allow engineers time for professional development? (conferences, courses, side projects)? What about something like "20% time" as found in Google and other places?

Answer 2

You should just go ahead. That's typically the kind of internal docs you won't find on the net.

The best doc you write will come from yourself, by writing down the big picture stuff. The organization content of such a document are too specific to your company business and culture.

Answer 3

There are many ways to approach such a document. The exact content depends on what you want to accomplish.

Here's an example (link to page / direct link to PDF). It seems focused on listing existing, phased-out and upcoming technologies in the organization so that vendors know what they're going to work with. This exemplifies one approach.

Obviously, this particular document doesn't cover design standards like unit tests. Again, the content depends on your particular goals...