Early in my career, coming from industrial engineering, I learned a simple rule that has shaped the way I think about software development ever since.
Software may look abstract, creative, fluid.
But underneath, it behaves like a production system.
The best articulation of this idea appears in The Goal by Eliyahu M. Goldratt, one of the most influential books I have ever read.
In production, every system revolves around three outputs you can influence:
- Quality
How many defects you are willing to accept.
In software, this translates to bugs, stability issues, security vulnerabilities, and edge cases. - Quantity
How many units you want to produce.
In software, this is the number of features, capabilities, or improvements you deliver. - Time
How frequently or how fast you want to ship.
Weekly releases, quarterly roadmaps, or a tight deadline for a strategic launch.
The rule: You only get two
These three dimensions are tightly coupled. You can optimise for two of them, but never all three.
Examples:
• High quality and many features → long time
You can build a rich, stable product. It will take months.
• High quality and fast delivery → very few features
You can ship something excellent by Friday. Just expect it to be small.
• Many features and fast delivery → low quality
This is the classic recipe for bugs, instability, technical debt, and customer pain.
This was true on a factory floor.
It was true when I led QA, when I led R&D Operations, and it remains true today in Product.
Why this still matters
Modern product development is faster, more automated, and more collaborative.
But no process, no tool, and no AI model can break the physics of systems.
When you push one corner of the triangle, something else must give.
• You want to accelerate roadmap velocity. Something must shrink.
• You want zero bug escapes. Something must slow down.
• You want more features per release. Quality or timelines will absorb the cost.
Teams get into trouble when they pretend the triangle does not exist.
The real skill: finding the equilibrium
Every team and every company must find the right balance between:
• what the market needs
• what your organisation can actually absorb
• what your customers value
• your tolerance for defects
• your appetite for technical debt
• your strategic urgency
Sometimes the right move is to sacrifice time to protect quality.
Sometimes the right move is to ship something small but fast.
Sometimes speed is the strategic weapon and quality trades off for learning.
Great product and engineering leaders do not fight the triangle.
They navigate it deliberately.
They make the tradeoffs explicit, visible, and aligned with strategy.
And they understand that this is not a one time decision.
You have to keep asking these questions and continuously adjust the triangle, sometimes almost in real time.
They ask:
• What are we optimising for right now?
• What are we consciously giving up?
• What will we pay for later if we push too hard now?
• What is the right equilibrium for this moment?
Software is production. The triangle still rules.
The tools evolve. The domains shift.
But flow is still flow. Bottlenecks are still bottlenecks. Tradeoffs are still tradeoffs.
Understanding this triangle remains one of the most reliable ways to keep teams focused, aligned, and honest about reality.
If you respect the physics, you ship better products.
If you ignore it, the system will remind you.