Happy Friday,

I'm sure you've seen this—a standards document covered in layers of dust with groups operating to the cry of, "No, this is an exception!" I know I have. More often than not, I see any attempt at standards turn into a case where following them is exceptional.

Does that mean that standards are futile? No! You probably need to adjust how you create and introduce them.

Before we get into that, though, let me talk about the two biggest mistakes I see when introducing standards:

• Standards that don't reflect reality
• Standards that are forced onto people

If I got paid by how many times I see a group's standards that don't reflect reality, I'd retire wealthy. We'll get into using standards to prompt a group's evolution in a minute, but when creating standards, the further they are from reality, the less useful they are. So when creating them, even if you don't like what you see, they must begin with what actually happens and not with what you wish happened.

As for forcing standards on people, this is a delicate one. Most organizations benefit from a baseline set of standards, but if you demand compliance, you should expect a malicious variety of compliance. The fact is that forcing anyone to do anything will prompt resistance, even if they would have agreed with it otherwise.

If you have problems with folks not following standards, I'll bet it's a combination of these two issues.

Let's talk instead about how to create standards folks follow, and we'll start by addressing the two major issues.

When creating standards, it is critically important that you study what people actually do. These are the standards people follow, and they are where you must start. It can be a tough pill to swallow when you find out folks don't get specific approvals, bypass quality gates, or treat everything as an emergency to skip steps. Still, if you refuse to acknowledge this, folks will refuse to acknowledge your standards.

Next, I recommend that when you write standards, and you hear the voice in your head say, "Oh, they'll know what this means," you respond with, "No, they won't." Your standards need to be clear and complete, especially in the beginning. I've seen way too many standards that have something like, "Write tests when applicable," and you find out everyone thinks it's never applicable and that they wrote the tests, but nobody said they should run or pass. I know it feels obnoxious, but details matter in the beginning. These early standards need to remove questions, not invite more.

So, we have a set of standards that are clear, complete, and reflect reality. Now, we need to introduce them to the groups. The way you do this is by having a meeting with the groups, introducing the standards and their intent, and inviting them to provide feedback. You'll uncover a lot of things that you didn't account for, and each team will have unique circumstances, problems, deficiencies, and exceptional qualities. Your standards will be an imperfect fit. So, you invite the group to adjust those standards. The goal with the adjustment is to tailor what is there to be more appropriate to the team, not remove things. An example could be that your initial standards expect automated tests but this team does data work, and automated tests don't apply, so their equivalent might be verifying data scripts in a test environment.

Next, you ask them what would evolve some of these standards in a way to make the team operate better. Again, the result needs to be clear and complete. I'll also suggest that less is more here. Just tweak a few things in a way that would cause a little stretch. Don't try to go for the dream scenario, it will fail and demoralize everyone.

Last, you review the standards and ask if the group feels they can accept and follow them. This step will help flush out any lingering concerns that didn't come up. Also, if they accept these standards, they can also accept responsibility for them, which is what you ultimately need. The group needs to believe in them and keep them alive.

So there you go, a little primer on creating standards that teams will follow instead of ignoring and subverting.

Sincerely,

Ryan