When we started Fluxon, we weren’t trying to build a better version of a traditional development firm. We thought the model was optimized for the wrong thing.
From my time at Google, I’d seen how external dev teams were often put together. The commercial incentive was larger teams and longer engagements. This didn’t always mean more progress.
On one team I worked with, there was an engineer who was exceptional. He was the person closing out most of the bugs and getting the hardest things shipped. When work landed elsewhere on the team, the quality dropped. There was no shortage of people, but adding more headcount didn’t produce a better result.
A client isn’t really buying engineering hours. They’re buying outcomes: a product launched, a technical problem solved, a new capability brought to market. We believed the team should follow that outcome, not the other way around. A small team of highly capable people can often accomplish far more than a much larger team.
That idea became Fluxon.
Find the smallest, strongest team for the job
Small only works if the people are exceptional. We put a huge amount of effort into finding the best talent we can, because that’s what makes smaller teams possible without compromising on capability. The bar for each person is high. They need to make decisions, embed in the product and take ownership beyond their part of the codebase. Some problems need large teams. Others don’t. We've found that hard product problems are often solved faster by a few excellent people because there are less handoffs and coordination.
Keep the people doing the work close to the problem
Our teams work directly with clients in their stack, their standards and their Slack. There aren’t layers between the people making decisions and the people building the product. Questions get answered faster. Context gets lost less often. Engineers can understand why something matters, not just what they’ve been asked to build.
Give the advice we’d want to receive
Sometimes a client comes to us asking for a large team. If we think a smaller one can do the job, we’ll say so. The same applies to the software itself. Sometimes the better answer is to build less. Sometimes it is to solve an architecture problem before adding more features. That may mean less work for us in the short term. We’re comfortable with that. But it creates better products, stronger partnerships, and teams that can move much faster.
The longer we’ve done this, the more convinced I am that headcount is a poor proxy for progress. Often, the best team for the job is smaller than people expect. Our job is to be honest about that. Hire the best talent, build the team around the outcome, and keep everything else as simple as possible.
