Second-Order thinking
Mental models provide a systematic way of dealing with problems. When you are faced with one, you can try to run it through a mental model, and see if a new insight pops. A commonly used mental model is Occam’s Razor. Which states that the simplest explanation, among many competing explanations, is likely the correct one. Or Hanlon’s Razor, that states that we shouldn’t attribute to malice what can be easily explained by stupidity. This is a good adage to keep in mind, especially in professional contexts. People are not actively plotting to make your life harder - it’s more likely that they are just clueless.
One of my favourite ones is Second-Order thinking. It provides the headspace to think about the impact of immediate actions and its ramifications. It forces us to contemplate the whole system, not just the local effects. Remember when you changed something in one part of the system, led to unintended consequences somewhere else. How many times did you fix a “trivial” bug that caused an issue somewhere else?
Bugs are bad, but in the grand scheme of things, most of them are fixable without too many consequences. Human relationships on the other hand, are harder to fix. There are two examples, where being aware of Second-Order thinking can help.
The first one is when one of your reports tells you they are having issues with someone else. This happens more than one can imagine - even in smaller companies. A less experienced manager will follow suit. They will talk with the other person and serve as a proxy between the disgruntled people. I want to make this as clear as possible: this never leads to good results. Ever. The moment you step-in, you are further breaking the relationship these people share. If the other person is being rude, or completely inappropriate, you should be either talking with their manager, or with HR. But most situations aren’t like this. Most situations are small misunderstandings that are solved with a quick 1:1 over a coffee. And that’s exactly what you should encourage your report to do. To schedule a 1:1 with the other person and allow them to settle their differences by themselves. The reason why this falls under Second-Order thinking, it’s because if you interfere, in the short term, you might solve the issue. But you are not doing these people any favour in the long term. You want to give them space to build trust with each other and find common ground. You can’t do that if you get mixed up in their issues.
The second one happens when you want to fix something you assign to someone else. This typically happens to an engineer that just got promoted to management. The coding skills are still sharp and they are likely competent as an IC. But they are now a manager, so they need to act as one. So a critical bug gets logged and an engineer starts working on it. People are getting stressed and asking you, the manager, where things are. You are now feeling the pressure. You are confident that you know how to solve it, since you previously built part of that system. In fact, it’s easier if you just fix it yourself, rather than explaining to the engineer how to do it. Things are on fire, time is of the essence, so you just do it. People are happy, problem solved. Most people believe that code is Truth and what matters is that the bug is squashed. But humans don’t work like that. The engineer that was originally assigned to the task is likely annoyed with the whole situation. They probably feel bad that they couldn’t solve the issue by themselves and that their manager doesn’t trust them. A far better approach was to either pair with the engineer and find a solution together. Or to keep the pressure off the engineer and give them time to find it by themselves. In both approaches, you might lose some time, but the trust and feeling of self-worth remains intact. This is another example where mid to long term consequences are not thought through.
There are many more examples where speed, or time, is favoured over things that humans value more. Competent managers know this, but they are also know when rules should be broken.