By Victor Uzochukwu
The scale-up phase is where many organizations succeed or fail because they become weighed down by themselves. I’ve been working with tech companies across multiple stages over the last five years, including witnessing firsthand how what worked well enough to get a company to product-market fit is what ultimately holds those same companies back when they scale. The difference between those that succeed and those that fail often lies in one thing: their operating model.
There is a point in every scaling technology company where everything that worked before no longer does. Your company has moved from having ten to fifty engineers on staff. The codebase that you could understand is now more like a messy tapestry of dependencies. Features that took days to build now take weeks, and no one can quite say why. This is what they call a mid-stage inflection point, and it requires a complete rethink about how engineering work is organized.
Founders almost invariably attribute this slowdown to a talent gap and technical debt. They decide to hire more seasoned engineers on a wholesale level and/or embark on gigantic refactoring projects. The trouble is, this is more about technology company structure than technology company talent, and what they lack is an operating model. Without one, they default to chaos masquerading as agility. They do not need more hands or better technology, but a structure to govern how work is done.
From what I have learned building systems in both fintech and enterprise software, I have realized that there are 3 foundational building blocks to any scalable engineering organization: topology, decision architecture, and cadence. Get these right, and you build a strong organization that can scale without slowing down. Get these wrong, and you’ll spend your days putting out fires while your organization is growing.
Team topology is a topic about how you organize your engineering teams. The error that keeps being repeated is that businesses tend to structure these teams around technical layers. So you’ve got a frontend team, a backend team, and a DevOps team, and they’ve got to work together to accomplish something simple like a new feature. That adds communication costs that grow exponentially with the size of each team. The better approach is to structure teams around value streams and product domains.
This gives each team a significant part of the value chain and provides teams with every technical capability required to work on those aspects independent of each other. This is how I organized a significant part of a payment infrastructure company’s business to make payments work, including designing the API layer and database schema, and monitoring this layer, which allowed us to complete work independent of other teams.
The main point to remember is to reduce dependencies between teams and increase the clarity of ownership. As long as each team understands what they own and what they can decide upon related to their ownership, you can avoid these productivity killers called coordinations. The decision-making architecture defines both how decisions are made and by whom.
The structure is more straightforward in early-stage startups, where each technical decision is reviewed by either CTO or a couple of lead engineers. The approach is easy to implement if you have a staff of ten, but it can’t serve as a bottleneck when you have fifty employees. The remedy is not to refrain from making technical decisions but to involve multiple decision-makers.
The best method, I have observed, is to define decision ownership at varying organizational levels. The teams should have complete freedom to decide on implementation and technical matters within their territory. They can plan their test strategy, work on optimal database queries, and refactor their code without having to seek approval. The design decisions, which impact more than one team, require a separate mechanism.
This is where architectural decision records and technical design reviews come into play. We make sure to document our context, analyze our alternatives, and solicit feedback on any decision we make that imposes constraints on other teams. This is not about bureaucracy. This is about making things visible. This helps teams make better decisions within their limited constraints because they know what they can work with.
The rate at which you deliver software and verify its effect is called delivery cadence. I have worked in environments that have shipped continuously and those that have shipped quarterly. The difference in feedback loops is just stunning. Those organizations get to build better products not because they are faster but because they can learn faster.
To build such a cadence, there are three pieces that need to work together: automated testing to allow you to trust what you ship, infrastructure to make deployments easy and low-risk, and feedback to understand what is actually happening with your deployments. The company I am with currently practiced regression testing manually on each build we released, and we released every two weeks. We release multiple times a day with enough automation to cover regressions ahead of time.
However, cadence is not solely about technology. It is also about how you plan and sequence your work. The quarterly planning cadence is appropriate when you ship software on media. Today, it is simply a source of artificial batching and delayed feedback. For example, I have found that two- to four-week planning cycles result in higher alignment and allow more time to adapt to what you discover.
Let me elaborate on this with an example related to a growth challenge I worked on. The challenge for our company is to enter new regions, which entails handling different currencies, payment options, and regulations. The conventional method to solve this is to incorporate these into our system by developing functionality across our architecture. Rather, we developed a market expansion team consisting of full-stack engineers who completely owned the capability. They developed new API endpoints, added currency convert functionality, implemented regional payment processors, and developed admin tooling to support compliance processes. They could make fast decisions because they completely owned the capability.
This is how this particular team functioned with respect to decision rights. They enjoyed complete autonomy concerning their service design. They could decide what database technology to use, what design patterns to employ when implementing APIs, and how to deploy their service. They only required approval when making decisions about shared infrastructure resources and those that generated dependencies for other teams. They required design review approval to make any changes to our core user model to include regional information.
Their change frequency was a result of this independence. They shipped multiple deployments a day to a dedicated environment that allowed their services to operate independently. This ensured they could test new payment services within specific markets without any impact on their deployed services’ continuity. Automated tests ensured there were no regression issues introduced into their deployed environment, while flags helped roll out new features.
The impact is that we were able to enter three new markets within six months, which wouldn’t have been possible within our old structure. More importantly, this experience influenced how we reshaped other parts of our engineering organization.
The biggest issue organizations are having is treating their operating model like a static plan, rather than a dynamic system that is constantly moving with their business. A plan that worked for fifty engineers is completely different than two hundred. The biggest thing is to assess if you are getting what you want out of your structure, and make organizational changes when you aren’t.
Another is to emulate best practices from successful technology businesses without understanding what makes them succeed. The Spotify squad is referenced everywhere, but this capability is largely misunderstood because it relies on having very strong architectural segregation and an autonomy culture, which is not replicated successfully very often.
A scalable software organization is not something that results from adopting a certain structure or tooling structure, but something that requires care and thoughtfulness concerning how you organize your teams, how you distribute decision rights, and how you build your cadences to achieve sustainable momentum. The organizations that succeed during this transition phase are those which realize that organizational design is equally important to technical architecture. They spend time building clarity on ownership and decision rights.
They build infrastructure to make software deliveries safe and frequent. The most important thing that I have learned during these last five years of being an engineer is that scaling technology is essentially scaling human coordination. The best operating model is one that doesn’t prescribe how engineers work but takes out the friction that keeps great engineers from being their best. That is what every scalable technology company is built upon.
