Scaling With Intention: Why Overgrowth Is the Enemy of Engineering Success

The world of technology has always been fast-paced, but in the race to scale and grow, many companies have veered off course. Instead of focusing on value, they’ve succumbed to unnecessary bloat—both in structure and processes. It’s not uncommon to see organisations hiring for titles like Senior Head of Engineering or VP of Engineering when their core engineering challenges haven’t evolved enough to justify these roles. And this isn’t just frustrating—it’s damaging. Flat structures, collaboration, and a focus on MVPs (Minimum Viable Products) have proven time and again to be the bedrock of innovation and efficiency. So why is it that we keep adding layers of unnecessary complexity?

The Beauty of Flat Structures

Once upon a time, engineering teams were lean, focused, and collaborative. Titles mattered less, hierarchies were flatter, and work moved faster. Flat structures inherently encourage a sense of ownership across the team. When everyone has a clear role without layers of bureaucracy, decisions get made quicker, communication flows seamlessly, and innovation happens naturally.

I’ve seen this firsthand in my career, particularly in my early days at On the Beach. At its inception, the engineering structure was flat, with engineers working directly with stakeholders to deliver value. The hierarchy was minimal: 4 or so engineers in a team, led by a Senior engineer for the first 2 years or so. Then a Tech Lead, eventually some Principal engineers, and then the Head of Engineering. Over time, as the company grew and needs evolved, roles like Technical Lead and Engineering Manager were swapped in or introduced—but only when they solved a real pain point.

Contrast this to what we see today: bloated organisational charts full of specialised roles that don’t truly align with the company’s stage or objectives. Instead of empowering teams, these roles slow them down, leading to decision paralysis and turf wars over who owns what. Collaboration suffers, and the focus shifts from delivering value to navigating hierarchy.

The Overengineering Trap

Overengineering has become the unfortunate hallmark of many modern tech teams. Rather than focusing on delivering MVPs to validate ideas and iterate quickly, many teams spend months perfecting solutions to problems that may not even exist. Engineers are caught up in “solutionising,” trying to build platforms and tools that anticipate every possible edge case instead of delivering something small, simple, and functional.

This is where the concept of “definition of done” comes in. Teams that prioritise delivering MVPs—things that are "good enough" to go live and gather feedback—are the ones that succeed in the long run. They test ideas, fail fast, and iterate. It’s efficient and customer-focused.

And yet, I see so many companies chasing the allure of “perfect.” The reality is that perfection is subjective and often comes at the expense of speed, agility, and cost. If teams spent less time overthinking and more time collaborating on getting value out the door, they’d not only save resources but also build better products for their users.

The Danger of Blindly Following the Books

Don’t get me wrong—frameworks and methodologies like Team Topologies are incredibly useful. They offer perspectives that can help align teams and improve delivery. But here’s the problem: frameworks are just that—frameworks. They’re not gospel.

Take Team Topologies as an example. The framework introduces concepts like stream-aligned teams, platform teams, and enabling teams—all of which can be invaluable when applied correctly. But they can also be over-applied, leading to unnecessary complexity. I’ve seen businesses create platform teams far too early, burning resources on tools and processes they didn’t need instead of focusing on delivering value to customers. These teams then become a burden rather than a benefit.

What’s missing is commercial awareness. Leaders need to ask themselves: What does my business need right now? What pain points am I solving? The answer might not involve platform teams or stream-aligned teams—it might simply be a group of motivated engineers collaborating on an MVP. Books are great for inspiration, but they’re not a substitute for critical thinking.

The Consequences of Scaling Without Purpose

The tech industry is paying the price for its obsession with rapid scaling. In recent years, we’ve seen waves of redundancies as companies that over-hired and over-built have realised they can’t sustain their bloated structures (TechCrunch, The Verge). It’s heartbreaking to see talented people lose their jobs because their organisations prioritised growth at all costs.

This overscaling has also led to a glut of misaligned talent in the market. For example, a CTO at a startup might have been little more than a Lead Engineer in practice, but now they’re competing for CTO roles at larger organisations—roles they’re unprepared for. It’s not their fault; the industry has created this misalignment by pushing people into titles and responsibilities they’re not ready for.

The solution is clear: scale intentionally. Hire for roles when they solve a specific problem, not just because it looks good on an org chart. Build teams around value delivery, not theoretical frameworks. And, most importantly, remember that growth is only meaningful when it’s sustainable.

What We Can Learn From DHH

If there’s one person the industry should pay more attention to, it’s David Heinemeier Hansson (DHH). His approach to scaling is refreshingly pragmatic: hire only when you feel genuine pain. No fluff, no vanity roles—just a focus on solving problems as they arise.

DHH’s philosophy is rooted in the idea that less is more. By keeping teams small and nimble, you encourage collaboration and ownership. By avoiding unnecessary hires, you reduce overhead and maintain agility. It’s not about avoiding growth altogether—it’s about growing with purpose.

Imagine if more companies embraced this mindset. Instead of chasing headcount and titles, they’d focus on delivering value, iterating quickly, and staying lean. They’d avoid the painful layoffs we’re seeing today and create environments where people can thrive. Imagine the innovation that would follow on the back of this.

Scaling With Intent

The path forward is clear. We need to move away from the culture of overengineering, overbuilding, and overhiring. Flat structures, collaboration, and MVPs should be the norm, not the exception. Leaders need to approach frameworks like Team Topologies with caution, applying them thoughtfully rather than dogmatically. And we need to look to examples like DHH to remind us that growth only matters when it’s sustainable.

The next time you’re tempted to add a new role, build a new process, or scale your team, ask yourself: What pain am I solving? If the answer isn’t clear, it might be time to take a step back. After all, the best engineering teams aren’t the ones with the fanciest titles or the most complex processes—they’re the ones that deliver value, day in and day out.