OddPen

Nowadays, for good or for worse, if you google something you end up on Reddit. Wait, wait, stay here. I do not want to talk about how this is bad. I want to discuss a phenomenon you can observe there. Or more precisely: on every platform, people ask for help! (I think it's even one of the issues that people find so annoying about starting out on Stackoverflow.)

Answerers are often either in the state of unconscious competence, thus be able to reflect and adapt a given standard solution, or were coached by such folk, and just proxy a bias.

Unconscious competence: The individual has had so much practice with a skill that it has become “second nature” and can be performed easily. As a result, the skill can be performed while executing another task. The individual may be able to teach it to others, depending upon how and when it was learned. — Four Stages of Competence

What does that mean? Let's start with an example. Lately, I came across a thread where people discussed Pair Programming. And, as expected, it was super controversial. I immediately thought it's an excellent example of what I want to talk about here. You could observe two groups that did not recommend it. The first one suggested a solution that was better (in their anecdotal experience). The second one said they tried it, and didn't like it. This group, more often than not, described a process that was, in fact, not Pair Programming. Another collective that we can throw into the pit here, is people suffering from “Not Invented Here Syndrome” in companies. It basically describes a bias against ideas from outside. We unconsciously are more critical with things we did not create in our “tribe.” I'm sure you have heard variations of “this will not work here”, haven't you? 🙂

[Not Invented Here Syndrome is] the tendency of a project group of stable composition to believe it possesses a monopoly of knowledge of its field, which leads it to reject new ideas from outsiders to the likely detriment of its performance. — Learnosity

All these groups have one thing in common: they refuse or are incapable of consulting for or adopting the textbook approach. By that, I mean the concept as given, as it is fully defined. And that can be an issue. The problems with that reach from a harder onboarding process, to lack of knowledge depth, and everything in between. One of the most obvious ones is a communication problem. It already manifests at the earliest point during hiring. Either you explain what your special process looks like, or you will deliberately run into a misunderstanding. And that issue exists throughout the whole journey. Coining a term differently for your domain, let's say your team, is a misalignment waiting to happen. Now, that does not mean you can't adapt a given standard to fit your scenario perfectly. No, absolutely not. However, please be very diligent with it and create small feedback loops. Start to adapt only, when you are in a state of unconscious competence. Only then you have the profound knowledge it takes to communicate why your approach is different. A good example of this is Scrum. Contrary to popular belief, it is black and white. You either do Scrum, or you don't. There is no in between. Still, it gives you the freedom to adapt, once you know what you are doing. However, it is not Scrum anymore. It is something that you have to give a name. And to be able to do that, you have to understand the textbook approach first. You need to be able to tell the differences, why they were introduced, and how you measure whether they have the desired effects.

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices. — The Scrum Guide

If you make changes, it's in my opinion, crucial to measure data. What did you want to achieve by introducing that concept? Does the adaption aid that better? Because there is one major pitfall I observe quite often: The adaptions actually benefit a different goal than what we have introduced the general idea for. And, sorry for being the killjoy here, often it's to sacrifice actual goal score for engineers' comfort. If you do not start from how it is supposed to be, you never really tried it. You never put it into practice. Hence, you also cannot understand it fully. Starting with an adapted version shields you from making valuable experiences, that are necessary, to understand why an adaption might make sense. Now, what can you do about that? It depends a bit on your context. Usually, you find yourself in one of the groups as described at the beginning. We have a group being experienced enough to adapt, we have a group that just echoes what they have been told (often to appear competent), and one that simply think their work environment is too special for something to work. In the first, you have worked your way through a concept and thoroughly understood it. So much, that you were able to finally make changes to fit it directly onto your individual scenario. That is good. You optimized things and – hopefully – ended up more effective. However, be aware of a pitfall! You went through a huge learning curve to end up where you are. To end up in a state where you could question things. Others did not. This is vital. If you provide consultancy or advice, you have to respect that. Of course, you can explain, why you have adapted or what optimizations you have found, but recommend others to start from 0. Start from textbook. Their scenario is not yours. If you believe you have found a better universal solution, you have to create another textbook. 😁 That brings us to the next category, kind of like the victims of the first, if you want so. You research a topic and ask more experienced people for their opinion. That's wonderful! Always reach out for different perspectives. However, hold in mind that you may not hear the most thoughtful, objective, and unbiased advice. Usually, you end up listening to anecdotes of very specific cases. All of them have in common (or should have) that they tried out what worked for them. This is not your reality. Do not start to simply echo what they told you. I understand why we do that. We want to sound as competent and smart as them, right? And it's, indeed, smart to keep their remarks in your notebook. It is smart to, later, use them for your own thoughts and ideas. It's important, thought, that this needs to take place when you have moved to a state of unconscious competence yourself. You have to start from scratch. You have to start from textbook. Your scenario is not theirs. The last group in my book is related to a different dynamic. If you often diverge from the vanilla textbook approach or are generally eager to challenge new ideas, you might be a victim of the Not Invented Here bias: You think your scenario is too special for anything to work. However, most likely it's not. Most of the time, when we discuss methodologies, frameworks, or industry-standards, there was put a lot of thought into what is almost universally applicable, and what is not. It has already been stripped down to the basic things that are highly likely to fit every work environment. To battle Not Invented Here Syndrome, it helps a lot to know that it exists and that it's easy to fall victim. My first advice is to exercise honest self reflection. Does this apply to you? What behaviors can you observe, and how can you change them? You will never know whether you are right, unless you try things out. And to try them out profoundly, you have to – you guessed it – start from the textbook! Do not try to utilize an adapted version upfront, to accommodate your alleged “specialities.” Try to do it as given. Now I really need to come to an end. This already feels wordy, sorry for that. It's just a phenomenon I observed quite a lot throughout my career, and it always bugged me. Hence, I really wanted to bring this post out. I hope that I got the point across and could convince you to “start from the textbook!” 😁