How to scale: if your organization is a mess, your software will be a mess

How do you scale a tech department or a specific engineering area? The starting situations where this becomes necessary are typically three:

1. The Scale-up phase: A startup receives funding, the business must run, and people are hired rapidly because you need to execute.
2. The new Corporate project: A large company launches a project initially handled by a few people, which for business needs must suddenly evolve and become larger.
3. M&A (Mergers and Acquisitions): One company buys another and the tech departments must integrate. This is the most complicated case, because it is not just about scaling, but dealing with two pre-existing cultures to build a single one.

Although the third case presents the biggest differences, at the level of principles and final objectives the situations are managed in a very similar way.

The breaking point and Conway's Law

The starting point is a company that needs to grow. Hiring increases and you move from a single manageable group of 4 or 5 people to 6, 8, 10, up to 15 people. At this point, chaos begins.

In some situations this growth happens in months or weeks, not years. The typical problem encountered is the impossibility for the manager to handle all these people. Developers start running around uncontrolled, without a real direction, taking isolated initiatives. Consequently, because the company is growing fast in a chaotic way, the software becomes extremely messy too.

As Conway's Law reminds us, the architecture of a software reflects the architecture of an organization. If an organization is a mess, the software will be mathematically a mess. We therefore face problems of coordination, strategy, communication, and software development. What to do and what not to do in these phases?

Designing the future starting from the Business

The first thing to do is start thinking about the future structure. Since the architecture follows the organization, we must decide how we want to be organized.

This step must be strictly tied to business objectives. We must assume the company has a strategy, KPIs, a roadmap, and a clear vision. If this is missing, the exercise of scaling is useless and only wastes money.

Once the future of the business is understood, we can imagine the future organization. The first mistake I see is making the organization born out of an architectural diagram. We must not divide teams based on microservices or pre-existing software. Absolutely not. We must understand what the future business areas will be and make a division linked to the product.

For every team we create, there must be clear KPIs that belong only to that team. If we have an e-commerce platform, we can decide to divide it into standalone macro-areas: a team handles inventory, one handles financial reconciliation, and another handles product presentation and the purchase flow. This division works because it makes sense at a product level and defines different objectives. Finance will have invoice accuracy and cash flow as KPIs. The storefront will have conversion rate and sales performance as KPIs.

A structure emerges based on the main pillars of the store. If the product is very large, we can create sub-pillars. The sales flow can be divided between a "Search Team" (KPI: result accuracy and speed) and a "Purchase Team" (KPI: conversion rate). The areas will have objectives that influence each other, but the priorities of each perimeter remain clearly distinct.

This future horizon does not need to be 10 years. One year is the ideal unit of measurement. It is enough to chart the course and it can be adjusted every six months depending on the company's situation.

Intermediate phases and Organizational Mitosis

Designing the one-year future is fundamental to define the present vision and the intermediate steps. We cannot magically jump from a single team to five teams with triple the headcount, also because hiring speed is variable.

How do you divide teams in practice? You must never arrive one day with a magic wand and draw new lines dividing everyone. This creates organizational chaos. Any reorganization always brings internal friction and an increase in cognitive load, reducing company performance. No matter how much people love dynamism, there is a technical adaptation time dictated by the human brain that we can do nothing about.

The correct approach takes inspiration from biology: organizational mitosis. You identify the macro-areas and divide the initial group (the ideal case is dividing it when there are 10 to 15 people) into two teams of 5 to 7 people. With new hires, you increase the size of these teams. When Team 1 grows from 5 to 8 engineers, the team divides again forming two new teams.

Initially, these two new teams must be managed by the same manager who led the original team. This is crucial to reduce management friction. When two teams split, their backlog and work in progress split too. Doing this operation while simultaneously changing the manager makes everything extremely complex. Keeping the same manager significantly increases the effectiveness of communication between the two new cells and facilitates the routing of initial activities, covering everything that was not perfectly designed on paper.

Premature Optimization and Architectural Cathedrals

