Start With the Smallest Increment That Can Work

David Packard — co-founder of Hewlett-Packard — once recounted advice he’d received from an old engineer: “More businesses die of indigestion than starvation.” I’ve watched that play out in software for almost 30 years. Not just with companies, but with projects.

The instinct when something is important is to throw resources at it. Staff up. Commit a big team. Write a comprehensive plan. Get everyone aligned and then go. It feels responsible. It feels like you’re taking the problem seriously.

But committing too many resources before you know what you’re building and which direction you’re going doesn’t reduce risk. It amplifies it. You get a lot of work done — just not necessarily the right work.

The Big Rewrite Trap

An organization decides to rewrite a critical platform from scratch. They’re frustrated with the current system, often rightly so. The codebase has sharp parts that cause terror in devs, the architecture is creaking under the weight of older decisions, and every change is a risk. So they staff up a big team, pick a new technology stack, and start building.

What they learn almost immediately is that their understanding of the current system and business process is not up to the task. The new codebase is being built in a vacuum, away from production, away from real users, away from the constraints that only reveal themselves when software is doing real work. And nobody has thought carefully about how to migrate from the old system to the new one. The plan is just: rewrite everything, then switch.

There’s a weird phenomena about team size and risk perception. An organization would pause if one person was in charge of a full platform rewrite. They’d accurately assess the risk — that’s a huge amount of work for one person, it’ll take forever, are we sure that when we’re done so much later we’ll be able to replace everything? But give them 20 or 30 people on that team, and suddenly the timeline feels manageable. The team size creates a false sense of safety. The risk hasn’t changed, it’s just been distributed across more people. If anything, it’s possible you’ve actually increased risk.

The Principle

I wrote last week about how Big A Agile is broken — how the industry built process theater on top of a manifesto that was fundamentally about working software and human collaboration. But the original agile insight remains as true as ever: start with the smallest increment that can work, ship it, and iterate.

That principle applies to the software itself, obviously. Build something real, put it in front of people, learn from what happens, and make it better. But it also applies to how you organize the work and the team. You don’t need to know the final shape of the engagement on day one. You need to start, learn, and grow as the picture comes into focus.

At BiTE, we’ve internalized this so deeply that it shapes how we enter client engagements. We often start with a single senior engineer. Sometimes it’s even smaller than that — an architectural review, a few days of focused assessment that identifies strengths, weaknesses, and a path toward greater stability. That limited engagement can be the first move, or the only move. Either way, it’s the smallest increment that can work.

How This Actually Plays Out

One of our longest client relationships started this way. Years ago, my co-founder Joe and I were brought into ICON — one of the world’s largest clinical research organizations — for a small engagement. A couple of weeks, maybe a month. The ask was to help their team adopt BDD as they kicked off work on a new platform.

That was it. A short engagement to teach a methodology and help them get started.

But once we were in the room, the engagement grew — not because we pushed for more scope, but because the work revealed what was needed next. BDD training led to writing executable specifications for the new platform. Specifications led to architecture. Architecture led to managing the offshore development team building the platform. Over time, BiTE grew to more than ten people across that engagement, handling multiple concurrent clinical trials and helping shape the architecture of their next-generation system.

When ICON needed to rescue their COVID clinical trial platform in the middle of a global pandemic — tight timelines, frequent protocol changes, regulatory compliance across multiple countries — they turned to us. We stabilized the platform, digitized over 10,000 informed consent forms, supported nine languages across 15 sites, and helped ensure the trial’s success.

That entire relationship, spanning years and multiple engagements, started with two people in a room for a couple of weeks.

Why Small Teams See Risk Clearly

There’s a structural reason why starting small works beyond just limiting commitment. Small teams are honest about what they don’t know. When you have two or three people on a problem, there’s no place to hide uncertainty behind parallel workstreams. Every risk is visible. Every gap in understanding is felt immediately.

Large teams can defer hard questions. They can build elaborate scaffolding around problems they haven’t actually solved yet. It feels like progress because people are busy. But busyness and progress are not the same thing.

A small team working on a live system — shipping real code that does real work — discovers the true shape of the problem faster than a large team building in a vacuum. And once you understand the problem, you can grow the team with confidence, because you know what you’re growing toward.

Start Small

The best projects I’ve been a part of didn’t start with a giant team and a sweeping master plan. They started with a small team, a working build, and a willingness to let the work reveal what was needed next. The best client relationships worked the same way. One small engagement created the understanding that made growing possible.

It’s the same principle at every level. Build the smallest thing that works. Ship it. Learn from it. Grow from there. The code, the team, the engagement — they all follow the same logic.

Start small. Iterate. Repeat.