Advice is data, not code
When receiving advice...
Advice you receive shouldn’t be taken as programming instructions. It’s not code.
Advice is best treated as data. Additional information you should factor into your framework.
In life you get a lot of advice. At some point I probably believed some of it was good, and some of it was bad.
It wasn’t until I was a startup founder that I realized, when you’re surrounded by smart people whose incentives are aligned, it’s possible to receive multiple pieces of very good advice that directly contradict each other. For example:
- Hyper-focus vs spread your bets
- Build a product, not a consultancy VS do things that don’t scale
All of this is good advice. For example, nobody thinks you shouldn’t be opportunistic and take advantage of opportunities that arise. But different people will have a different sense regarding the value and payoff likelihood of opportunities that present themselves.
Taking advice as instructions from lots of different corners results in failure to execute on any given path well. Instead, treat honestly given advice as another person's observation of a data point — which may open your eyes to some possibility, or cause you to change how you weight things.
The costs of giving advice
When giving advice...
Providing others with advice carries close to zero marginal direct cost, taking only the time required to conceive and dispense it.
Depending on what the advice relates to, and who it is given to, there may — however — be indirect costs:
- If followed, and things turn out poorly for the other person: relationship or reputational costs;
- If followed, and things turn out poorly for you: the other person may get what they want at your expense;
- It not followed, and things turned out well for the person anyway: your judgement may be doubted in future going forward;
Dispense advice carefully.