The organizational division must take into account the architectural design. The architecture must evolve with the organization. There must be no premature evolution to meet an organizational design that might exist three years from now.

Assuming that an area will be divided into many parts and creating millions of microservices in advance is premature optimization that excessively increases software complexity. You create a "cathedral" that will not survive reality. When you design a super complex architecture with a very long horizon, added to the uncertainties of business growth, it is mathematical that this complexity will never pay off. The business will evolve differently and every team will find itself managing an unmanageable number of services.

The recommendation is to calibrate the number of services correctly. It is much better to create internal divisions within the microservice (proper class management and software design) so they can be physically split later, when the organization actually needs it.

The error of continuous collaboration

Another great challenge related to growth is communication. Inside a single team, communication flows fast. Between two teams, silos form over time. They represent the first real friction.

How do you make teams collaborate? Simple: they should not collaborate.

If two teams constantly need to collaborate to reach a single goal, we will find ourselves constantly managing cross-team initiatives. This leads to massive bottlenecks. Governance goes down. To solve this, companies create coordinating figures between separate teams: since the two managers cannot align, a third figure is placed in the middle to act as a bridge. Over time and as teams increase, this generates an infernal hierarchy. Too many organizational layers and intermediate figures are created, generating incredible communication latency.

If we have correctly divided business goals and product perimeters, every team has a different and defined mandate. No gray areas.

Software Contracts and Asynchronous Communication

If the organizational work is correct, the software infrastructure is missing. The architecture must be truly decoupled. If we have two logically coupled microservices (modifying one requires modifying the other) and they are managed by two different teams, we have just created a bottleneck.

The fundamental solution is to create communication contracts (APIs). Teams must communicate through the "non-communication" of the software. Every team autonomously evolves its own product. Coordination will obviously be required to update communication protocols, but this is handled asynchronously and is much easier than aligning on every single operation.

The bulk of communication must shift to asynchronous: RFCs, Architecture Decision Records, written documentation, and clear contracts. When communication shifts from "I must come tell you what to do" to "I need information, I will retrieve it", the organization becomes fast. The ultimate goal is the complete autonomy of each team. Without this, it will always be necessary to add yet another coordinator.

The red alarm signal

A very serious alarm signal is when the entire organization must execute a single initiative and all managers must sit at a table to talk to each other. Someone will object that to evolve the entire product it is normal for the whole company to be involved. This is completely wrong. If a bunch of managers of managers have to talk about "what to do", you will go nowhere.

The product must evolve in its entirety, but when this blockage happens it means the objectives are poorly defined (like a vague goal such as "we want to get rich") or that top management is deciding the solution instead of the objective. Objectives must be concrete, measurable, specific enough for a team but generic enough not to dictate a technical solution.

Freedom at the edges and the absence of processes

When the company finds itself continuously defining processes, interaction methods, or manifestos, it is time to stop, erase everything, and restart from the fundamentals: Organization, Architecture, and Objectives.

You might be in a company with 30-year-old monoliths and you cannot be perfect on day one. But you can do a lot by starting to trust the people in the teams. You must reduce managerial pressure, the desire to dictate solutions, and let teams find their own way. By lightening the governance load, the organization starts to breathe and undertake small improvements that cascade into enormous results. I have found myself in seemingly out-of-control situations where introducing small adjustments to give awareness of the direction was enough: the team started moving correctly on its own, without needing someone to tell them what to do every single time.

Finally, standards can be introduced, but a standard must never be the tool to control a wrong organization. It must exclusively be a generic policy, an extremely lightweight guideline, investing in rigidity only in the most critical aspects like security.

It is inevitable, and deeply positive, that different teams at the edges of the organization have very different ways of working and make different technical choices. It is precisely in the multitude of experimentation and diversity of approaches that a growing company maximizes the chances of finding the winning approach. You must never lock the entire department into a highly rigid grid of protocols and processes.

In this whole discussion, I have not mentioned a single process. The only protocol that must exist is the data contract between parties. If we think we can create processes to make the organization grow, we will only lock it down completely, guaranteeing its failure.