Software Engineering Excellence. Part 2. Scaling Excellence Across Teams and Projects

When founders approach us with a pressing need to rapidly expand their engineering teams (especially after fresh fundraising) - it raises immediate concerns. Through our experience guiding numerous companies during their scaling phases, we've noticed a common pattern. Unfortunately, many companies don't just do it wrong slightly - they often stumble significantly.

Following the publication of our previous article on engineering excellence, we engaged in discussions about the complexities of scaling it. It's apparent that as companies grow, the engineering challenges we highlighted become even harder to manage and the pace of everything goes up, so there is no time to think slow. Scaling isn't merely about increasing the number of team members or adopting the latest technologies or best practices; it is also about the right pace and continuous monitoring.

Take, for example, a payment processing company we were working with recently. They expanded their engineering team from 4 to 24 engineers in just eight months, which was a challenge on its own to hire and onboard that number of people. Of course, it looked good on paper… However, in 6 months’ time, their deployment process required 3 days of preparation. Daily stand-ups evolved into hour-long debugging sessions, and they saw the departure of 3 key engineers (the money spent on hiring and onboarding just lost). Their CEO repeatedly asked: why does progress slow down as the team grows? And no one was able to clearly answer, so they invited us to help.

A deeper look revealed familiar issues. The team hastily adopted microservices because they believed "that's what scaling companies do." They implemented Kafka without having real-time processing needs. Each service became isolated, managed by its own team, and every team had a sense of ownership, but unfortunately no one cared too much about “the whole”. So they decided to create an architecture committee, and it was a good idea in general, but technical decisions now required approval from the committee, and created even more challenges.

On the other side of the spectrum, we've seen companies navigate the growth phase successfully. One of our B2B clients chose a different approach. Rather than prematurely splitting their codebase, they concentrated on establishing clear boundaries within their existing monolithic architecture. They defined robust API contracts between components. When the time came to separate services, the transition was smooth and without unnecessary complications.

Their success was no accident. They also invested early in developer tools, ensuring that every new engineer could deploy code in their first week. They kept a simple yet well-defined architecture that was easy to maintain. In other words, they avoided adding complexity solely because of their growth.

We’ve seen numerous scaling efforts, and with many, we were part of the journey, so we've identified a few regular patterns. From what we can say, teams that thrive typically excel in three fundamental areas. These are logical code organization (and architecture), extensive automation (including testing and deployments), and transparent decision-making (this is the hardest part). Lacking any of these can make growth a painful experience.

The organization of code is more critical than many realize. An eCommerce platform we collaborate with treated the modules within their monolithic backend as if they were separate services from the beginning. They established clean APIs, defined clear ownership, and enforced proper boundaries, but at the same time they kept all their backend code within a single deployable unit. This approach provided the advantages of service boundaries without the operational challenges associated with distributed systems.

Automation becomes a huge advantage at scale, but ideally it should be started earlier on, and the basic foundation should be there before scaling. Manual processes that suffice for a team of 5 can become detrimental when the team grows to 20. We advised the same eCommerce client to include deployment automation and autotesting foundations (in a very thoughtful way) not because it was fashionable, but out of necessity. Their deployment pipeline caught obvious mistakes before code reviews, and new engineers could set up their development environments without going through a long (and usually outdated) setup guide.

Recently, we observed a marketplace client struggle with technical decision-making at scale. Every architectural choice led to week-long debates. We helped them implement a straightforward guideline. Every technical proposal needed to address three questions: 1) What business problem does it solve? 2) What is the maintenance cost? 3) Can this decision be postponed? This simple framework reduced their architecture meetings by half and eventually accelerated feature delivery significantly.

Data often tells an informative story. We usually recommend our clients monitor deployment frequency as one of the core metrics. Following our advice, a client monitored their deployment frequency before and after migrating to microservices (though they insisted on the migration against our advice). The results were telling - their supposedly "more scalable" architecture actually slowed feature delivery in a big way. We've seen this trend recur so frequently that it's almost predictable. Again, we are not advising against microservices, we are just trying to help to do it with smaller steps and at the right time.

We always recommend keeping an eye on metrics to detect scaling issues early. A decline in deployment frequency, pull requests remaining open longer, and an increasing bug count are all early warning signs. By the time team morale starts to dip, the problems have likely become big enough.

We recently assisted a payment processing company in turning things around. The solution didn't involve adding more processes or adopting new tools. Instead, they consolidated services, streamlined their event architecture, and clarified ownership roles. Within two months, they returned to daily deployments. Sometimes, the most effective scaling strategy is to reduce complexity rather than introduce more complexity.

The human aspects of scaling, such as culture, communication, and team dynamics are all extremely important and deserve a dedicated discussion, which we'll address in our next article. However, it's essential to first ensure that the technical foundation is solid.

Through our experiences with technology choices during periods of scaling, we've learned that simplicity often guarantees the best results. Successful scaling rarely requires cutting-edge technology. It requires clear boundaries, robust automation, and a pragmatic approach to technical decisions.

The most successful scaling stories we've witnessed share a common theme - they maintain simplicity for as long as possible. They don't introduce excessive processes merely because of growth. They promote independence without fostering silos. They keep the primary goal in focus - not to build the most complex system, but to deliver business value efficiently on a larger scale (and faster pace).

From observing numerous scaling attempts, one thing is clear - the fundamentals cannot be overlooked. It's impossible to compensate for poor architecture with additional processes. Adding complexity won't resolve team growth challenges. Often, the best decisions in scaling are those that avoid unnecessary complications.