The late Dee Hock, founder of Visa, was a business legend in many respects. Like many of the most revered founders, his ideas were years ahead of their time, and his writing is clear, concise, and super interesting. He famously organized Visa around a decentralized management model, in an era when the norm was the extremely centralized, hierarchical structure. Companies like Amazon, Johnson and Johnson, Uber, Valve Software, and others have adopted the same principles Hock pioneered to make their companies more resilient in the face of challenge.
In 2000 he published a book called Birth of the Chaordic Age which described his thesis on systems that straddle a boundary between imposing order while embracing chaos — ”chaordic” systems. This essay sets out the central idea:
The production of goods and services has progressed from the Age of Hand-crafting through the Industrial Age, more accurately thought of as the Age of Machine-crafting, into the so-called Information Age, which can best be understood as the Age of Mind-crafting, (or as I prefer to call it, the Chaordic Age,) since information is nothing but the raw material of that incredible processor we call mind and the pseudo-mind we call computer.
The Age of Machine-crafting was primarily an extension of muscle power. The Chaordic Age is primarily an extension of mental power.
In the Chaordic Age, where innovation and successful “adaptation” requires the leverage of individual minds, organizations need to embrace individual intuition and judgment to keep up. In the past, the primary goal of a corporation was to encode processes and decision-making criteria into the corporate structure itself — to eliminate the need for any particular person, and make the human beings interchangeable equivalent parts. Hock says in the future, this model won’t work:
In organizations of the future the centuries-old effort to eliminate judgment and intuition, art if you will, from the conduct of institutions will change. Organizations have too long aped the traditional mechanistic, military model wherein obedience to orders is paramount and individual behavior or independent thinking frowned upon, if not altogether forbidden. It will be necessary at every level to have people capable of discernment, of making fine judgments and acting sensibly upon them.
He was onto something. Business schools need to catch up.
Geospatial analytics company Descartes Labs recently sold to private equity, in what former CEO Mark Johnson calls a “fire sale.” This post is his perspective on the nature of the business over time, their missteps along the way in both company identity and fundraising, and some of the shenanigans that can happen as stakeholders start to head for the exits.
Not knowing much about Descartes’ actual business, either the original vision of the product or its actual delivery over the years, I don’t have much specific perspective to offer. But this story is a recurring theme in the world of spatial, earth observation, and analytics startups that have come and gone over the past 10 years or so. These businesses are built on extremely capital-intensive investments in satellites, space-based sensors, and data, which are major hurdles that cause many of them to get sideways in their fundraising structures very early in their business journeys.
The early years of a startup are always extremely volatile, with pivots and adjustments happening along the way as the company navigates the idea maze, looking for product-market fit. I think the heavy capital required up front compels funders to expect too much too soon in the product development process. There’s a chicken-and-egg problem — the PMF search in these kinds of businesses costs many millions. If you’re building a SaaS project management tool, you can wander around looking for fit for years with only a few people and limited seed money. But in satellite startups, the runway you need to do product-market experimentation is enormously expensive. Large enough funding pools also saddle the business with aggressive expectations for customer counts, growth, and revenue. With revenue targets set but no repeatable PMF, many of these startups do whatever they can to find dollars, which often leads to doing what are effectively custom services deals for a single or few customers. That’s necessary to make money of course, and it’s not valueless for product validation. But it’s too narrow to function as true PMF. Stay in this awkward state too long and you end up stuck down the wrong hallways of the idea maze. You’ll never find the fitness you need to build a lasting business. Billwrote a great post on this recently, about this identity struggle between being a solutions, services, or product company.
The best thinking on the topic of EO and satellite data companies is my friend Joe Morrison’s newsletter, “A Closer Look”. He leads product for Umbra, a startup specializing in SAR. He’s done a lot more thinking than me on this topic and has thoughtful takes on the satellite and geo market in general.
“Efficiency is doing things right; effectiveness is doing the right things.”
— Peter Drucker
People throw around these two words pretty indiscriminately in business, usually not making a distinction between them. They’re treated as interchangeable synonyms for broadly being “good” at something.
We can think about effectiveness and efficiency as two dimensions on a grid, often (but not always) in competition with one another. More focus on one means less on the other.
That Drucker quote is a pretty solid one-line distinction. But like many quotes, it’s concerned with being pithy and memorable, but not that helpful.
“Doing things right” is too amorphous. I’d define the two dimensions like this:
Efficiency is concerned with being well-run, applying resources with minimal waste; having an economical approach
Effectiveness is a focus on fit, fitting the right solution to the appropriate problem, being specific and surgical in approach
Where would speed fit into this? Many people would think of velocity of work as an aspect of efficiency, but it’s also a result of and an input to effectiveness. When a team of SEAL operators swoop in to hit a target, we’d say that’s just about the pinnacle of being “effective”, and swiftness is a key factor in driving that effectiveness.
Let’s look at some differences through the lens of product and company-building. What does it mean to orient on one over the other? Which one matters more, and when?
A company is like a machine — you can have an incredibly efficient machine that doesn’t do anything useful, or you can have a machine that does useful things while wasting a huge amount of energy, money, and time.
With one option, our team leans toward methods and processes that efficiently deploy resources:
Use just the right number of people on a project
Create infrastructure that’s low-cost
Build supportive environments that get out of peoples’ way
Instrument processes to measure resource consumption
Spend less on tools along the way
With this sort of focus, a team gets lean, minimizes waste, and creates repeatable systems to build scalable products. Which all sounds great!
On the other dimension, we apply more attention on effectiveness, doing the right things:
Spend lots of time listening to customers to map out their problems (demand thinking!)
Test small, incremental chunks so we stay close to the problem
Make deliberate efforts, taking small steps frequently, not going too far down blind alleys with no feedback
Another great-sounding list of things. So what do we do? Clearly there needs to be a balance.
Depending on preferences, personality types, experiences, and skill sets, different people will tend to orient on one of these dimensions more than the other. People have comfort zones they like to operate in. Each stage of product growth requires a different mix of focuses and preferences, and the wrong match will kill your company.
If you’re still in search of the keys to product-market fit — hunting for the right problem and the fitting solution — you want your team focused on the demand side. What specific pains do customers have? When do they experience those pains? What things are in our range that can function as solutions? You want to spend time with customers and rapidly probe small problems with incremental solutions, testing validity of your work. That’s all that matters. This is Paul Graham’s “do things that don’t scale” stage. Perfecting your machine’s efficiency is wasted effort until you’re solving the right problems.
A quick note on speed, and why I think it’s critical to being effective — if you’re laser-focused on moving carefully and deliberately to solve the right problem at the right altitude, but not able to move quickly enough, you won’t have a tight enough feedback loop to run through the iteration cycle enough over a period of time. Essential to the effectiveness problem is the ability to rapidly drive signal back from a user to validate your direction.
When you find the key that unlocks a particular problem-solution pair, then it’s time to consider how efficiently you can expand it to a wider audience. If your hacked-together, duct-taped solution cracks the code and solves problems for customers, you need to address the efficiency with which you can economically expand to others. In the early to mid-stage, effectiveness is far and away the more important thing to focus on.
The traditional definition of efficiency refers to achieving maximum output with the minimum required effort. When you’re still in search of the right solution, the effort:output ratio barely matters. It only matters insofar as you have the required runway to test enough iterations to get something useful before you run out of money, get beat by others, or the environment changes underneath you. But there’s no benefit to getting 100 miles/gallon if you’re driving the wrong way.
Getting this balance wrong is easy. There’s a pernicious aspect to many engineers, particularly so in pre-PM-fit products: they like to optimize things. You need to forcefully resist spending too much time on optimization, rearchitecting, refactoring, et al until it’s the right time (i.e. the go-to-market fit stage, or thereabout). As builders or technologists, most of us bristle at the idea of doing something the quick and dirty way. We have that urge to automate, analyze, and streamline things. It’s not to say that there’s zero space for this. If you spend literally zero time on a sustainable foundation, then your product clicks and it’s time to scale up, you’ll be building on unstable ground (see the extensive literature on technical debt here).
There’s no “correct” approach here. It depends on so many factors. As Tom Sowell says, “there are no solutions, only trade-offs.” In my first-hand experience, and from sideline observations of other teams, companies are made by favoring effectiveness early and broken by ignoring efficiency later.
I enjoyed this interview with Stripe co-founder John Collison. The range of topics covered in this discussion is wild. Always impressive to see someone that’s been so objectively successful still maintain the level of curiosity he does, motivated to constantly fill knowledge gaps.
A sampling of the discussion topics:
Industrial conglomerates
Value of writing skill and clear internal communication
Fred Wilson with advice to startups on keeping things simple:
I have sat through numerous pitches where I am listening to the founder explain their technology and go to market plan and I think “this is going to be a reverse triple somersault with two twists in pike and there is no way they are going to land it…
So the better approach is to pick something simple to execute, nail it, then build on it with another relatively simple move, nail that too, and keep going.
One of the benefits of staying in bootstrapped mode is that this is forced on you; if you make projects or goals too big, you waste time and money and don’t hit the target. There’s a temptation to overcomplicate goals or to try and build something too complex because it feels like it’s more valuable. If you index on the wrong things, you can get yourself convinced that the number of features tracks with value, when we all know that’s dangerous territory to tread, especially for small teams.
