17 months ago, our Product Engineering team could fit around a single table.
Everyone knew what everyone else was working on. Questions were answered instantly, and decisions spread naturally through conversations. If someone learned something useful in the morning, the rest of the team usually knew by the afternoon. It was fast, simple, and it worked.
In less than 18 months, our team grew from 4 engineers to 21. The interesting part isn't that the team grew, plenty of organisations hired quickly. The interesting part was discovering that many of the things that made us fast at 4 engineers didn't work as effectively at 21. Not because they were wrong, but because we had outgrown them.
When I say "what made us fast", I don't just mean delivery speed. It was shared context, strong ownership, rapid decision-making, close collaboration, and a culture where people genuinely helped each other succeed.
The challenge wasn't simply just about scaling the team, but scaling those qualities alongside it.
We didn't want to scale blindly. As the organisation grew, we became more deliberate about measuring what good looked like. Today, Product Engineering teams at Easygo track a common set of engineering metrics, including the availability of critical customer journeys, planned work versus delivered work, and the completion of post-incident review actions within agreed timeframes. These metrics give us a shared view of engineering health and helped us maintain delivery predictability, reliability, and engineering quality even as the team grew by more than 5x.
Scaling Knowledge Without Losing Speed
More than 70% of our current engineering team joined during this rapid growth period. That made knowledge sharing one of the most important scaling challenges we had to solve.
One of the first signs appeared during a quarterly feedback conversation with a newer engineer. When I asked what had helped them most since joining, their answer was simple:
"Having everyone around me always able to answer my questions and guide me in the right direction."
When I asked what had been most challenging, it wasn't the codebase or the technology. It was everything around it: understanding our deployment processes, learning how code moves through reviews, navigating internal tools and systems, getting up to speed with the realities of operating products like Stake and Kick across multiple jurisdictions and rapidly expanding into new global markets.
The code was easy but the context wasn’t.
That feedback captured something we had already started feeling. When we were smaller, knowledge spread naturally. You overheard conversations, sat near someone who knew the answer, and learned through proximity. But with the team growing, the proximity stopped scaling. Questions took longer to answer, lessons learned by one team weren't always visible to another, and new engineers needed context that no longer spread organically.
The challenge was no longer just helping engineers understand the software. It was helping them understand the organisation.
We responded by investing more heavily in structured onboarding, better documentation, knowledge-sharing sessions, and clearer learning pathways. The goal wasn’t just to help new engineers ramp up faster. It was to ensure that knowledge could continue to scale as quickly as the team.
We also became more intentional about how engineers learned from each other. At the team level, we introduced regular Tech Huddles where engineers could share technical discoveries, discuss design approaches, unblock challenges, and learn from one another. As the organisation grew, we extended that idea through Engineering Guilds. These forums bring engineers together across teams to share lessons learned, showcase new tools and technologies, discuss common challenges, and learn from work happening elsewhere in the organisation.
What started as a simple knowledge-sharing practice became an important part of maintaining shared context and spreading ideas across the organisation.
Scaling Ownership Without Creating Silos
As the team grew, ownership became both more important and more complicated.
When we were smaller, responsibilities were usually obvious. Everyone knew who was working on what, who to ask for help, and who was responsible for making decisions. As more engineers joined and the organisation expanded, that clarity no longer happened automatically. At the same time, we wanted to avoid another common trap:
One principle I've found myself repeating often is:
Every person has a home, but nobody has a boundary.
Everyone should have clear ownership and accountability. But ownership should never limit curiosity, collaboration, or impact.
The principle quickly became visible in how teams worked. Engineers regularly contributed beyond their immediate area of ownership. Senior engineers mentored across squads, reviewed cross-team pull requests, contributed to others’ solution designs and Request for Comments (RFCs), and shared their expertise wherever it was needed. Engineers improved onboarding experiences for future hires, updated on-call runbooks and playbooks based on operational learnings, and refined technical documentation to make life easier for the next person.
What stood out was that people weren't doing these things because they were asked to. They did them because they cared about making the team better. Ownership became clearer, but collaboration became broader.
We also recognised that culture doesn't scale by accident. Every six months, we bring our teams together to reflect on achievements, share lessons learned, hear perspectives from key stakeholders, and align on priorities for the next chapter. As the team grew, these moments became increasingly important for maintaining shared context, strengthening relationships, and ensuring we continued moving in the same direction.
One lesson that surprised us was that alignment doesn't slow teams down. In fact, as organisations grow, alignment becomes one of the key enablers of speed. At 4 engineers, alignment happened naturally through conversation. At 21 engineers, we had to become much more intentional about creating it. Because as organisations scale, speed doesn't come from everyone doing their own thing. It comes from many teams making good decisions independently while remaining aligned on a common purpose.
Looking Back
Looking back, this wasn't just a story about headcount growth. More than 70% of the team joined during this period, yet we continued to deliver key product initiatives, support global market expansion, and invest in engineering maturity.
More importantly, we saw engineers step into technical leadership roles, knowledge flow more effectively across teams, and ownership remained strong even as responsibilities became more distributed.
That's the outcome I'm most proud of. Not that we grew from 4 engineers to 21, but that we grew without losing the qualities that made us fast in the first place: shared context, strong ownership, rapid decision-making, collaboration, and a culture where people genuinely help each other succeed.
The goal was never simply to build a bigger engineering team. It was to create an environment where talented people can learn quickly, take ownership, and continue growing together. Because scaling isn't really about growing teams. It's about helping more people do their best work together.
