Standards: Grow Them, Don’t Make Them

Every time I’m in the United States I waste time on physical and mental conversions of standards. I convert all transactions from dollars to euro’s, and vice versa. I convert miles to kilometers, gallons to liters, and am/pm to 24 hours. And by now I have at least four adapter plugs to convert from European electrical sockets to US sockets, because I sometimes forget to pack them, despite the fact that they are listed on my traveling checklist.

Despite the hassle that travelers worldwide have to put up with, I don’t think it is a good idea to ask the United Nations to enforce global standards for sockets, currencies, and measurement systems. Different parts in a complex system will always try to optimize for themselves, and therefore local systems will switch to global standards when it is optimal for them to do so. This is exactly what happened in Europe: 16 European countries voluntarily switched to a new pan-European currency because they figured that the opportunities and long-term cost savings were higher than the one‑time switching costs. Some other European countries have not (yet) taken this step because their perceived costs (financial, political, and cultural) are apparently still higher than the benefits.

Standardization is usually not something that needs to be enforced. No worldwide government was necessary to make billions of people around the world to standardize on the 24-hour clock, the Gregorian calendar, the English language, or Right-hand traffic. True, there are plenty of deviations from the international standards. Positive feedback loops will only lead to adoption of standards when it pays to do so.

After choosing our activities, we begin to perform them. As we do so, the next event in self-management comes into play – monitoring our performance for competence. This event, then, involves making sure that our work activities meet our standards. During the compliance era, work standards were external and set by managers at fixed levels. Workers were charged with doing work that met these levels – doing “good enough” or “satisfactory” work. In contrast, self-management involves committed workers meeting their own internal standards of competence. Internal standards are more dynamic: people raise their standards on tasks they care about as they become more skilled and experienced at the task activities.
Intrinsic Motivation at Work (Kenneth Thomas)

In software development, competence leaders work with people to discuss their own internal standards, not management-imposed standards. Like naming conventions, coding standards, user interaction conventions, file structures, configuration management practices, tools, error log standards, and security standards. There is no need for management to make top-down standardization happen. Bottom-up standardization will happen when goals and metrics make it painfully clear for employees that it is more optimal for them to change.

(figure by Biking Nikon PDX)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

Twitter TwitterRss SubscribeEmail NewsletterLinkedIn LinkedInSlideShare SlideShare

Latest, greatest and favoritest posts:
When You Are Rejected
Yes, Good Managers Are Manipulators
Agile is NOT a Risk Management Strategy
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • http://islandofagile.blogspot.com/ Pete Schneider

    You say that goals and metrics will make it clear to the employees that their lives will be better if they adopt standards.
    I’ve seen this happen with my current team. When we formally adopted common code ownership the team realized quickly that it was a lot easier to work on someone else’s code if everyone stuck to a set of mutual conventions.
    My question is what goals and metrics do you use to make this visible?

How to Change the World - free Workout - free
CLOSE