Scaling up is the part we usually know how to talk about. We add teams. We create ownership boundaries. We introduce platform work. We separate systems so people can move faster without stepping on each other every day. For a while, our architecture and our organization were moving in that same direction. Before 2015, we were around 56 developers. We had enough people, enough product areas, and enough specialization for more separation to feel natural.
The product areas had different realities. Payments had its own. Mailer had its own. Media buying and media traffic had theirs. Paysites was more complicated because several teams worked inside the same product space and often shared the same codebase, but even there the shape was understandable. We had a platform team responsible for the core of the paysite system, and other teams were expected to build on top of that foundation.
It was not perfect. The platform team had to convince other teams to follow its direction, and the teams closest to stakeholders sometimes had reasons to push around the boundaries. Stakeholders would ask for features that overlapped, conflicted, or solved the same problem without knowing someone else had made a similar request. We tried architecture meetings. We tried champions. We tried to create the conversations that would keep the system coherent. Some of it worked, but the flow was never smooth because ownership was never as clear as the org chart made it look.
Looking back, the ideas in Team Topologies give useful language for what we were living. Some teams were stream-aligned around a product area. The platform team was trying to reduce cognitive load by giving the other teams a common foundation. In theory, that should have helped. In practice, the interaction mode was often negotiation instead of enablement. The platform team could look like a blocker when it pushed for consistency, and product teams could look undisciplined when they pushed for local speed. Both readings were too simple. The real issue was that the architecture and team boundaries were still being discovered while the business kept moving.
Then the company had to scale down. The financial reality changed, and the organization had to reduce its size. We went from around 56 developers before 2015 to around 40 in 2016. The funny part, if there is a funny part, is that systems do not disappear when teams do. Their roadmaps may slow down, their owners may change, but the production systems are still there. They still need bug fixes, deployments, runtime upgrades, support, and someone who remembers why a decision was made.
We restructured. Payments and media traffic kept their responsibilities, but the paysite group inherited several other systems. Four development teams became two, and the platform team stayed for a while. Conversation became easier because there were fewer teams, but another change mattered just as much: the stakeholder structure changed. A PMO started filtering and centralizing requests. That did not solve everything, but it reduced competing requests and gave us a clearer way to measure what mattered. For a few years, the model worked well enough.
Then came another restructuring, this time around 2020. We downsized again, moving closer to 30 developers. The bigger change was in how requests reached the teams. The business felt the process had become too complex, so the PMO disappeared and the business units moved closer to the development teams. The platform team also disappeared. We were left with two paysite teams and a payment team, while still carrying the systems that had accumulated over time. The organization had become smaller and flatter, but the technical surface area had not shrunk with it.
That was the mismatch. The architecture stayed distributed. The organization did not.
Just before that period, we had decided to move more seriously toward service-oriented architecture. We had started breaking pieces out of the monolith into services, first with Slim, then more and more through AWS, API Gateway, and Lambda. At the time, the decision looked reasonable. Services gave us clearer deployment surfaces. They let different teams own different parts of the system. They helped us separate responsibilities that were tangled in the monolith. For the size and ambition of the organization we had then, the direction made sense.
But after the organization changed, the same direction created a different kind of cost. The pace of extraction slowed almost to zero. New features kept coming in, and each time we had to decide whether to build in the cloud service world or in the old monolith because part of the capability still lived there. One team was working mostly with the newer services. Another team was still mostly in the monolith. We tried to share knowledge several times, but knowledge that is not used does not stay fresh. People forgot what had been taught because they did not work in those systems often enough, and that created frustration on both sides.
That is when I started to see the flaw more clearly. It was not that services were bad. It was that our service strategy assumed a team shape we no longer had. Microservices need owners. They need operational capacity. They need people who understand deployments, observability, runtime upgrades, security expectations, incident response, and the business context around each service. When the team is large enough, that cost can be worth it. When the team gets smaller, the same cost becomes cognitive load spread across fewer people.
Today that pressure is even clearer. In 2026, the engineering organization is closer to 20 developers, and the paysite team is much smaller than it used to be. The number of systems has not dropped at the same rate. Some APIs are now legacy. Some need runtime upgrades before they can be deployed safely again. We still have to deliver features, but we also carry the maintenance bill for every service we created when the organization had more capacity. The work did not become less important just because fewer people remained to do it.
A lot of the work becomes a form of controlled degradation. You do not get to redesign everything. You stabilize what must stay alive. You simplify when you are already touching a part of the system. You accept that some pieces will not improve this quarter, or maybe this year, because the business still needs delivery and the team still has a finite amount of attention. That is not the architecture story people usually want to tell, but it is a common one in long-lived systems.
I do not think the right lesson is "never split the monolith." That is too easy. Some services were the right move. Some boundaries were real. Some parts of the system benefited from being deployed independently. The lesson is closer to this: a service boundary is not only a code boundary. It is a promise that the organization will keep enough ownership, attention, and operational maturity around that boundary for as long as the service exists.
If I could replay the decision, I would probably keep the monolith longer and make its internal boundaries clearer. Not as an excuse to keep everything tangled, but as a deliberate modular monolith with stronger ownership rules. We could have defined which teams owned which vertical slices, who could change shared parts, when a platform decision had to be followed, and how cross-cutting work should be negotiated. That would not have removed stakeholder complexity, but it might have made the cost of future downsizing lower.
I made a similar parallel after listening to The Manager's Path. The structure that works when you have many teams, engineering managers, managers of managers, a director, and a CTO is not the same structure that works when the group gets smaller. Management layers are not automatically waste. At scale, they create alignment, develop people, manage performance, and keep engineering standards from drifting. But when the organization shrinks, the same layers and boundaries can become too heavy for the amount of work and decision-making that remains.
Scaling down is not just removing boxes from an org chart. It changes the architecture you can afford. It changes how much specialization is healthy. It changes whether a platform team is a force multiplier or a luxury. It changes whether teams should own services independently or whether they should share a clearer, smaller system with stronger conventions. We often plan for growth because growth feels like the success case. We spend less time asking what happens if the company becomes smaller while the architecture keeps the shape of the larger company.
We felt that again when we started discussing a future structure with an enablement team. We had two senior developers with deep system knowledge, and the idea was to move them into a role where they could share that knowledge across teams instead of remaining single points of failure inside one team. That idea made sense while we were expecting to scale up again. In 2025, we were acquired, and another team was supposed to start working with us. For a while, we planned for growth. In the end, we had to scale down instead.
For the last few months, I have been wondering if the rise of agentic AI changes that calculation. If services are smaller and better isolated, maybe AI can work with them more easily. A narrow repository with clear tests and clear ownership is easier for both humans and agents to reason about. But AI does not remove topology costs. It changes where those costs show up. If a small team has to guide AI across too many services, too many deployment flows, and too many runtime differences, the cognitive load moves into planning, prompting, reviewing, and governing the work. AI may write more of the code, but someone still has to understand the system well enough to decide whether the result belongs there.
I can imagine smaller teams becoming more effective with AI. I have seen people describe a model with one product-minded business person, two strong developers, and a good delivery pipeline, and I can see how that could work in some contexts. I have not tested that model myself, so I would treat it as a possibility rather than a conclusion. But it points to a real shift. The constraint may move from developer typing time to product judgment, review quality, operational discipline, and architectural coherence. A team of six or seven AI-assisted developers who can touch frontend, backend, and infrastructure can produce a large amount of change. The harder question is whether the business needs that much change, and whether the system can absorb it.
If the company scales up again, I think the same principles still apply. We will need clear ownership. We will need someone paying attention to engineering standards across teams. We will need managers who help developers grow and who keep teams aligned on how work should be done. We will need to avoid each team building its own AI workflow, its own standards, and its own interpretation of quality. The faster the tools become, the more important shared direction becomes.
The best signal that something is wrong is not the word monolith or microservices. It is the gap between the system and the people available to carry it. You start seeing more systems than owners. A quick change touches three repositories by default. Nobody has time to simplify anything. A runtime upgrade feels like archaeology because the team that built the service no longer exists. Those are not purely technical signals. They are organizational signals showing up in the codebase.
In the end, I think team structure has to do a few things before anything else. It has to solve the needs of the business. It has to let work move from idea to production without too much friction. It has to create accountability, so teams feel responsible for their code and for their mistakes. And it has to be reviewed from time to time, because the codebase changes, technology changes, business needs change, and the number of people available to carry the system changes too.
I would still be careful with changing teams too often. Relationships matter. Trust matters. Sometimes changing what a team owns is better than shuffling everyone into a new structure that looks cleaner on paper but loses the history that made the team effective. Architecture decisions age. Teams change. Priorities shift. Scaling up is not easy, but it is the version we tend to design for. Scaling back down is the part we forget to plan for, and that is often when we discover which decisions the organization can still carry.
- Patrick