Standards in software development

I was reading a piece by Jurgen Appelo in which he argues that in a standards (things like naming conventions, file structures, error log standards, etc.) will emerge from the bottom up " goals and metrics make it painfully clear for employees that it is more optimal for them to change."

I'm intrigued by this. I run a small (6 person) development team that worked out it's own coding standards a couple of years ago. I believe that the primary driver was switching to common code ownership. It's a lot easier to maintain and extend someone else's code if you are sticking to a set of mutual conventions.

Currently there are two separate efforts (that I know of) to develop coding standards at my workplace. The test engineering team, which writes test tools and automation in python, is working on coding guidelines for use in writing automated tests. As far as I can tell this is coming primarily from the individual contributors with some nudges from management. The development organization, which writes the product code in C and C++ (and a smattering of other langauges for bits and pieces) is trying to integrate their various coding standards into a single document. It's a non-trivial task, there are over 100 coders in 6 offices, spread across 3 continents, working on 7 different products. This effort seems to be driven from the top down.

It will be interesting to see how the two efforts progress.

After reading Jurgen's post, I was left with one question. What kinds of goals and metrics can you put into place to make it more likely that team members will see that standarization will make their work easier?