The business is growing, and your engineering team is too. Great news - until the sprawl sets in. How can your teams and processes scale with consistency and maturity?

In a previous role, I inherited a fragmented system written in five different languages, both monolith and microservices; and years of inconsistent tech choices including areas of the system that had been completely neglected.

Whilst there were bottlenecks between the teams, the individual team performance ranged from moderate to good - so it was important not to be disruptive to the current ways of working of those productive teams with top-down mandates or heavy-handed governance that teams would try to circumvent or avoid. It felt like every team was solving the same problems differently - and sometimes unknowingly repeating each other's mistakes.

In this post I cover my experiences introducing lightweight governance, ensuring consistent architecture, and deprecating legacy systems without stalling team velocity.

Architectural Consistency Through Standards, Not Mandates

With an inherited system lacking process and documentation, there's no time like the present to start righting some of the wrongs.

One of the common issues we came across was that we often didn't understand why a particular technical choice had been made. So we began by documenting any new decisions in an Architecture Decision Record. These ADRs captured any significant architectural decisions made, including the context and consequences of those decisions. These could later be referred to by developers in other teams - or our successors - so they can understand the reasoning for different approaches and decisions.

I also brought developers together to review the current architecture and focus on patterns we'd like to use to improve future work. Given the varied tech stack, enforcing tools wasn’t feasible. But we could standardise how we build, test and deploy to make it easier for developers to switch between teams and reduce the debate when building new systems by aligning our new solutions to choices that aligned with our principles.

Legacy-Innovation Balance via Strategic Modernization

With a growing business, it's inevitable that technical debt will start to build up and some areas of your product will become legacy systems. Legacy systems aren’t always bad - but unexamined legacy is risky. We evaluated each system: should it be retired, kept or re-written?

Event storming exercises allowed us to understand the key concepts of legacy systems and helped clarify business rules. Understanding what the priorities are with legacy systems will help you understand how to approach the problem.

The strangler fig pattern let us replace functionality incrementally by wrapping legacy systems with a facade layer. Once all functionality is moved, you can retire the old system completely. With this pattern you never have a "big bang" replacement that could break everything and you can validate the new architecture with small pieces before committing fully. If issues do arise, you can easily rollback and redirect traffic back to the legacy system.

Governance That Accelerates Rather Than Gates

It is difficult to introduce new governance methodologies to teams without resistance.

It's important to bring the team on the journey to maturity and help them understand why these processes need to be introduced. Rather than leading with "we need governance", start conversations around the problems your developers are already experiencing. "We keep having to fix the same security issues across teams" or "onboarding new developers takes forever because nothing is documented" resonates more than abstract governance concepts.

Getting the team involved in how they can be implemented can also help. Forming working groups where senior developers from different teams help design the standards with their collective wisdom will lead to better buy-in. When people help create the rules, they're more likely to follow them, and they can help evangelize them to their teams.

Teamwork makes the dreamwork!

• Shift-left practices such as including static analysis security scanning and basic compliance checks in pull request and deployment CI/CD workflows can help introduce governance early into your processes, and are something the team will quickly get used to as part of their everyday.
• Infrastructure as Code can help bring in and keep these additions consistent - we created deployment templates with security scanning built-in, making the secure path the easy path.
• Providing self-service platforms with the right guardrails and minimal friction can help in other areas, like setting up new repositories or managing production access.
• Keep approvals lightweight so you meet your auditing requirements without blocking the velocity of the team.

The goal for governance should be to make the secure, scalable golden path the easy one.

Measuring Outcomes

Like all parts of software development, it's important to measure the impact of the processes you put in place rather than the adherence and compliance to the process.

As well as measuring the maturity of your system and processes, measure how your development experience has changed. Some metrics to consider include: deployment frequency, lead time for changes, or incidents caused by architectural inconsistencies.

Are things getting better? If not, iterate.

Summary

As a CTO, you're responsible for guiding the platform to scale sustainably - without slowing the team down.

It's important to focus on practical, proven approaches like the ones described in this article to help you move the system forward, and ensure the team are invested in achieving the results you need.

Don't try to fix it all at once - start small. Introduce lightweight governance, document decisions and build the golden path that teams will want to follow. Start with one visible win such as documenting architectural decisions or adding security scanning to CI/CD, then measure impact before expanding governance practices to other areas. By maturing your systems gradually, your team will scale with it.

Where could you introduce clarity without friction this quarter?