Giving advice? Simplicity is king.

I’ve been playing a lot of Go, but recently I’ve switched to Chess and I’ve been playing it way more for the past six months.

As I was playing Go, one of the frustrating things was that I had difficulty figuring out which move was bad and why.

It’s a little bit easier in Chess. Even without a computer analysis, you can replay your game and find critical points. Oh… here I missed that they can do a fork. Oh… here they pinned my knight, and for the next ten moves, I had to dance around it. You will probably miss a lot of nuances, but you can immediately learn from your mistakes.

Getting back to Go. Quite often, understanding the explanation (why some move was bad) required reading ten moves ahead with multiple permutations, which was WAY beyond my abilities. As a result, it felt like — here is a good position, a lot of magic happens, boom, you are obviously losing.

The issue with such explanations is that to understand it, you need to be at the level where you won’t be asking for help with this situation anymore.

There were numerous times when I felt similarly regarding some business/career advice. Communications are not my forte. To be more precise, I am good in a low-risk/high-respect environment. I am significantly worse at it in high-risk/adversarial situations.

So, there were numerous times when people who were WAY better than me (about communication in adversarial situations) gave me advice. Usually, it was advice on how I should structure my communication and what should be the fallback plans and what I should and should not say.

And lo and behold. I felt exactly like with Go analysis. The advice didn’t have anything explicitly wrong, but it was applicable to a person who is better in such situations (and who probably could have figured out such a situation on their own).

While contemplating the matter and when asked for advice, I formulated the following set of rules.

• Advice should elevate a person a bit. It’s an unreasonable expectation to try to bring a person to your level in one step (if the difference is way too big).
• Advice should provide good direction (while giving a person some wiggle room, taking into account that the person can’t do a carbon copy of what you do).
• Advice should be actionable.

Just to give you an example from my area of expertise. I worked with a bunch of junior software engineers, and there is a standard question of how to get better/advance. Here are advice that I usually give:

• Read more (well-known) books about programming.
• Try to grab some not-trivial projects and work on them.
• Do what others won’t do (for example, write documentation, etc).

I don’t try to go down three levels down trying to precisely specify the order of execution, exactly what kind of non-trivial projects to work on, how to communicate about it with people and make it visible through the company.

If they follow my simple advice, they will become better and will be ready for more nuanced and complex conversations. And if I dump on their head buckets of extremely complicated advice, they will just snap back to their default mode of operations.

As I wrote in the title — Simplicity is the king.