5 Sep 2025 · Software Engineering · 4 min read

    The Secrets to Scaling Engineering Teams (Lessons from Rails, Unity & WeTransfer)

    Contents

    In 2025, scaling engineering teams has become a defining challenge for leaders. Budgets are tighter, delivery expectations are higher, and organizations can’t afford brittle processes or bloated teams. The strongest companies are learning that scale doesn’t come from headcount alone, but from focus, predictable delivery, and shared responsibility.

    On the Semaphore Uncut podcast, I’ve heard directly from leaders who’ve faced this challenge. David Heinemeier Hansson (creator of Ruby on Rails and CTO of 37signals), Alan Page (former VP of Engineering Services at Unity), and Antoine van der Lee (former Lead iOS Engineer at WeTransfer, now founder of RocketSim) all shared lessons on how to scale engineering teams without losing speed or resilience.

    Here are the secrets they revealed.

    Small Teams, Big Results

    David Heinemeier Hansson has long been skeptical of the “grow at all costs” model. When he and his team built Basecamp, they were just four people, and Ruby on Rails was born out of that lean effort. For him, scaling is about focus, not headcount.

    “Building a great product does not demand having a huge team, infrastructure, or capital.” — David Heinemeier Hansson, Semaphore Uncut

    Instead of chasing venture capital and large teams, David argues that smaller, focused groups often move faster and build better products. His story is a reminder that scaling engineering teams is about doing more with less.

    Quality Belongs to Everyone

    Alan Page has seen testing evolve from long, isolated phases to being integrated into daily work. At Unity, his philosophy was clear: testing should accelerate delivery, not slow it down.

    “These days, testing is truly about accelerating the business and making things move faster.” — Alan Page, Semaphore Uncut

    For Alan, scaling engineering teams means ensuring quality is everyone’s job. Developers own functional correctness, while testers add value in complex scenarios. By embedding testing into CI/CD pipelines, teams can ship faster and with fewer surprises. That cultural shift is what allows teams to grow without creating bottlenecks.

    Release Discipline Creates Confidence

    During his time at WeTransfer, Antoine van der Lee introduced a release train: shipping every Monday without exception. Supported by CI/CD automation, this took the stress out of scaling delivery.

    “Everybody on the team knows that every Monday there’s a new release coming, and we don’t have to think about releasing anymore.” — Antoine van der Lee, Semaphore Uncut

    This steady rhythm created predictability, reduced crunch time, and gave the team confidence. Antoine also built an open-source CI/CD boilerplate that standardized automation across projects, cutting down on maintenance overhead. For growing teams, this kind of discipline is what makes scaling sustainable.

    Lessons for Today’s Teams

    The stories from Rails, Unity, and WeTransfer highlight different paths to the same destination: scalable, resilient engineering teams. David shows that staying small avoids unnecessary complexity. Alan shows that embedding quality into everyday work enables speed at scale. Antoine shows that disciplined release practices give teams the confidence to ship regularly without stress.

    For leaders, these lessons highlight something concrete: scaling engineering teams isn’t about headcount or hype—it’s about the daily practices that help teams adapt and thrive.

    Listen to More on Semaphore Uncut

    These insights are drawn from conversations on the Semaphore Uncut podcast, where I sit down with engineering leaders to explore how they build and scale successful teams.

    🎧 Hear the full conversations with David Heinemeier HanssonAlan Page, and Antoine van der Lee.

    Final Thought

    Scaling engineering teams in 2025 is about more than adding people. It’s about building habits that create focus, embed quality, and keep delivery predictable. Those are the choices that let teams grow without breaking.

    Thanks for reading. I’d love to hear your thoughts—let’s connect on Twitter/X or at darkofabijan.com

    Want to discuss this article? Join our Discord.

    mm
    Writen by:
    Star us on GitHub