When to Standardize?

This may seem obvious, but in my career, seems often overlooked. A simple principle is to only standardize a process when it helps with motivation and making good decisions more than it hurts our ability in those areas.

For example, when we have compliance issues, it is helpful to standardize a process because we are not all compliance experts. Further, it helps improve our motivation, because we don’t want to have to think about compliance all the time, nor fuck up == improved motivation through perceived competence and opportunity for mastery of what we do care about.

Standardization hurts autonomy and relatedness always. And, it hurts mastery if it is something we want to be good at; it hurts our sense of purpose if it’s something we see as part of our mission.

Standardization hurts good decisions, when the people who are closest to the decisions (with the most information) aren’t the ones making the decision. And, if the people closest to the decision can’t adapt and improve (or perceive they can’t) upon prior decisions, we hurt long term advantages of iterating.

In general, my advice is standardize only when that decision comes from the bottom up — e.g. “This compliance is hard stuff; hey boss, can we look to get expert help and standardize this across the teams?”. Hire specialists when needed (this is how all roles should be created). So, instead of spending your energy high level projects and standardization from the top-down, spend your energy improving on leadership, trust, and empowerment.

Important note: I found this old note. I love it and I don’t remember writing it. It looks like my writing style. I did a google search and couldn’t find anything similar that I might’ve read. But PLEASE let me know if I should be attributing this thinking to others — definitely some Deci & Ryan and David Marquet background info that went into it.