Scaling Engineering Teams Without Breaking Them

Headcount Is the Easy Part

The hardest failures in scaling an engineering organisation are not technical. A company can buy compute, refactor a monolith, or adopt Kubernetes given enough time and money. What it cannot easily buy back is the velocity it loses when an org grows faster than its ability to coordinate. Adding the hundredth engineer to a system designed for twenty does not produce five times the output; without deliberate structure it often produces less, because every new person adds communication edges, merge contention, and decisions that now require a meeting nobody scheduled. At Baalvion, building the Baalvion Operating System across 198 markets and 180+ jurisdictions forced us to treat the org chart with the same rigour as the architecture: a system with explicit interfaces, owners, and failure modes.

This article is about the patterns we use to grow teams without breaking the throughput, ownership clarity, and engineering culture that make BOS work. The thesis is repeatedly proven: the structure of your teams becomes the structure of your software, so you should design the teams as carefully as the system. Scaling is org design, and org design is an engineering discipline.

Conway's Law Is Not a Warning, It Is a Tool

Conway's Law observes that organisations design systems that mirror their own communication structure. Most teams encounter it as a problem — a tangled service graph that maps exactly onto a tangled reporting graph. We treat it as leverage. If team boundaries inevitably become software boundaries, then choosing them deliberately is the cheapest way to get the architecture you actually want. This is the Inverse Conway Manoeuvre: shape the teams to match the target architecture, and the architecture tends to follow.

BOS is organised into five layers — Infrastructure, Intelligence, Governance, Commerce and Finance — and those layers are not just a diagram; they are an ownership map. The Finance layer that runs the ledger and settlement is owned by a team with deep context in double-entry accounting, reconciliation and the regulatory constraints of cross-border money movement. The Commerce teams that build trade and the luxury network (Amarisé) own their services end to end. When a software boundary keeps generating cross-team friction — two teams forever editing the same service, blocking each other's releases — we read it as a signal that the boundary is wrong, and we move either the boundary or the ownership until the seam is clean. The architecture and the org are debugged together.

Team Topologies: Four Shapes, Clear Interactions

We lean heavily on the Team Topologies model because it gives a shared vocabulary for what a team is for. It defines four fundamental team types, and almost every team at Baalvion maps cleanly to one of them. Forcing that classification is itself useful: a team that cannot say which type it is usually has a confused mission.

Just as important are the prescribed interaction modes: collaboration (two teams working closely for a defined period to figure something out), X-as-a-Service (one team consumes another's output through a stable contract with minimal conversation), and facilitation (an enabling team helping another improve). The point is that collaboration is expensive and should be temporary. Two teams in permanent high-bandwidth collaboration is not a healthy relationship — it is a missing API. The fix is usually to harden the interface between them into a self-service contract so the relationship can downgrade to X-as-a-Service. That single move is one of the most reliable ways we have found to recover velocity as the org grows.

Cognitive Load Is the Real Constraint

The deepest idea we have taken from this model is that the binding constraint on a team is cognitive load, not hours. A team can only hold so much in its head — the domain, the codebase, the operational quirks, the dependencies. Pile more responsibility onto existing teams and you eventually exceed that budget; the symptoms are familiar: slowing delivery, brittle on-call, knowledge concentrated in one or two people who can never take leave. Headcount alone does not fix it, because the problem is breadth, not the number of hands.

So we size and split teams by cognitive load rather than by org-chart tidiness. A team owns a domain small enough that the whole team can reason about it, and the platform exists specifically to shrink everyone else's load — a stream-aligned team should not need to understand RLS policy enforcement or outbox relays to ship a feature, because the platform has made those a paved-road default. It is the same reasoning behind how Baalvion builds scalable software: reducing what any one part of the system must know is the through-line of both the architecture and the org.

Platform Engineering: Paved Roads, Not Gates

As the number of stream-aligned teams grows, the cost of every team solving infrastructure independently grows with it — and the inconsistency becomes a compliance liability in a platform that must hold SOC 2 Type II and ISO 27001. The answer is a platform team that productises the common substrate, but the framing matters. A platform team that gatekeeps — every deployment routed through a ticket and a human approval — becomes the bottleneck it was meant to remove. One that builds a paved road becomes a multiplier.

The distinction is self-service versus permission. Our platform ships golden paths for what every BOS service needs: a service template with multi-tenancy, authentication, structured logging, metrics and the CI/CD pipeline already wired in; reusable libraries for tenant context, idempotency keys and the transactional outbox; and infrastructure as code so a team provisions what it needs without filing a request. Teams are free to leave the road, but the road is so much faster and safer that they rarely want to. Compliance controls are baked into the paved path rather than enforced by a review board, which is how you get governance and velocity at once instead of trading one for the other. We treat developer experience as a product with an explicit goal: minimise the time from idea to safely running in production.

The Autonomy and Alignment Trade-Off

Autonomy is what makes teams fast; alignment is what keeps a hundred fast teams from building a hundred incompatible things. The two pull against each other, and the job of org design is not to pick a winner but to choose deliberately where each applies. We give teams maximal autonomy over how they solve problems inside their boundary — internal design, sequencing, tooling within reason. We hold a small set of things firmly aligned: the interfaces between teams, the security and compliance posture, the data and event contracts, and the non-negotiables of a compliance-first, auditable platform.

The mechanism that makes this work is tight contracts at the edges and freedom within them. A team can rebuild its internals on a Tuesday and nobody else needs to know, because the contract it exposes did not change. This is the organisational expression of the same principle that makes our API-first architecture work technically: stable, well-specified interfaces let the things behind them evolve independently. Misalignment is expensive precisely where systems touch, so that is where we spend our coordination budget and almost nowhere else. We are suspicious of any process that imposes alignment on a team's internals — it buys consistency nobody asked for at the price of the autonomy that made the team productive.

Hiring at Scale Without Diluting the Bar

Rapid hiring is where engineering cultures most often quietly break. Double an org in a year and you risk a workforce where most people learned the codebase from others who also just arrived, and the implicit standards — what good looks like, how we reason about correctness and isolation, what we will and will not ship — erode without anyone deciding to lower them. We protect against this concretely rather than hoping culture transmits by osmosis.

The same discipline we bring to client work in enterprise software and technology consulting applies inward: a process is only real if the system enforces it — the interview rubric, the paved road, the review gate — rather than individual goodwill that erodes the moment the org gets busy.

How the Pieces Reinforce Each Other

None of these patterns is novel in isolation, and that is the point. Team topologies give you the right team shapes; Conway's Law tells you those shapes become your architecture, so you choose them to match the target system; cognitive load tells you how big a team's domain can be before it splits; the platform shrinks every other team's load so they stay small and fast; the autonomy-alignment trade-off tells you to spend coordination only at the interfaces; and disciplined hiring keeps the bar from drifting. Remove one and the others weaken — without a platform, cognitive load explodes; without contracts, autonomy becomes chaos; without a hiring bar, the structure fills with people who never learned why it exists. You can see both sides meet in our case study on unifying global trade operations, where team boundaries and service boundaries were designed as one decision. Scaling engineering teams without breaking them is, in the end, the same work as building infrastructure that holds at scale: apply the constraints early, enforce them with systems, and audit them continuously.