Some ideas only make sense after you have lived through them.
When we founded Software Planet Group back in 2000, we made a decision that, at the time, looked almost naive. We chose not to build teams around narrow roles. No strict separation into frontend, backend, database engineers or QA as isolated functions.
Instead, we built our process around a simple unit: a user story.
One engineer – one user story – full responsibility from start to finish.
At the time, this was not a trend. It was just the most practical way to deliver working software without losing control over the result.
Years later, we came across a similar line of thinking in Peter Thiel’s reflections on technological stagnation. His argument is broader, but one point stands out. Progress slows down when systems become too specialised, when knowledge is fragmented, and when no one is able to connect the dots.
We had seen the same pattern in software development long before it became a topic of discussion.
When Delivery Breaks Down
Modern development processes often look efficient on paper. Roles are clearly defined. Responsibilities are separated. Each specialist focuses on their area.
In reality, this creates a different kind of problem.
A single user story moves through multiple hands. Frontend, backend, database, QA, DevOps. Each step introduces a delay. Each transition creates a gap in understanding. Responsibility becomes distributed, and with that, diluted.
No one owns the outcome. Everyone owns a part of the process.
The result is predictable. Longer delivery cycles. More defects at the boundaries. Higher cost of change. And most importantly, a constant loss of context.
At scale, this is not just inefficient. It becomes a structural limitation.
The Generalist as a Unit of Delivery
In our model, the unit of delivery is not a task or a role. It is a completed user story.
A generalist is not someone who knows a bit of everything. That definition is weak and misleading.
A generalist is an engineer who can take a functional requirement and carry it all the way to production.
They understand the business intent behind the story. They implement changes across the UI, API and data layers. They validate the result. They take responsibility for quality. And they make decisions along the way.
This changes the dynamics completely.
There are fewer handoffs. Less coordination overhead. Faster feedback loops. And a clear sense of ownership.
What you gain is not just speed. You gain control.
Why This Matters More Today Than Before
Over the past decade, the cost of building software has changed.
Teams are more expensive. Systems are more complex. The cost of mistakes has increased. At the same time, businesses have become more cautious. They are less willing to experiment blindly and more focused on predictable delivery.
In this environment, inefficiency is no longer tolerable.
Traditional role-based teams scale by adding people. But they also scale coordination complexity. More roles mean more communication, more dependencies, more delays.
You end up paying for multiple layers of effort to deliver a single outcome.
A generalist model scales differently. It reduces coordination instead of expanding it. It aligns effort with outcome. It keeps the system manageable even as it grows.
For a business, this translates directly into cost, speed and predictability.
The Shift Introduced by AI
There is a common assumption that AI will replace developers. In practice, it does something else.
AI reduces the cost of writing code. But it does not reduce the cost of deciding what to build, how to structure it, or how to evaluate the result.
In fragmented teams, AI often amplifies existing inefficiencies. Faster code generation does not fix poor coordination or unclear ownership.
In a generalist model, the effect is different.
The engineer becomes a coordinator of the solution. They define the task, guide the implementation, validate the output and adjust direction when needed.
You can think of it as moving from writing code to directing how the code is created.
AI becomes a force multiplier, not a replacement.
But this only works when the person using it has end-to-end visibility and responsibility.
Not a Trend, but a Deliberate Choice
For us, this is not a new direction shaped by recent trends. It is how we have been working since the beginning.
Our teams are built around full-stack engineers. Our process is driven by user stories. Responsibility is always end-to-end. Practices like Test-Driven Development, Behaviour-Driven Development and pair programming are not optional additions. They are part of the system that makes this model work.
This approach reflects a simple principle.
Software development should be organised around delivering results, not managing roles.
Where This Leads
As systems become more complex and the pressure on delivery increases, the gap between these two models becomes more visible.
You can continue to optimise individual parts of the process and hope the system improves as a whole.
Or you can redesign the unit of delivery itself.
In our experience, the second option is the only one that scales without losing control.
If this way of thinking resonates with you, it is worth discussing how it can be applied to your product and your team.
