On Effectiveness vs. Efficiency
Res Extensa #57 :: Comparing two ways of thinking about team management
“Efficiency is doing things right; effectiveness is doing the right things.”
— Peter Drucker
We throw around these words indiscriminately in business, not making a distinction between them. They’re treated as interchangeable synonyms for being “good” at something.
I think about effectiveness and efficiency as two dimensions on a grid, often (but not always) in tension with one another. More focus on one means less on the other.
That Drucker quote is a solid one-liner: pithy and memorable. But like many quotes, it compacts meaning and erases useful detail. It’s more memorable than it is helpful.
“Doing things right” is too amorphous. What do we mean by “right”? I’d redefine 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
One can be effective in hitting a target but costly and inefficient to make it happen. Conversely, optimal management of time and resources doesn’t imply reaching the objective.
Let’s look at some differences through the lens of product and company-building. What does it mean to index on one over the other? Which one matters more, and when?
Comparing the two
One common analogy compares a company to a machine. You may have an incredibly efficient machine that does nothing useful, or one that produces golden eggs while wasting a massive amount of energy, money, and time. Now let’s imagine two teams on this spectrum.
With one model, a team leans toward methods and processes that efficiently deploy resources:
Uses just the right number of people on a project
Creates infrastructure that’s low-cost
Instruments processes to measure resource consumption
Spends less on tools along the way
With this sort of focus, a team gets lean, minimizes waste, and creates repeatable systems to build scalability. All sounds great!
On the other dimension, the team puts more attention on effectiveness, doing the right things:
Spends lots of time listening to customers to map out their problems (demand thinking!)
Seeks constant feedback on whether or not what we’re making helps customers make progress
Tests small, incremental chunks to stay close to the problem
Makes deliberate progress, 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 we want a balance.
Context is the key
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.
One aspect we haven’t address yet is speed, the clock rate of work and decision making. Many people would consider speed an aspect of efficiency. But a certain type of speed is a necessity to tighten the feedback loops enough to be effective — we call this velocity, not speed: speed in a given direction. It’s hard to be effective without a talent for rapid triage, removing things that don’t contribute to the outcome, even when those things help us be efficient. Effectiveness requires high-signal, high-frequency feedback.
When a team of SEAL operators swoop in to hit a target, we consider that just about the pinnacle of being effective, and swiftness is a key to that effectiveness.
When you find the key that unlocks a particular problem, 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 most important thing to focus on.
The traditional definition of efficiency means achieving maximum output with the minimum required effort. When you’re still in search of the right solution, or you still don’t quite understand the problem you’re working on, the effort:output ratio barelymatters. 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 per gallon if you’re driving the wrong way.
Like everything, it’s complicated
It’s easy to get this balance wrong. There’s a pernicious trait many technologists carry, particularly dangerous in pre-PM-fit stage: we 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 thereabouts). As builders, lots 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 watching others on the sidelines, companies are made by favoring effectiveness early and broken by ignoring efficiency later.
Thanks for reading. If you found this useful or interesting, please share with your friends, connections, and colleagues. And as always I welcome feedback or challenge to my perspective. Does your experience line up? Am I misguided? Comment below and let me know!
Sounds like good advice with one major exception regarding efficiency. There is an entire software industry based on reuse of existing tools, apps, and code (amplified by AI tools now). This level of optimization makes complex product design feasible today.