Build Small Things
The more complex a project is, the more likely it is to fail.
The data clearly confirms it, but if you've spent any time in software development you just know this is true. We can feel the uncomfortable and inevitable words being spoken: "I'm sorry but it was just a lot more complicated than we originally thought". Let's be clear, this problem is extremely costly, it's endemic and it's not improving. The solutions we have today; the catch-all that is "agile", is far from perfect. AI agents are not going to save us.
Build Small Things is the foundational principle that explains why software development succeeds or fails. Every failure can be traced to complexity. Every success can be traced to simplicity.
This simple yet radical approach applies in a multiplicity of arenas. Project planning. Product iteration. Process design. Code organization. Individual work patterns. The same principle that makes a single line of code safe to deploy makes a small project succeed. The same principle that makes a simple system maintainable makes a simple process efficient.
Complexity fails. Simplicity wins. This is true at every level, from a hobby project to a global enterprise architecture.
This isn't just a theory. As a technical leader who's been in the guts of everything from seed-stage startups to hyper-growth unicorns, I've seen that the most common culprit for sluggish development, off-track projects, or projects that never see release day isn't technical debt or a lack of talent. It's the process itself. It’s the very structure we use to think about and practice our work.
Software empowers people, it makes their lives better. It allows us to do remarkable computational things that our brains are ill-equipped to do on their own. To work in software is to improve the lives of those around us. When we can make small improvements to the lives of those people on a daily basis the cumulative impact is profound. Results are constant, impactful and are measured in real time, not quarterly. This requires a different way of thinking. This requires embarking on simple projects with clear goals. This requires writing code that's simple to reason about. This requires full understanding on the "why" behind the "how".
Build Small Things is the alternative to Big Project Syndrome complexity. We don't escape complexity with more process, more ceremonies, or more management. We escape it by making today's fear-based process irrelevant. We ship constantly. We integrate consistently. We discuss continuously. We build a system so fluid and resilient that the bureaucratic rituals of "Agile" look as foolish and outdated as they actually are.
We expect problems to occur. We have the levers to fix things instantly, because we allow for a system that can often bend and sometimes break. Instead of investing in the theater of sprint planning, we invest in a resilient deployment system that makes shipping code, and fixing it, instant, safe, and above all, expected. We escape the giant, terrifying releases trapped in a sprint-first architecture by making releases so small and frequent they become non-events.
Build Small Things isn't just about code. It's about projects that can ship in days, not months. It's about processes that enable real organizational change, not ceremonies that create delays. It's about individual engineers committing hourly, not weekly. It's about organizations that eliminate complexity, not manage it. It's about inspiring those of us who work in software development to say "I built something worthwhile today" and those of us that use software to become active participants in it.
This manifesto shows you how.
The Trap: The Two-Week Prison
Your process is either generating value or it's generating overhead. There is no neutral state. As engineering teams grow, we instinctively pile on process to compensate for the natural erosion of interpersonal trust and the rising cost of failure. But every step added, every new ceremony, introduces latency. It creates task-switching costs. It turns a lean operation into a bureaucracy, one Jira ticket at a time.
A sprint is a time-box. A deadline. And deadlines are where good engineering goes to die. The entire structure encourages you to batch up work, creating large, complex pull requests that are hell to review and even harder to merge. The need to "finish the sprint" leads to cutting corners and accumulating the very technical debt the process was supposed to prevent.
Think about what we try and cram into that two-week box. A Product Requirements Document has to be written. The work has to be prioritized against a dozen other screaming emergencies. UX has to design it. The team has to groom it. Then, and only then, can it be built and tested. We've taken the entire, lumbering waterfall process and simply chopped it into two-week chunks, pretending it's agile. It's a theatrical performance of productivity, where the main output isn't working software, but the successful completion of the ceremony itself.
Worse, it creates a built-in delay machine. A simple request made on day two of a sprint gets the dreaded reply: "We'll get it in the next sprint." Let's do the math on that. The current sprint has to finish (two weeks). The next sprint has to be planned and completed (another two weeks). Then the code has to be tested and deployed. A simple, one-line change can easily take over a month to reach a customer. If you're lucky. This is the opposite of agile.
These "best practices" are the very things that create a self-fulfilling prophecy of slowness. When speed drops, what do we do? We add more process, more SCRUM, more testing, more review, to compensate. This, of course, further slows the team. The sprint cycle itself trains engineers to think in large, slow batches. Why ship a one-line fix today when you can bundle it into the grand, two-week release? This inevitably leads to enormous, multi-file pull requests that are impossible to review, riddled with merge conflicts, and terrifying to deploy. It is a spiral into inefficiency and shattered morale.
While SCRUM, large PRs, and lengthy UAT are all on the list of rituals you should re-evaluate, there is one structure that is almost universally misused in high-growth companies: the dedicated Staging Environment and its fixed Sprint Release cycle.
In a startup desperately trying to find product-market fit, a lengthy, multi-step process for releasing code is poison. The delay between code completion and user validation is pure capital risk. Holding onto finished code for a multi-day review, merging it into a staging environment, and subjecting it to ceremonial testing is a luxury you cannot afford. It is simply too expensive.
The single most dangerous structural dependency you can have is the fixed-cadence, gate-checked Sprint Release.
Velocity is a Function of Risk Tolerance
The most successful hyper-growth teams I've led operated by stripping away these typical dependencies. The goal was always the same: get the code to production immediately. This requires an entirely different Risk vs. Velocity calculation than a mature enterprise. A technical leader's job is not to eliminate risk; it's to choose the right risks to take for where the business is.
I map every organization on a Risk vs Velocity plot. Seed-stage, Sinclair in 1981, and Gopuff where I worked in 2019 sit up and to the right. Nuclear plant software tolerates no risk, understandably so. Gopuff in 2023 had already slid toward a less risk tolerant world, there was simply more to lose; this was a neither bad not good, just a business reality.
Four quadrants. Only one of them is a place you'll survive early.
Most companies want to live in the Efficient quadrant: low risk, high velocity. This is the quadrant where we cosplay agile, pretending we can move fast without ever breaking anything. But you don't get to live there on day one. You have to earn it later, after your architecture and culture is mature and resiliant enough to more at speed whilist absorbing failure.
If you try to force efficiency too early by piling on process, you don't actually reduce risk. You just destroy your speed. You end up in the Stagnant quadrant, where nothing breaks because nothing changes, or worse, the Fragile quadrant, where you take all the damage and still cannot innovate.
When there is a runway and your future is uncertain, you have to live in the Fluid quadrant. High risk, high velocity. Brittle systems, optional tests, immediate shipping.
The job is not to be perfectly efficient. The job is to pick a sweet spot under your real business risk tolerance.
"Eliminate risk" and "avoid technical debt" sound like universal truths, but they lack context. They are noble goals, but they are not one-size-fits-all laws of physics. The same rigor required for a core financial ledger will suffocate a new experimental product feature trying to find market fit. If you apply maximum safety to a system that requires maximum speed, you are solving the wrong problem. Zero technical debt on a product that misses its market window is not a success; it is a beautifully engineered tombstone. You must align your engineering rigor with your financial reality.
A company searching for product-market fit is fighting for its very life; by definition that company must innovate, adapt and change or it will simply not survive. In this state the financial cost of losing two days of velocity to a review/staging/sprint process far outweighs the cost of a temporary bug in production. You are trading precious Time to Market for an illusion of safety. The true strategic value in the early days is validating your assumptions faster than your burn rate depletes your cash. When the house is on fire, you don't form a committee to discuss the optimal water pressure. You grab a bucket.
The Way Out: Velocity as a System
How do you skip the traditional dependencies and engineering rigor without everything catching fire? You must replace Process-based Risk Mitigation with Structural & Cultural Risk Mitigation. Here is what that actually looks like on the ground.
1. Architect for Speed with Tiny, Atomic Units
You can't ship a massive, 1000-file PR straight to production with no tests and no review; that will most likely fail. But you can eliminate the need for it.
- Commit small and often. Every commit should do one thing. When engineers ship tiny, atomic units of work every single day, the very concept of a merge conflict becomes absurd. You can't have a conflict when you're constantly integrating.
- Trunk-Based Development. Avoid long-lived feature branches. Sitting code is dead weight that destroys productivity. If a pull request takes more than a day to review, it creates blockers, is too complex, and should never have been embarked on. If it works, it ships right away.
- Pair on everything. In the age of AI, this means a human-AI pair. Relying on multiple fully autonomous agents is a trap that creates a new Doom Spiral of endless review; work piling up with too many agents left to rush headlong into a problem that engineers can't keep up with. Real velocity comes from the "Editor" workflow: the human is the architect holding the context, while the AI handles syntax and boilerplate.
2. Choke Your Legacy Code to Death
This philosophy of small, incremental change has a name when applied to legacy systems: The Strangler Fig Pattern. It's the most effective way to deal with the monolithic monsters that inevitably grow inside any successful company.
You don't rewrite a legacy system. A full rewrite is a multi-year, expensive death march that will probably fail. Instead, you choke it out. Like the tropical vine it's named after, you grow the new system around the old one. You identify a single piece of functionality, build a new service for it, and divert a fraction of live traffic to the new code. You prove, with real production data, that your new creation is superior.
I've used this pattern for decades to execute bottom-up refactors of codebases in constant evolution, all without pausing the delivery of critical business features. You strangle out the old code, piece by piece, while still shipping at a ridiculous pace. It trades the high risk of a total rewrite for the manageable risk of small, reversible changes, building a system that tests itself so catastrophic failure is mitigated.
3. Build a Culture of Distributed Trust
The fundamental principle that allows a startup to move at speed is federated trust. Sprints, by contrast, are a declaration of mistrust, a tool for managers to package work into predictable, chartable units.
The energy spent coordinating a two-week sprint release should be reinvested into developing resilient infrastructure that enables instant rollback. Skip the dependency. Embrace the fluidity.
Escape the Spiral
You have a choice. You can optimize for predictability. You can build a bureaucracy designed to protect everyone from the fear of incompetence. You can use sprints to package engineering into neat, chartable units that give us all the illusion of safety. But you will pay for that illusion with your velocity, and eventually, your market share.
Or you can optimize for impact. You can build a culture of federated trust, where velocity is the primary architectural requirement.
You don't escape the Doom Spiral by getting better at the ceremonies. You escape it by rendering them obsolete. When your infrastructure allows for instant deployment and instant rollback, the bureaucratic theater of "Agile" simply falls away. Shipping code stops being a terrifying, coordinated event and becomes a quiet, daily habit.
Don't wait for a re-org to change how you work. Start tomorrow morning. Take your current Jira ticket. Split it into pieces so ridiculously small that they don't even warrant a code review. Push the first piece straight to production before you finish your coffee.
If that terrifies you, your units of work are still too big.
Build small things.
