In every boardroom and engineering hub I’ve ever worked in, I see a fundamental conflict between two schools of thought. I call it the “The Big Reveal” vs. “The Collaborative Increment.”
1. The Perfectionist Fallacy (The “Big Reveal”)
This approach says: “Do not show it to the world until it is perfect.” In engineering, this often manifests as “Gold-Plating”—spending weeks refining a sub-system or a UI component that hasn’t even been tested by a user yet. It feels safe to stay in the lab, protecting the design from early criticism. But in a fast-moving environment, it is often a death sentence.
The Risk: You spend six months building a “perfect” architectural bridge, only to realize the user actually needed a boat. By the time you “reveal” the final product, the technical requirements have shifted, or your core assumptions about user behavior have been proven wrong.
2. The Collaborative Increment (The “Iterative” Phase)
The second approach—the one we live by at OpenLM—is to release early, release often, and invite the “tension” of feedback into the engineering process immediately.
We work in increments. We get a “walking” version of a feature—one that functions but might not be polished—out the door to see how it survives in a real-world production environment. This isn’t about being “unfinished”; it’s about being “responsive.”
Understanding the Strategy: The “Two-Way Door”
To understand why iteration works, we have to look at how leading firms like Amazon categorize engineering and business decisions. Jeff Bezos famously split all decisions into two types:
- Type 1 (One-Way Doors): These are near-irreversible decisions. If you walk through, you can’t go back without massive cost. Examples include choosing a core database architecture or a primary programming language for a legacy system. These require slow, perfectionist deliberation.
- Type 2 (Two-Way Doors): These are reversible. If the decision was a mistake, you can just walk back through the door and try something else. Most software features, UI layouts, and API endpoints are Two-Way Doors.
When you treat a “Two-Way Door” as if it were a “One-Way Door,” you kill your engineering velocity. The goal is to walk through as many Two-Way Doors as possible to see what’s on the other side.
Following the Master: The Linus Torvalds Way
If we want to understand why this approach works, we have to look at the master of modern engineering: Linus Torvalds.
When Linus was developing the Linux kernel, he didn’t wait until it was a polished, feature-complete OS to show it to the world. Instead, he pioneered a philosophy that changed software history: “Release early, release often. And listen to your customers.”
At OpenLM, we follow this example. Linus understood that a single engineer working in a vacuum for a year can never compete with a thousand engineers providing feedback in real-time. By releasing Linux 0.01 when it was barely functional, he invited the world to help him find the “truth” of the code. He famously proved that “given enough eyeballs, all bugs are shallow.”
Following Linus’s example means letting go of the ego that says “I must be perfect” and embracing the humility that says “I need feedback to be great.”
What the Research Says
Beyond the world of Linux, significant research supports the power of iterative engineering:
- The “Marshmallow Challenge” (Peter Skillman): In this study, groups of engineers and kindergarteners build structures out of spaghetti. Kindergarteners consistently beat MBA students because they start building immediately, the structure collapses, and they try again. They iterate, while the adults over-plan a single “perfect” failure.
- The Pixar Method: Ed Catmull, co-founder of Pixar, famously said: “All our movies suck at first.” They use a “Braintrust” to provide brutal, early feedback on “ugly” versions of stories before a single frame of final animation is rendered.
- Effectuation Theory (Saras Sarasvathy): Academic research shows successful entrepreneurs look at the tools they have now, create a small result, and pivot based on what happens next, rather than waiting for a “perfect” plan.
Engineering: The “Monolith” vs. The “Micro-Release”
The difference in these approaches is most visible in how engineering teams handle new feature requests:
- The Perfectionist (The Monolith): The team goes into a silo for three months to build the “complete” version of a new module. They write thousands of lines of code based on internal assumptions. On the day of the “Big Reveal,” they push to production—only to find users are confused or the logic creates a performance bottleneck they didn’t anticipate.
- The Iterative Engineer (The Micro-Release): Following the Torvalds model, this team builds the “Minimum Viable Logic.” They release it via a feature flag to a small group. They monitor the logs and watch how users interact with it in real-time. Within a week, the data tells them what actually works. They scrap the unneeded complexity and double down on the core 20% that provides 80% of the value.
By the time three months have passed, the Iterative Engineer has a feature that is lean, efficient, and battle-tested. One approach relies on the “ego” of the architect; the other relies on the “truth” of the environment.
The Culture of “Early Feedback”
At OpenLM, our approach is to get feedback while the “clay is still wet.”
It requires a certain level of vulnerability to show a fellow engineer or a customer a version that isn’t “finished.” But the result is a product that has been “battle-tested” by reality, not just polished in a vacuum.
The goal isn’t to be right the first time. The goal is to be right the fastest.
