“If I knew that, I wouldn’t have …”

The moment a company, manager, or leader hears these words their instinct is to create a policy or document or thing that clarifies the expectation. At least that’s the goal. What often happens is that they add tough language (“You will be terminated if you do X”) in an effort to make sure everyone knows what will happen.

I have so so many problems with this approach.

Is it really a problem?

So often these things are outliers — a person who is the exception not the rule. For some reason this is almost always the case with HR policies. ONE person takes advantage of sick days and then everyone suffers.

There will always be people who don’t read, do what they want, take advantage of things. People who basically suck. But they are the minority and we shouldn’t punish everyone for that.

Obviously, if this is an overarching issue or one you hear over and over again you should address though, which leads us to …

Inspire don’t punish

It’s been shown that motivation with fear, while successful in the short term, overarchingly leads to mistakes and decreased performance. People respond when they feel acknowledged and heard. This is how to get loyal employees, productive workers, and happy students even in intense environments.

Internal fear and competition is bad also — those who view their failures with self-compassion are actually more likely to take personal responsibility for their actions.

Don’t discriminate

Not everyone responds to fear in the same way — some relish in the competitiveness; others shrink. This is fine. But more than individual personality differences, there are social differences among gender and race (and more).

When a person is in a situation where they are the minority, the idea that they don’t belong exists from the get go. You are proving it and thus making them more likely to respond by just leaving.

Clarity isn’t tough

If you feel the need to add tough language to something, it’s likely that you either aren’t using the right words or are reacting negatively to the present situation. Take a moment (or a couple weeks) before writing it.

Support the Clarity with Action

But also, think about how you can support the clarity you want. Clarity doesn’t just come in a written document (who reads those anyway?), it comes from the behavior and culture of a team. What feedback loops are you missing?

If an engineer did something wrong, how did they get to the place where they could even make that decision? Could you add in a safety net 2 steps back?

If he deployed something he shouldn’t how could you have prevented that with action? Why did he deploy then? What was he deploying? Was there a code review? Was the build squirreled?