Prioritise The Highest Order Bit

I met Dinesh Raju about 10 years ago, at a startup event that I no longer remember. In that first meeting he gave me an early version of what I now call ‘beware what sounds insightful’, but he was talking about startup advice, not online writing. I listened very carefully (and this is quite obvious, given that I wrote this post on VCs, years later) and internalised it in the decade that followed.

Much later, when I was already running operations in Vietnam, I came to him for management advice. He told me to reread Ray Dalio’s Principles, and to work my way through High Output Management. I did both. About a year after that, I came back and told him I was much better as a manager, that retention was high and morale was great, and he gave me a link to his company’s management doc. He told me to pay special attention to the section titled ‘prioritise the highest order bit’.

I thought it was pretty good.

I met up with Dinesh again a couple of weeks ago. He said something along the lines of “I’ve always found the highest order bit idea to be profound, and the older I get, the more I realise how profound and true it is” — so I went and looked up his management doc again.

The phrase ‘highest order bit’ isn’t new by any means (Bill Gates used it in Microsoft in the early 90s, so presumably it was in the air before that), but I thought that Dinesh’s articulation was particularly useful. I quote, from his doc:

Prioritise the Highest Order Bit

When evaluating past decisions or thinking about making new ones, a useful analogy to use is the flipping of the highest-order bit.

The binary representation of a number is made up of a set of ordered bits. The number 13 would be represented as 1101.

The increase in value of flipping a higher-order bit outweighs flipping all the lower-order bits combined. 100 is bigger than 011, 1000 is bigger than 0111, and so on.

So aim to identify and flip the highest order bit because if you don't, you're not going to be able to make up for it by flipping everything else.

An entrepreneur may look at a successful diner and think that customers are there because of the hip decor on the walls. She sets up a competing diner across the street with better decor only to find that it can't pull any customers away. The highest-order bit isn't the decor. It's actually the cheap but high-quality coffee that customers care most about. Without getting the coffee right, no amount of aesthetics will beat the competition.

In the real world, it gets more complicated since bits are intimately linked to one another. Flipping a higher-order bit may reveal a string of unflipped lower-order bits, or may even require unflipping lower bits first because of resource constraints. Customers at your diner really want home delivery. But you'll need to buy a van for that, and to afford it, you're going to have to sell some of the decor.

Many of the flaws you see in a startup are lower-order bits which were left unaddressed or even deliberately unflipped, so that higher-order ones could be flipped first.

So far, this is pretty standard stuff. The highest order bit implies that you want to always be working on the most important thing. Almost by definition, the most important thing is the thing that moves the needle for your work, not necessarily the thing that is most tractable right now.

But the document has a second section, that adds additional nuance to the idea:

Get to the ideal state by iterating relentlessly

Given the importance of the highest-order bit, it might be tempting to drop everything else and focus only on flipping it first. If our breakfast diner's signature coffee is bland, shouldn't we stop trying to improve the decor or serve more customers until the coffee is fixed? Unfortunately it's not that simple.

- You don't always know which bit is the highest-order one, how to flip it, or even what the flipped version looks like. This should be unsurprising, because pretty much no one else knows either. In startups especially, what we 'know' is the product of generalisations and communications about half-truths from the environment we're in. It takes time to develop the intuition to see bits in the right order and how to flip them. You develop this intuition by producing more work and flipping more bits, even if they end up being lower-order ones. Speed up the process by constantly getting in sync with people whose opinions are more accurate than yours.

- You don't always have the right resources to flip the highest-order bit. Even the most successful companies in the world are limited by resource constraints. To get more resources, you'll need to flip some lower-order bits first. Even though these improvements will be of the lower-order variety, they show growth and potential. This growth begets more resources which can then be used to target higher-order bits.

Hang on to the irritation you feel when you see all the ways that the bits in your environment aren't lined up. You feel this because you have taste.  Safeguard your taste, but don't let it grind you to a halt. Instead, channel that emotion. Work on all the bits you have the ability to flip with the resources and skills you bring to the table. Fix them the best you can while still seeding and driving new initiatives, even lower-order ones. We ultimately want to build exemplary awe-inspiring products, and we will. But understand that the only practical way to get there is by iterating relentlessly through interim states that are uninspiring but improving.

All this means that you need to be comfortable with making decisions which leaves many bits unflipped or even cause flipped bits to regress. You'll need to do this even while being burdened with flaws from decisions made by others in the past.

Startup decision-making is therefore an exercise in:

1. Inheriting an environment that has many shocking flaws.

2. Identifying the highest-order flaw that you have the ability to address with your limited resources.

3. Picking the best available action to fix it, even if it risks making some lower-order flaws worse.

4. Starting again from step 1 with, hopefully, a less egregious set of shortcomings to choose from.

And I realise that this bit is what best explains the chaos of building an early-stage startup.

Playing House

Here’s an example. I remember one time, late in 2017, when we had revenue problems in my old company. (An explanation of how this came to be would take too long; suffice to say it had something to do with an abrupt change in the market that occurred in second half of that year). I was due to leave the business, so my boss and I sat down for dinner, and I pointed out a half dozen time bombs with the way we were managing our team. I said he needed to fix that or risk having people leave the company. But he disagreed.

“Look I understand, all of that is bad, but what’s worse is our company running out of money. I need to solve this first.”

He turned out to be right.

But of course I was also right  — I was good enough at management at that point to predict the problems correctly. In the end, we took a huge hit on morale, and a bunch of good people left. It took the company a year before they recovered. My boss was ok with this. The highest order bit was ensuring that the company survived, never mind that certain ‘bits regressed’, as Dinesh would put it. Rebuilding that revenue took all of his attention for the next year; he willingly let other problems go.

I’ve often said that the biggest thing I learnt from my old boss was cash discipline — or at least, an understanding of what cash discipline looks like. We were bootstrapped, and we sold actual hardware — which meant two big things: first, we could only spend what we sold, and second, a chunk of our cash was always tied up in inventory. My boss’s focus on cash flow meant that we would often take shortcuts on lots of other things. Technical debt? All the time. No proper user testing for months at a stretch? Yep. Ignore certain customers, and risk burning our relationships with them because a more important customer needed help? That too. We patched up the processes over time so they became less bad, but we were never 100% blowup free.

Much later, I learnt that company building at the expense of business building was a common failure mode for startups. Michael Seibel says, of that tendency:

When you have product-market fit, you should do company building, but most people never get it. And most people should never be doing company building. And most people should never be investing their investor dollars in company building. They should just be investing in product. That's hard. Product can punch you in the face every day. And sometimes, you want something new, you want something different. If your products punch you in the face, but you're hiring great people, you can squint, lie to yourself, and tell yourself your company's doing well, until you run out of money.

If you’ve never worked at a startup, and you wonder what it means when people say ‘every startup is a shit-show on the inside’, well — this is what it means. The advice to ‘focus on the highest order bit’ is easy to say, but the natural implication of putting it to practice, especially in a resource-constrained environment, is that you often have to let other things blow up. And Dinesh’s company management doc is the best articulation I’ve seen of this simple truth.

Originally published 20 April 2021, last updated 29 April 2021.