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 explained by stupidity. This is a good adage to keep in mind. People are not plotting to make your life harder - it’s more likely that they don’t know any better.

One of my favorite 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, leading 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 are harder to fix.

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. This falls under Second-Order thinking, 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.

When you want to fix something you assigned to someone else. This happens to an engineer that got promoted to management. The coding skills are still sharp and they are likely competent as an IC. But they are now managers, 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 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, the problem is 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 assigned engineer 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.

When a manager keeps providing solutions to their team, instead of problems. It’s tempting to do this, when you feel you have a good grasp about the problem space and confidence in your technical ability. Good engineers are rare. You can find people that know how to code, but this doesn’t mean they are good operators. Good engineers like the technical aspect, but their drive comes from solving user problems. If you remove the latter, they will lose interest in the former as well. As a manager, you can pull this stunt a few times, until you see productivity drop. There are a few other things that come out from this and similar situations. First, it becomes increasingly difficult to evaluate your team and hold them accountable. The tasks are coming from the manager, if the initiative doesn’t succeed, who is at fault? The engineer that did what was asked, or the person that provided a shopping list of tasks? The second is that trust erodes. Engineers will ask, why is this person always on top of me and telling me what to do, instead of trusting my judgement? Questions like “why was I even hired?”, or “why can’t I be allowed to do my job?” will come about. Along the way, both accountability and ownership are lost. I have seen this happening plenty of times without the manager (either EM, or PM) even noticing.

There are many more examples where speed, or time, is favoured over things that humans value more. Experienced managers know that actions and decisions don’t happen in the vacuum.