Bits and Bobs 10/23/23
2A sketch of a model for choosing what projects to invest in.
Imagine all of the projects you could do as a graph of possibility.
Every node you build opens up other adjacent nodes, too.
The frontier of possibilities has a combinatorial explosion... so you need some way to decide which ones to invest in.
Parallels to the Assembly Theory academic paper I linked last week.
Imagine a north star representing your vision or long-term goal.
Imagine each adjacent (edge + node) combo has a few components:
An orientation (angle towards or away from the north star)
A one-time cost to build
A marginal cost to operate
A marginal value to users when they use it
An uncertainty term that obscures all of the other terms
One approach is to pick the node that is most aligned with your north star.
You might even do some instrumental UXR to reduce some local uncertainty, given that you want to take a big step in a given direction.
Downsides of this approach: the cost to build might turn out to be exorbitant, or the activation gradient (marginal value / marginal cost) might be shallow, or even negative!
Another approach is to first sit with the problem, almost communing with it.
Taking the time for the cloud of uncertainty to lift, just a bit.
You should spend at least some time looking for novel, disconfirming evidence. You might find a great pathway you hadn't considered.
Then, you look for cheap projects that have the strongest activation gradient (marginal value / marginal cost) and also bring you at least incrementally more in the direction of the north star.
This research is broader, more exploratory, more based on intuition and sensing.
You might call this approach "novelty search with vibes"
This approach goes slower in the short-term, but is more likely to discover long-term viable/fast paths.
3Imagine a problem domain where you have a list of projects everyone agrees would be good to do in the fullness of time.
A trap I've seen a lot in my career is to spend a ton of time prioritizing/coordinating on the precise, optimal order to build them.
The optimal sequencing might be 1x cheaper than the non-optimal sequencing.
Discovering the optimal sequencing is hard, because there will be lots of uncertainty that won't resolve until later.
The cost to coordinate in uncertainty and identify the optimal sequencing could easily be 10x - 100x more than just picking an arbitrary sequencing.
On net you could spend 90% of your time and effort basically bickering, and only 10% building.
In these cases, it's better to simply pick a good-enough sequencing, not even pretend it's optimal, and just start executing.
4Here's a quick technique to earn loyalty from a counterparty.
Multiple times, proactively give them something you know they will value before they even ask for it.
This demonstrates to them that you are proactively looking out for them and not treating them transactionally.
The signal is even stronger if the thing you give them has some direct cost to you.
5Last week I riffed on distinguishing skill vs luck.
I should have also linked to Michael Mauboussin's excellent book The Success Equation: Untangling Skill and Luck in Business, Sports, and Investing
Here's a nice summary from my friend Sam Arbesman.
One of the key ideas is that early in a market skill predominates; as the competitors get more skillful, luck tends to predominate as the skill component is competed away.
6Another benefit of open source development: you don't have to assert that it's good enough; users can decide that for themselves.
When you market a product, you're essentially asserting "I believe this tool is at least good enough for your use".
Sometimes that's hard to distinguish a priori, and if you get it wrong you can significantly erode trust.
But often your product is "good enough" for some motivated subset of your users well before you realize it.
Open source development allows a thing to not be marketed, and yet still have the possibility of self-selecting users using it anyway.
When users start using it, that gives you some signal to help you get a better handle on the implicit decisions you've made, an opportunity to tweak them.
Once it's heavily used by self-selecting users, marketing it becomes a no-brainer accelerant, instead of a do-or-die moment of truth.
7A primary use case is what gets your user to join.
A secondary use case can become one that gets your user to stay.
There's a class of secondary use cases that have a self-hoisting quality.
They start off small but can grow to the point where their activation gradient is above the bar and later they can sometimes become the primary use case.
But when they start off, secondary use cases are fragile seedlings that will wither in the sun; they need to stay in the shade of a primary use case to give them the space to grow.
8A possible definition of deep (vs superficial) beauty: "it works the way you'd expect it to"
The ideal of the expectation is not "whatever some rando thinks after considering it for 12 seconds," but what a thoughtful user would expect if given infinite time to reflect on how it should work.
That is, how close to the platonic ideal of the product can you get?
9Imagine a specific type of orange tree where 0.1% of planted trees will turn out to provide fruit that is literally made of gold.
Anyone can plant an orange tree and get some normal oranges out of it (a meager profit)... but also a bonus lottery ticket.
Each seedling is a bet with capped downside (mainly opportunity cost) and significant upside.
To guarantee great returns, you'd need a big enough orchard to plant 1000 trees: 1000 bets.
10I wanted to build on a riff in the excellent Invest Like The Best podcast: John Collison, Patrick Collison - A Business State of Mind
People talk about the interesting things, but reality has no interestingness bias.
Most real things are mundane.
People talk about interesting things because the surprising model-updating things are what makes sense to spend the very small number of conversation tokens on.
But this creates an illusion of the true distribution of interestingness.
11Imagine two discussion participants.
Imagine two discussion participants. What's the most interesting thing for them to talk about?
If they talk about things they already fully agree on, they'll waste time and expensive conversation tokens.
If they talk about things they fundamentally disagree on--that are so outside each others' current mental model that they track as incomprehensible noise or actively clash--then they'll lose trust and come out of the conversation with nothing to show for it.
There's a goldilocks zone: things they don't currently agree on but are close enough that they could come to agree on them through sharing information.
12Curiosity can sometimes look like humility, but they're distinct.
Humility is recognizing you don't have all the answers, while curiosity is the drive to seek them out.
Different types of humility are also distinct:
intellectual (free floating ideas)
pragmatic (situated in real operational problems).
emotional (mindset)
You can have curiosity or humility in any of them.
If you have humility in one but not the others, you have a blindspot that could be quite dangerous.
"I'm humble and curious, so the person who is missing something must be them."
13Be compassionate to your past self for decisions you made.
You did it in an environment that was way more uncertain than today!
It's way way easier to make decisions after the fact, because now you know how some of the wave functions will collapse.
The view from the future looking back is on a relative basis practically omniscient.
It's common to have been right when you made the decision (based on your bets in uncertainty) and wrong now (based on how the world has evolved, and what things have now become more clear).
The correctness of your decision is not static; it changes as the conditions change.
14If as a leader you don't acknowledge a fundamental tension, then you've set up your subordinates for failure.
The task is secretly impossible and yet your subordinates are responsible for delivering it.
If you're distracted or busy, when the project fails it's easy to erroneously conclude not "the idea is wrong" but "the execution was wrong".
Sharing disconfirming evidence from the person responsible for executing a plan once it is committed can look like making excuses.
The people best situated to understand disconfirming evidence (e.g. how hard a given task actually is) are those executing on it, developing knowhow.
If people fear being blamed for execution issues, they might not share relevant disconfirming evidence.
That's why seeking disconfirming evidence from subordinates before committing to a plan is the best way to make sure you understand the forces in tension.
16Try to use each hour of your time in its highest and best use.
If it's a special / rare hour, use it for special / rare things.
For example, if you're on a short trip to Dublin and your coworkers ask you to go to the pub after work, even if you're tired, you should go!
As another example, if you're based in Dublin and go to the pub with your coworkers multiple times a week, then maybe it is better to every so often just stay at home with your partner and watch Netflix.
17A conversation I had a few years ago at Google with a VP who had joined from outside straight into the Office of the CEO.
"Let me guess how you see Google. You were told that this was a place full of smart, hard-working, collaborative people. But it turns out that they're actually lazy back-stabbing toddlers," I said.
He nodded enthusiastically.
"Let me suggest a reframe. These people really are smart, hard-working, collaborative people. And yet they're behaving like lazy, back-stabbing toddlers. What is the hidden force that is causing that to happen?"