The ‘I want to be like you’ fallacy
Let me start with a tweet that I love:
I love it because it exposes the – very human – desire to find a shortcut by replicating a formula that has been ‘proven’ to work. That formula could read:
- Step 1: Look at successful people
- Step 2: Replicate a random thing that they advocate/do
- Step 3: Profit
The tweet above satirises nepotism, but there are other versions of this joke that replace nepotistic hiring with e.g. a multi-million dollar trust fund. In all versions, however, we have a situation where it’s highly likely that one element has a disproportionately large effect on the outcome, and that this one element can’t be achieved through effort (large inheritance; parent’s company). The other elements, achievable by most people (early wake-ups, journaling) are obvious red herrings, in this case, poking fun at our appetite for the quick fix that will change our lives.
Hearing from successful people is an ever-popular type of “training” (Bill Clinton, Tony Blair and Lance Armstrong regularly top the best-paid speaker lists, commanding hundreds of thousands of dollars for short speeches). In successful-people-masterclasses, we hear a boiled down nugget of ‘what worked’ from someone who achieved something impressive (or was around when it happened). We rely on them to identify the key element in a complex context. The same is true with the addictive concept of “best practice”. But by simplifying it and abstracting away from its context, we not only get an unnatural focus on one action, but we actually lose the most powerful lesson that experience can teach us: how to use context for decision-making.
Let me give you some examples from my career as a CTO and as a CTO Coach of when ‘wisdom’ from one context is entirely inappropriate for another:
- The startup founder who told me they wanted to keep their team tiny “because Instagram was acquired for $1B with 13 employees”. That company is doing brilliantly but, according to LinkedIn, it has more than twice as many employees as Instagram. I’m happy for them that they stopped trying to follow someone else’s path!
- The Head of Product who’d been managing a team of 100 across 14 countries and used the same approach for a team of 5 because of “Best Practice” (it didn’t go well).
- The fairly experienced software developer who wanted to use functional programming in a language that didn’t support functions as first-class objects “because functional programming is the future”. He wrote convoluted code that he struggled to get through code review.
In each of these examples, context is key to solving problems, something that most people don’t appreciate when they are giving you the 5 habits of highly effective nuns. Pun absolutely intended.
One popular masterclass topic that suffers hugely from not looking at context is ‘strategy’. In fact – forgive the brief rant – strategy is one of the most overused words in management and leadership. It’s become a word I shudder to use, like Agile or MVP, because their misuse is so commonplace that it has all but replaced the original meaning. ‘Strategy’ is often used to mean “with a long-term view”, which is vague and unsatisfying. True strategy, according to people who study it, is about contextual decision-making. I.e. it’s about the application of wisdom to a unique situation.
But do devs *need* wisdom? The short answer is: sometimes. Not all devs need wisdom, and wisdom isn’t needed at all times. But when it is needed, it’s invaluable.
For example, you don’t make big decisions on the trade-offs of monoliths vs. microservices every day, but when you do they can be critical.
Knowledge vs. Skills vs. Wisdom
I’ve spoken about differentiating between these different types of learning at CTO Craft Con, and I think it bears repeating in this context because the methods of learning should be different for each.
- For knowledge (recalling info) – content consumed passively / actively is fine. Knowledge can be gained and maintained through
- repeated exposure
- recognition testing
- recall testing
- spaced repetition etc.
- For skills (doing things better) – this requires active engagement rather than just passive consumption. Skills can be gained through:
- constructive hands-on problem solving
- practising with feedback
Adding an interactive human element is even better, bringing the benefits of engagement, feedback and peer learning. It’s critical that we aim higher than recognition/recall for skills. It’s not enough that they know about the skill, they need to be able to apply it appropriately and effectively.
- For wisdom (improving judgment) – this can be taught through simulated contextual scenarios in which you look at a range of contexts and examine why one thing worked in one situation, and how it could be applied (or misapplied) to another. These exercises need to allow for deep situational analysis, and a comprehensive evaluation of solutions available.
When ‘wisdom’ is presented as ‘copy me’, it creates a dangerous mentality that discourages questioning and re-examining, and encourages application of the same approach wholesale.
So then, if we can’t trust the cheat sheets of others, and we can’t trust conclusions drawn from experience, what’s left?
Asking Why, not How
Too often, when someone is successful – or we are successful ourselves, we flock to ask how? What we should be asking (if our goal is to learn from it) is “why?” You might be familiar with using “5 whys” to analyse process failures, but do you use them to analyse decisions made? Do you ask “why not”?
An example that comes to mind based on a conversation with a company I’m working with is:
- We’re adopting Go,
- Why? It runs really fast.
- Why does that matter to us? We know our customers spend more when the site is fast.
- Why not C++ – that runs fast? It’s harder to hire C++ engineers, and Go engineers can typically write equivalent code faster.
- Why wouldn’t [insert company] use Go? They use JS across the stack, so adding another language would be a big pain for them, and they probably don’t have the resources to upskill on something so new or so different from JS.
That moves you from a rule of thumb like “Go is fast, everyone should use Go” to wisdom like “Go is the right choice for us because our customers are performance-sensitive”. Compared with other languages that produce fast code, it’ll probably be easier to hire Go engineers at the moment, and Go teams likely have a higher velocity. However, it’s not for everyone; you need to have the resources to learn a new language, and that learning curve might be steeper from other languages like JS.”
In leadership – as well as in tech – being effective is often about making decisions that are right for the context: Should I scale people or process first? Should we adopt Kubernetes? Should I continue coding as a CTO? The answer to these questions should always begin with ‘it depends’. There are no crib sheets, no ‘best practice’ that guarantees success.
BUT that doesn’t mean we can’t learn from others: quite the opposite. By understanding the ‘why’ behind the best practice, the context behind the success of others, you are able to make an informed decision about whether it’s right for your context. And, in the process, get a little bit wiser.
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more!