Do not make rules that you cannot control or enforce

I have been repeating this sentence more often than I’d like recently. But if the COID-19 time has taught me one thing very impressively, it is:

Rule 1: Forget rules which you cannot control or enforce
(Alternatively: “Do not hope for the sanity of your colleagues / fellows / …”)

Many of the COVID measures would certainly not have been necessary if “we all” had behaved reasonably. One could discuss the term “reasonable” right away. But “reasonable” unfortunately depends on personal goals. If the personal goals diverge, the opinion about “reasonable behavior” diverges as well. And suddenly “we all” do not have a common sense of what “reasonable behaviour” is. This discrepancy is then what is called a “conflict.”

So, if you are responsible for a system (the system does not even have to be technical – the “health care system” e.g.), you can hope for the sanity of the involved participants (users) and not impose any constraints / rules … This will most likely lead to a conflict. If the conflict has to be solved, you will generally be confronted with utmost gratitude and boundless cooperation (this was ironic, by the way).

No problem: just set up some rules … But rules only do make sense if you can control and enforce compliance with the rules. Because … honestly whenever we discover an inconvenient rule, we want to circumvent it. And we are creative 🙂

Rule 2: Only make rules whose compliance you can enforce and control.

If you find yourself in a position where you can detect a violation of a rule but cannot (anymore) react (or only with enormous effort). You are on lost ground and can do nothing but watch.

Rule 3: It should be clear to everyone how the enforcement will be done.
Rule 2.5: This is transparency.

The 3 rules sound trivial … but can also be very unpleasant if you have to write them down and communicate them. On the other side, you will have certain displeasure right away, but not later (or at least less because the rules were clear from the beginning). A user, on the other hand knows what (s)he is (not) allowed to do. And if there is the transparency about the consequences, the user can also decide for him-/herself whether to break a rule or not – but one cannot complain.

Don’t just ask for Feedback and Improvements

“Every employee should feel encouraged to give feedback and contribute ideas for improvement!” Who has heard this before? Probably everyone!

My (slightly provocative) opinion: “The effect was probably close to zero. So Forget it and don’t do such a shout out!”. Unless you want nothing or barely anything to change. Then do a big shout-out and send people back to work! Great show – with no effect! Of course, I made the mistake myself and didn’t notice for quite a while (years, actually). Every now and then an idea or suggestion came along (or I had one myself) and we were proud of the improvement. At some point between Retros and PostMortems I got the point: “It needs the right framework!”

Why are there retros for projects / sprints / teams / …? Why are there PostMortems? What’s the justification to do them? Not because of the “new fancy agile stuff” where you “just do it that way”, but because it pays off – it works. Because it provides a framework for discussion. Because time is explicitly reserved for the questions: “What can we do better?”, “Why did […] happen?”, “How can we prevent […] from happening again?”

And within this “frame” – that reserved time – people really find the time and opportunity to express ideas. Or just explain some tedious tasks that should be improved because they are … tedious. In this reserved time, there might come more ideas than in the days and weeks before. Than in the time where people are permanently confronted with the problems – where one actually could already come to the conclusion that there is potential for improvement. And maybe also more complex ideas, which people just can’t “simply do” besides regular work. Complex ideas which need a little time to be explained, discussed and understood.

If you want something to run better, the call for improvement is a step. But only one step. So the next step is: Okay, get all people together that are concerned and willing to contribute. Let’s have a look at the bugs/whatever… of the last weeks. Where are do issues pile up? Where do we ALWAYS do the same thing over and over again (“Toil” in SRE Speak)? What’s annoying? Do we have data with which to raise an assumption to a fact (that makes prioritization ways easier)?

And then the essential points: Derive actions, evaluate and implement! And do it on time! Otherwise, any motivation is not only gone, but it is immediately learned that nothing happens anyway.

All this is time-consuming, tedious, inconvenient and also annoying when you have to prioritize the actions against other tasks … But … it brings value. – So if you want to improv: Don’t just ask for feedback.