Over the past two decades, I’ve been part of a couple of small startups that have managed to navigate the chaos and have consistently delivered products that the market has embraced.

Our success boiled down to a few key factors, but one standout contributor was the power of small, motivated teams, made up of engineers who understood the market, our users and the whole tech stack.

LLMs make small, lean teams far more productive. Prototyping is cheaper too: it’s now quicker to build something and refine it than to document how it should work.

But there are no real frameworks on how to keep such small teams happy, motivated and focussed on the tasks at hand.

Traditional Agile methods like Scrum work in larger organisations, but they become wasteful in a small team without a dedicated QA, Scrum Master or Product Manager. The pain is worse when the team is remote and spread across time zones.

So here is how I deliver when I get to set things up my way. I call it the Motivated Engineer Framework, though it’s less a framework than a habit that has worked for me again and again.

Everything starts with a clear goal. Not a ticket or a spec, but a plain statement of what we are trying to achieve and why it matters. If the team can’t say the goal in a sentence, we aren’t ready to build anything yet.

Next, I get the right people on a call. That means whoever knows the most about the problem: a customer-facing colleague, a founder, an engineer who has been close to that part of the system. Before we meet, everyone involved prepares a short brief on the options they can see for solving it. The meeting then becomes a decision rather than a brainstorm, and it rarely needs to run long.

Then we build. If the goal is a big one there will be plenty of unknowns, so the first iteration is a prototype rather than a finished feature. Building something real is the quickest way to find out what we don’t know, and with the tools we have today it is often cheaper than writing a detailed plan.

We review that prototype together with the stakeholder, a designer, the product manager and the engineer who built it. Seeing working software surfaces problems that a document never would. But the most useful review comes from customers, so we don’t wait until the end to ship. We deploy many times along the way, behind feature flags, and turn each iteration on for a small group of beta customers. Their feedback shapes the next loop, and each loop is short enough that nobody loses momentum.

Feature flags are what make this safe. Unfinished work can live in production without anyone else seeing it, we can switch something off in seconds if it misbehaves, and we learn how it holds up against real data and real usage long before launch.

As the feature settles, I finish the job properly: update the documentation, round out the tests, and add the monitoring that tells us how it is behaving in production. Doing the bulk of this once the shape is clear means we aren’t polishing work that changed three times along the way.

The final step isn’t really a deploy at all, because the code has been in production for weeks. It’s switching the flag on for everyone. Because the people who mattered, including real customers, have seen it at every step, there are very few surprises on launch day.

None of this is complicated, and that’s the point. A small team doesn’t need ceremonies to stay focussed. It needs a clear goal, the right people, short loops with real customers, and the freedom to build. That’s what keeps engineers motivated, and in my experience motivated engineers are what ship successful products.