8 Myths of Building "Lean"
The Art of Requirements II: Balancing alignment and leanness in digital architecture and engineering
Like Agile, “lean” has become something of a meme or cliche in the business and technical world. This is no fault of Eric Ries or whoever may be deemed responsible for revitalizing the term, but it does require us to exercise some thinking muscles to recover the original idea here.
Let us first restate what “lean” is, then what is not, before we consider general principles to build lean from a technical design perspective.
The Lean MVP
We will take Eric Ries’ The Lean Startup as our starting point on this subject.
The startup, or more broadly the initiative, is concerned with building something new to fill a gap. If there is a gap, then there necessarily is uncertainty around how to fill that gap.
The core business proposition or objective should not be primarily locked into filling the gap with this particular solution but rather commit itself to solving a particular problem through hypothesis testing various solution.
Thus the core loop of building lean is to identify a business hypothesis with metrics to measure the success, and even more importantly the failure of said hypothesis. From there, the MVP is the smallest possible test that addresses the riskiest, most uncertain assumption. The MVP provides actionable information to inform the initiative which can pivot and iterate upon such findings.
It is validated learning that directs innovations in an auditable way to provide growth.
What Lean Is Not
Like waterfall in Agile's clothing, many business and technical professional like to attribute this positive buzzword “lean” to many things that are decidedly not lean.
Any initial prototype is deemed an MVP even if there is no consciously articulated business hypothesis being tested.1
Here are some common ways un-lean thinking can disguise itself as “lean”.
1. Avoiding Planning
This is perhaps one of the most common misuses of “lean” I encounter across organizations, particularly in startup culture.
Building technology is not easy.
The advance of time has led to the proliferation of technologies, their terms, their mappings, and their use cases. Things are not getting simpler.2
However if you are a decision maker on digital products, platforms, or applications, especially for a freshly-minted start-up, you may struggle to wrap your mind around all the options that are out there and confront you, whether through vendors or opinionated engineers you work with.
Taking each on their own may be simple enough but then they need to be reckoned altogether, and the complexity balloons the more factors you take into consideration.
Given such difficulty and a desire to “move fast” or “just build”, the temptation is to adopt a “lean” methodology and forego any and all considerations around system architecture whether it is the application you are building or the company’s operations itself.
However this can quickly turn into a let’s-throw-everything-at-the-wall-and-see-what-sticks mentality.
This can work, much like you can win at Russian roulette, but it is risky and more often than not costly.
Again this aversion to systems planning or enterprise architecture is not unfounded.
Plan-avoidance can take precedence as a gut reaction to the endless meeting chains of Waterfall. Talking everything through ad nauseam before one could even start doing anything at all.
Startup founders exiting corporate environments may feel liberated from QBRs and Scrum-of-Scrums and use this newfound freedom to instill a culture of technical anarchy in their startup.3
But as any technology professional is well aware, once there is the glimmer of gold in a dev, sandbox, or even local environment, the immediate question is how soon can we get this into production.
So if various individual contributors (ICs) are working on projects or features in their siloes, whatever shows the slightest signs of fruit, may face intense pressure to find its way to a production environment, with minimal other considerations.
Unless the IC is a master class contributor, then this is where things can get hairy, in trying to find this path to production. Some complicating factors includes but are not limited to:
How to build or deploy this across environments
How are secrets/keys managed
How secure is the application
Can it scale and/or handle load
Is it reliable and sustainable
Can it be extended for other features or patterns
Is it costly to run with a live user base
Can other ICs work on the application without an immense learning curve
If AI was used, how much bloat or inconsistent patterns are present (along with all the other gaps AI-driven coding can introduce)
The prototype first, plan later mindset inevitably puts the cart before the horse and can lead to serious delays, frustrations, and costs, simply because basic considerations around the operations of the workload were never considered, out of a desire to “think lean”.
This is not to say that one should overplan either.
Planning should take into account the tradeoffs. How much time do you validate hypotheses or engage in systems design rather than proceeding with caution?
Ideally you would be working with the production stakeholders to identify the factors that go into the “pipeline to prod” so that you do not face hang-ups before you get there.
2. Avoiding Thinking
This is similar to the first, but slightly different.
While planning-avoidance prematurely waves off systems planning, environment management, compliance etc. as “too heavy”, thinking-avoidance simply will take the most immediate, presented solution or idea as the best one.
This arises when there is a known problem or set of tradeoffs to consider either in the technology or operational structure of an organization.
You know there is a problem, but identifying the proper solution to that problem may require critical thinking or hypothesis testing.
The human temptation is to eschew that kind of hard work or hard thinking in favor of taking either the first solution recommended by their particular AI assistant or by saying “we’ll figure it out later”.
Many will quote design principles of minimalism or again call it “lean” to simply not worry about the problem and cross that bridge when we get to it.
But again this can end up being very costly and regrettable in retrospect, when a day or two of consideration could have saved the firm five or six figures of cloud or personnel spend or lost sales revenue.
This leads to deferring the answer to whatever is proposed first and following the chain of developments, eyes half shut, to see where it goes.
“Lean” is about actively prioritizing hypothesis testing using data and critical judgment, but like plan-avoidance, thinking-avoidance can often take on the label of lean minimalism to justify passivity or our own human tendency toward laziness.
3. Find the Case to Justify the Assumption
Another far too easy trap to fall into is shifting the purpose of the MVP or the lean prototype away from solving a question and toward proving an answer.
Technologists in startup and corporate environments often have a keen interest in their intelligence optics.
Because intelligence is immaterial and intangible, it becomes an ongoing site of competition around the players who claim to be technical, and even some who deny being technical but will reserve the right to enter technical debates.
The rivalries and various episodes that emerge from this can be dramatic enough, but it can also engender behavior that is costly to the company or the particular initiative.
People can attach their ego to this or that proposal. This or that solution they propose.
Then they feel the need to protect them, like their own children.
This is when thinking lean becomes about finding the right test that will prove the pre-selected answer.
It is the mindset that says, I know what is most lean, but I need to justify it so everything can see it.
So MVP hypothesis testing is oriented primarily around reinforcing the credentials of the one who authored the hypothesis rather than an honest assessment of its value delivery.
A problem not limited to technologists either but can range across a wide range of personalities and roles.
But it is how one can claim to be lean by finding the minimal acceptable evidence to advance a theory that they have already set in stone.
4. High Velocity, High Volume
One of the most appetizing facets of a lean methodology is the purported ability to “move fast”.
High developer velocity.
Low time to market.
This paves the way for more… features, features, features.
Imaginative and more visionary personalities can often struggle to balance the influx of new ideas against discipline, focus, and keeping it minimal.
They can take the “lean methodology” to mean that it’s got the metabolism to absorb a glut of caloric features without gaining weight.
Even the most scalable and extensible systems architecture can enable and support feature overloading, but at the cost of UX.
This can tie into plan avoidance, as the stakeholder may simply want to see if such and such a feature works or gains acceptance.4
If the technology counterparts can keep up, the number of features is itself taken as the definitive success metric, regardless of its impact.
The trick with “lean” is to find the test that can kill a feature before it proves costly to the company, if it should prove not to be worth the effort. Not to create a runway to load up on features ad infinitum.
5. High Velocity, Low Quality
A cousin of the previous mentality is the implicit acceptance of low quality work, particularly technical implementation, just in the interest of getting things out the door.
This can emerge in a variety of ways.
One, for the business line that operates out of a sense of constant urgency and last-minuteness, the technical IC is compelled to cut corners on their work, even though they know better. They hold their breath and finish the user story, knowing they have introduced technical.
Two, perhaps the business line is somewhat patient, but an engineer has mis-estimated the work. They have gone through several iterations, and now it is getting down to the wire, so when they stumble across something that barely works, the engineer will sprint toward that solution and pat themselves on the back for delivering at the eleventh hour.
Or let us say the product owner or equivalent business stakeholder takes a holistic, architectural mindset to iterative development. In other words, they are sharp and know they need to leave room for systems decisions.
This can also backfire, particularly in environments where the IC helps draft their own technical requirements.
Three, the technical IC who wants to minimize the amount of work they need to complete in the short-term will enumerate a long list of reasons or justifications for why they cannot meet certain additional acceptance criteria or systems requirements.
In their words, it is too darn complicated or difficult, and all the technical gobbedly-gook frightens off the product owner from pushing them any further on it, settling for whatever minimal quality the IC feels like accomplishing.
Long-winded pushback of this kind can successfully trick managers out of basic technical standards evaluation (e.g. idempotent migrations, retry logic, consistent React state), all because the IC will argue that the low quality technical work is the “lean” option.
Four, on the other end of the spectrum an overzealous engineer can propose an incredibly sophisticated and powerful piece of machinery for their feature, and on the off chance they estimate it somewhat accurately, it seems incredibly expensive and over-extended for them to complete any of these tasks.
In the interest of being lean, a manager or other stakeholder will thus descope any and all systems considerations to avoid the overengineered approach they are presented with, simply because often those same overzealous ICs have a very hard time self-selecting or prioritizing what is properly most important for systems design or scalability.
Thus the engineer is overruled because they could not constraint their production-readiness expectations to something acceptable to the business line.
In all of these, as some of you may be able to tell, a large part of the problem is perhaps due to org structure, roles, responsibilities, and separation of concerns, but all the same, it is easy to see how ostensible concerns about being “too heavy” can be used to ignore considerations around quality, sustainability, reliability, or scalability.
6. Pennywise
When budgets or seed round money are a concern, the myth of building “lean” can often find a way to justify saving pennies at the expense of pounds.
These are often the founders or startup cultures least amenable to the idea of “you have to spend money to make money”, perhaps because they have seen that line used to burn entire investor rounds.
But the idea of building lean can often be used to unnecessarily constrain the technology and talent pool budget in ways that can prove costly in the long-run.
Hiring junior or nearshore engineers has its benefits, especially when getting off the ground, but it also has its downsides if you want a scalable application with sustainable development velocity.
Going all in on the managed services for prototyping may seem the cheapest, smart move for avoiding hosting costs, but sticker shock at a minimal Kubernetes cluster may very soon be outweighed by the costs of getting off AWS Amplify or Vercel.
There is of course a virtue to fiscal discipline that can be lost on many startup executives with a starry-eyed vision and flush with investor cash, but the other extreme may constrain the startup or initiative’s potential for growth out of a rhetorical to be “lean”, when this is a misapplication of what is meant by a process focused on surgical, scientific precision to solve business questions.
7. The Lean Contortionist
All of the above myths come out of some sense of reducing or subtracting complexity in order to help build something “lean”, even if they misapply the original idea.
However, there is an entire separate category which has found a way to reinvent something “heavy” by virtue of the lean methodology.
This can arise out of a demand to be “lean” enough to be extensible in any and every direction.
You end up getting buried in a morass of requirements around portability, observability, HA, BC/DR, scalability, OS support, security, compliance, and anything else that can be thought of.
These can come from senior technical manager or architects who are unable to properly limit the field of vision or constrain their requirements in the traditional MVP sense and thus burden any new digital initiative with a potpourri of non-negotiables so that it is “lean” enough to change course to fit any requirements. Another way of just being heavy.
8. Silencing Stakeholders
This last one overlaps with many of the above but depending on how evolved or mature an organization is, this is when one feels there are simply too many competing voices in the room, and they feel it drowns out startup focus on rapid iteration and product velocity.
This can lead executives and managers to unilaterally exclude particular stakeholders from the iteration process, just so the time-to-market doesn’t have to be bogged down by meetings and perspectives.
It is not entirely unsympathetic if your governance, regulation, compliance (GRC) stakeholders multiply your iteration cycle by a factor of three or five with very untargeted, generic feedback.
Or if your infrastructure team is complaining about competing priorities and they will not be able to get around to it until next quarter. And you just want it done.
Thus the temptation to just opt not to invite those folks to this or that meeting, and tell them you did not want to bother them since you know how busy they are.
You want a lean, tight, small team to help get your feature or product to production, and the stakeholder bandwagon can get in the way of that sometimes.
But that is not what lean was proposed to accomplish.
Epilogue: Lean + Platform
Some of you may have experience with these species of pseudo-lean, or perhaps others besides those listed above.
There is no one size fits all to preventing or alleviating these.
Some of it comes down to properly weighing tradeoffs. Perhaps you do need to go in blind on some things.
Perhaps it is an issue of org structure and skillsets.
One way to provide a foundation to build “lean” is the premise of platform engineering.
Out of the hundred or thousand various considerations that can swim around any technologists’ eyes, the IC should be able to work with surgical focus that optimizes the value-delivery of their work while minimizing their need to “reinvent the wheel”.
This is why enterprise architecture, baselines, patterns, self-service infrastructure, platform bootstrapping, all of these provide the ingredients to abstract away many sources of noise or secondary concerns from the developer.
The security, compliance, infrastructure, and whatever else requirements are moved out of their field of vision and distraction.
This can help them hit the keyboard running. And build it.
Lean.
That of course does not prevent someone stumbling upon such hypotheses or findings by accident, even if they are not strictly following the MVP model.
Even if generative AI advances may abstract away the day-to-day complexity of writing software or managing config files, under-the-hood, that complexity is still very much there.
Alternatively, on the other end of the spectrum, a CTO or technical CEO may be so opinionated that there may be no room for discussion at all. The best of these will document and communicate their technical vision to individual team members, but there is often an inverse relationship between technical and communication/management skills.
Or worse they may presume that feature will have to be popular and do everything it takes to make that feature gain user acceptance.