I have recently re-listened, after 10 years, the “Lean Startup” by Eric Ries. I think it was and still is an important book and in retrospect, I wish that I had taken it more to heart and re-read it more often. But I have some major qualms with it as well.

Qualms

I will start with what looks like a minor qualm, like nitpicking, but which I hope to show lies at the heart of my disagreements with this book. This is the issue of the abuse of the term “scientific”. The author insists on labeling his ideas as scientific over and over again but instead of showing us anything remotely resembling science, he offers us a series of anecdotes of how folks were failing before they had the “theory of lean startup” and then they were succeeding. The worst part is that he actually knows that this is not science:

Taylor invented modern white-collar work that sees companies as systems that must be managed at more than the level of the individual. There is a reason all past management revolutions have been led by engineers: management is human systems engineering.

And that is the proper framing of the problem of management: it is an engineering challenge. I see the software systems we build as human-technological constructs because we build and operate machines in an indelibly human setting.

Somewhere deep inside, I suspect that the author knows this as he later writes:

In a startup situation, things constantly go wrong. When that happens, we face the age-old dilemma summarized by Deming: How do we know that the problem is due to a special cause versus a systemic cause?

Therefore the effort cannot be just guided by theory but rather by constant iterations of the application to the changing circumstances. Or as lay person would call it: engineering.

The next example is an utter reversal of one of the cornerstones scientific method: falsification. The author writes:

It is these questions that require the use of theory to answer. Those who look to adopt the Lean Startup as a defined set of steps or tactics will not succeed. I had to learn this the hard way.

Hence successes can freely be attributed to Lean Startup theory but failures (not that we can find any in this book) must be because the theory was not applied correctly (see Ad Hoc Hypothesis). So while he is admonishing us (rightly!) to form testable hypothesis regarding our projects, he refuses to form a single testable hypothesis of his Lean Startup theory itself. Consider:

• This book contains no statistics on success and failures of Lean Startup methodology.
• This book contains no comparison of Lean Startup methodology with other methodologies and its relative merits (or demerits)
• This book contains no attempts to show that the success rate is higher in the world of startups ever since the Lean Startup movement came to be.

It is all narrative with zero math, statistics or intellectual honestly. This book cannot even define the failure modes of Lean Startup - we are supposed to use it everywhere, no matter the circumstances. And after all this the author, at the end of the book, has the gall to call other management practices “pseudoscience”:

Although we harness the labor of scientists and engineers who would have dazzled any early-twentieth-century person with their feats of technical wizardry, the management practices we use to organize them are generally devoid of scientific rigor. In fact, I would go so far as to call them pseudoscience.

Why this need to appeal to the authority of science? Apart from the obvious (who could be against science!), I feel that the author really wishes hard (too hard) for his theory to be generally applicable, removing the human factor. At the same time, he knows that it is, quite literally, impossible to remove it. This conflict comes to fore in “Organizational Superpowers” where he tries to argue that a participant in one of his workshops is both brilliant but that his insights have nothing to do with brilliance. The kicker is:

He is frustrated because the managers he is pitching his ideas to do not see the system. They wrongly conclude that the key to success is finding brilliant people like him to put on their teams.

You know what happens every time you have a bunch of un-brilliant people, provide them just with the theory, time and materials and they go on and succeed in their endeavour? What happens is that Hollywood makes a movie out of it because it is so, so, so rare, that we all flock to the theaters to see this feat.

My experience informs me that the exact opposite is true: some folks have thought harder and better on some problems than others and their judgment is consistently better (e.g. Eric on startups vs Ivan on startups). Going to Eric’s workshops is one way of improving judgment but even before that the person has shown good judgment in merely deciding to go! Had I not wasted my time and talent on years of engineering feats, I would not be as receptive to Eric’s message as I am now. But I was not smart enough to not waste time and talent in the first place.

And once again Eric implicitly agrees because in the very next section he writes:

Taylor is remembered for his focus on systematic practice rather than individual brilliance.

and then after a lengthy quote continues:

Unfortunately, Taylor’s insistence that scientific management does not stand in opposition to finding and promoting the best individuals was quickly forgotten.

I don’t understand this inability to embrace that yes, we do depend on great, exceptional work of humans, on their brilliance if you will, to make anything of value.

By sheer chance, as I was thinking about all this, I was also re-reading “Of the Liberty of Thought and Discussion” by John Stuart Mill and stumbled on this quote:

knowing that he has sought for objections and difficulties, instead of avoiding them, and has shut out no light which can be thrown upon the subject from any quarter—he has a right to think his judgement better than that of any person, or any multitude, who have not gone through a similar process.

At the core, some people will be much better at building X than the average: they care more about building X, they have thought more about building X, they have experimented more at building numerous failed variations of X and so we should seek out these individuals and give them a chance to build X, rather than wishfully thinking that just with the right theory, anybody can build X just as well. We have been building buildings for millennia and yet we oh so definitely know that there are people that are brilliant at building and people that are shoddy at it - even when they went to the same school and studied the same theories.

The Good Parts

Years ago I read “JavaScript: The Good Parts”. What stuck most with me, beyond , is that we can strive to extract “the good parts” in things that overall are not great but have a lot to offer nonetheless. And the good parts in Lean Startup are more than good - they are… ahem, brilliant.

Building a startup is an exercise in institution building; thus, it necessarily involves management.

I recently (on November 17th, 2023 to be precise) had an epiphany: people who are really serious about software (and I am really serious about software) should do their own management. This is of course me paraphrasing Alan Kay’s quote: “People who are really serious about software should make their own hardware”.

This must be obvious to many but it was not to me: I have struggled with the problem of stewardship before but I have not previously embraced the need, the necessity of actually managing, both upward and downward, in order to achieve the best outcomes.

Eric’s experience shows here: he knows that institution must be built in order to succeed. We could softly call this “culture” but I love the use of word “institution” here as it is much harder. I recently joined Levels and while Levels is young, it feels like I’m joining a deliberately designed institution.

The core of the book, its best chapters, that carry far more weight than others are “Measure”, “Pivot (or Persevere)” (maybe the most important chapter in the book) and “Batch”. It is those tactics that are more than enough for you to navigate the topology of any problem space:

• Figure out where you are (the baseline) and how to orient yourself, measuring the progress in whatever direction you may be going.
• Change course whenever the measurements are off. Execute the pivot when you conclude that you have reached a local topological peak.
• Do not make huge course changes where you lose the ability to measure for too long. Rather than that prefer small but significant enough changes to be able to repeat the measurements.

I don’t want to undersell the importance of reading these chapters - there is a lot of good reasoning and deep explanations of why this works. But furthermore, when you are in fray of building, it is so, so easy to forget to check if what you are building should be built in the first place. It is on this insistence on stopping the waste where the book is strongest and author’s voice surest:

We would not waste time on endless arguments between the defenders of quality and the cowboys of reckless advance; instead, we would recognize that speed and quality are allies in the pursuit of the customer’s long-term benefit. We would race to test our vision but not to abandon it. We would look to eliminate waste not to build quality castles in the sky but in the service of agility and breakthrough business results.

Conclusion

I started by saying that Lean Startup is an important book. I sincerely feel this way. I really wish I had re-read it often - warts and all - if not the whole book then those core chapters that I mentioned. I wish I had pivoted away sooner and more frequently in my own startup of one (called career) rather than persisting beyond reason and I do think rereading this particular book would have helped. So: recommended with reservations.

Last modified on 2024-03-08