Two sides of the same dune at sunset in the Sahara
The first two things this week might trigger an angry feeling. Please read all three before drafting your letter to the editor…
🧱 Build
When we're putting together a team to work on a new product there are two types of people we need: some who are heads down and some who are heads up.
Heads Down
Some people start with the technology and ask “How does this work, on the inside?”1 They think mostly about the bits of the product that you don't see and beyond that to the underlying implementation. They wonder how it could be improved, without any impact on the outward appearance. They have a deep technical knowledge and an ability to think in algorithms. They worry about performance and efficiency and optimisation.2 They think about the engineering (indeed these people are those who we often label as "software engineers"). In my experience they generally prefer to work by themselves, and can usually tell when they have nailed it. They can sometimes struggle to understand that not everybody is an expert like them, and be dismissive of aspects of the product that seem to them to be simply aesthetics.
Heads Up
Others start with the technology too, but they have a different question: "How do people use this?" They think most about the aspects of the product that people see and touch and interact with and beyond that to how this fits into the broader tasks those using it are trying to achieve. They can empathise with people, and often end up leading product teams.3 They worry about the look and feel. They think about the experience. They generally prefer to work collaboratively, and need lots of feedback to reassure themselves. They can sometimes be naive to the complexities of implementing something that looks simple on the surface,4 and ignorant to the trade-offs that their design decisions impose.
What are ya?
Each time we hire a technical person it's important to work out beforehand which type is right for the role we have. A great team needs a well selected mix of both types of people.
And, if you are a technical person yourself, it's good to understand where you fit into this, as that will help you work out how you can best contribute.
🦄 Believe
With no disrespect intended to either Ms Myers or Ms Briggs, it sometimes feels like there are basically only two types of people:
Fact-based people; and
Faith-based people.
Fact-based people focus on what they can understand and measure and prove.
Faith-based people focus on what they feel and believe, and what intuitively seems right.
What we need
Our knowledge only increases when somebody is wrong
— Karl Popper
Fact-based people need the confirmation of feedback loops to give them confidence that they are making the right choices, or at least making choices that don't suck as much as the other options they considered. The problem is that this fundamental insecurity can easily tip over into paralysis ("what if there is a better option?!") They still need something to prompt them and compel them to act, otherwise they never have a hypothesis to test.
Faith-based people need nothing of the sort. Instead, they rely on instincts and hopes. It's important to differentiate between these two things. It seems reasonable to trust our own instincts. If we don't, it's unlikely that anybody else will. And they are often correct. But, that trust shouldn't extend to blind faith. Hope, on the other hand, is not a method. Hope is generally just wishful thinking.
Ideas in conflict
Like arguing evolution with a creationist
Because there are weaknesses with either approach, there is obviously a place for both. But problems do seem to occur when these two opposing approaches overlap.
Many of us think we are fact-based but then we dismiss evidence that we don’t agree with or which contradicts our worldview (aka the things we believe or need to be true for some other reason). It’s difficult to not be defensive about our opinions or our previous positions. It’s easy to believe we are fact-based.
As I've been frustrated to discover on more than one occasion, it's ultimately futile to argue about specific facts with somebody without first confirming that is what they are basing their decision on. Heresy in the wrong company is no joke!
Likewise, it can be infuriating for somebody with strong opinions to try and work with others constantly questioning their judgement and wanting them to back up gut feelings with a bit of observation. It’s so much faster to skip that step.
For the sake of our collective mental health it would seem that that like minds need to stick together. But, we'd probably all be worse off if we did.
Can we choose?
Wearing a watch doesn’t make you a punctual person. But it gives you the information you need to be one, if that’s your wish.5
I think it’s possible, but not easy.
To become more faith-based we need to learn to trust our instincts more, stop questioning, stop doubting and stop waiting for evidence before acting.
To become more fact-based we need to develop the confidence to change our mind when presented with a better option, and then work over time to make that a habit.
Either way, the important thing is to understand ourselves and those we are trying to work with.
If we do that we increase our influence and save a lot of frustration.
☯️ Split
Simple binary categorisations are enticing.
For example, see above!
Usually, in each of our minds, there is one "correct" box and one "incorrect" box, and the world would just be so much better if everybody could see that!
But, it's usually much more helpful to think of these things as a continuum, and to realise that there are always trade-offs.
For example, consider flexibility.6 Especially as we get older, who doesn't wish they were more flexible?
But, rigidity and flexibility are two ends of a continuum. Both qualities have pros and cons. Being hyper-flexible is just as dangerous and limiting and being hyper-rigid. But, for some reason, flexibility is a quality with positive associations, while rigidity is not.
More examples are everywhere we look, once we understand the pattern. Small vs Large. Offence vs Defence.7 Young vs Old. Urban vs Rural. Rockstars vs Roadies.8 Masculine vs Feminine. Web vs Native. Left vs Right. Seam vs Spin.
When we put ourselves at the extreme end of a continuum, and boast about the benefits of that position, then we are very likely also compensating for some of the extreme downsides associated with that position.
Given that it might then seem that the sweet spot is in the inoffensive middle. But, actually that might not be true either. In the middle the positive and negatives are probably both lower than they would be if we got off the fence!
The reality is: most things are complicated. The more we know about them the less simple they become.
Why can't you just see that! 🙈
🔗 Links…
I’m continuing to migrate some of this writing to a permanent home on RowanSimpson.com.
The ecosystem series I’ve drafted in this newsletter during the year is available in three instalments:
This week I’ve published three more related essays:
Enjoy! And please share them with anybody who might be interested.
Top Three is a weekly collection of things I notice in 2021. I’m writing it for myself, and will include a lot of half-formed work-in-progress, but please feel free to follow along and share it if it’s interesting to you.
For example, see this old blog post: LOAD * ,8,1 and the “Everything was made by somebody” section of my essay: Most People.
John Gruber has a nice way of describing this, in a post from earlier this year about Objective-C.
He said:
There are some good programmers who view their source code as their product. The source code they write is, in their minds, the thing they are crafting. And if the source code, by nature of the language itself, is ugly, that’s a non-starter.
There are other good programmers who view the app they are creating as their product. The app is the thing they are creating and the source code is just a part of the process. It’s the difference between crafting code and crafting apps.
I would argue that both of these fit into the "Heads Down" bucket. There is another level: those who view the things that other people do with their app as the product.
As Eric Ries has pointed out, the career path of a heads-up developer:
Write software
Lead a team of people writing software
Manage people who lead a team of people writing software
Advise people who manage people who lead a team of people writing software
What’s the next step after that? Asking for a friend!
Source: Hackers Diet
HT to Courtney Johnston for this example
See this excellent post from Tomasz Tunguz: A Crypto-Trading Uber Driver and a Billionaire's Spat over Candy - On The Importance of Sticking to Your Strategy