You have twenty-five engineers in three teams and almost every feature needs all three of them. You have been asked to re-cut the organisation. How would you do it, and what does the change itself cost?

Measure the coupling before you move anybody

An org proposal built from an intuition about who talks to whom is guesswork with a diagram attached, and the diagram makes it persuasive without making it right. Spend a fortnight getting evidence from work that has already shipped, because that evidence is cheap and nobody can argue with it.

The measurement that matters most is straightforward: take the last quarter's completed features and, for each one, count how many of the three teams had to change something and how many separate deployments were needed to make it usable. Suppose you take twelve features and find that eleven required changes in two or more teams, and that the median feature waited on two handoffs. That tells you the coupling is real rather than cultural, and it tells you which pairs of teams are welded together — which is the actual input to a boundary decision.

Two more readings are worth taking. First, where the waiting happens: time an item spends blocked on another team, taken from the board's own timestamps, separates a dependency that is annoying from one that is expensive. Second, ownership ambiguity: list the services and ask which single team can change and deploy each one without asking permission. Anything with no answer, or three answers, is a boundary problem you can often fix without moving a single person.

That last point is the one candidates skip and the one an interviewer values. Clarifying ownership and publishing interface contracts is weeks of work; re-cutting three teams is a quarter of disruption. If the measurement shows the coupling is mostly two unowned services and an undocumented interface, do the cheap thing and keep your reorganisation for the problem that survives it.

Cut around what a team can release alone

The only boundary criterion that reliably holds is whether a team can take a piece of user-visible value from idea to production without waiting on another team's Sprint. Every other criterion sounds sensible and fails. Grouping by technology gives you a front-end team and a back-end team, which guarantees that every feature is a handoff by construction. Grouping by headcount balance optimises a spreadsheet nobody uses. Grouping by who currently gets on well encodes today's personalities into next year's structure.

Applying the release criterion usually produces a mixture rather than a uniform set of teams. Some teams own a slice of the product end to end, sized so that most of their work is theirs alone. Others exist because something genuinely needs to be shared — an identity service, a deployment platform, a data pipeline — and those should be structured to be consumed without a meeting, which means a documented interface, self-service, and a support commitment rather than a queue. The distinction to make out loud is that a shared team providing a self-service capability reduces dependencies, while a shared team that must be scheduled multiplies them, and the two are indistinguishable on an org chart.

Twenty-five engineers gives you room for four teams of five or six with a little slack, or three of eight. Prefer the number that gives each team a whole slice over the number that looks tidy, and resist the pull towards a fourth team that owns "shared components", which is where unowned work goes to be forgotten.

Price the transition, because it is not free

The strongest answers put a number on the change itself, from stated inputs, rather than presenting the new structure as a pure gain.

Take a re-cut that moves nine of twenty-five engineers to a different codebase. If each of those nine spends roughly a month at reduced output while learning an unfamiliar system, that is around nine engineer-months, or most of a quarter of one team's capacity, spent on nothing a customer sees. Add the manager time: three managers re-forming teams, re-establishing one-to-ones, and rebuilding trust with people they have not managed before. Add the planning restart, since in-flight commitments were made by teams that no longer exist in that shape. The inputs there are the nine movers and the one-month ramp, both of which a reviewer can challenge, and challenging them is the point.

That total is worth paying if the coupling costs you more than that every quarter, and it is not worth paying to fix an irritation. State the comparison explicitly, and state how long you expect the disruption to last, because a director who is told two months and experiences six will not authorise the next change you propose.

The problems the org chart hides

Three of them, and each one has sunk a technically sound design.

Reporting lines and managers come first. Four teams need four people to lead them, and if you have three you are either promoting someone who is not ready, hiring into the middle of a disruption, or asking one person to hold two teams. Say which, and say it before someone else notices, because a design that quietly requires a headcount you do not have is not a design.

Career paths come second. If your new boundaries take the interesting architectural work into one team, you have told the other three that promotion happens elsewhere. Check each proposed team for whether a senior engineer on it can do work that would support a case for the next level. A team whose remit is entirely maintenance will lose its best people within two quarters, and that is a design defect rather than an attrition problem.

Concentrated knowledge comes third. If the three people who understand the legacy billing path end up on separate teams, one of those teams now owns a system nobody on it can safely change. The mitigation is to name it as a known risk with a deliberate plan — pairing, a documented handover, a period of dual ownership with an end date — rather than to bend the whole structure around three individuals or to pretend it will resolve itself.

Say what your design makes worse

Every boundary you draw creates a new seam, and the seam is where next year's problem lives. Cutting around product slices makes cross-cutting concerns harder: four teams will build four notification mechanisms unless something stops them. Introducing a platform team creates a dependency for everyone on it and a queue if it is understaffed. Merging two teams reduces handoffs and increases the number of people in a planning conversation.

Volunteering this is what distinguishes a candidate who has done a reorganisation from one who has drawn one. Name the seam, say what you would put in place to watch it, and say what you would measure at six months — the share of features that touch one team only, and the time items spend blocked — so the change is falsifiable rather than merely announced.

When no org chart will help

Sometimes the measurement comes back and says the coupling is in the code. If shipping any feature requires a coordinated change to one shared database schema and a monolith with no internal boundaries, then whichever way you cut the teams, they will still queue behind the same deployment. Reorganising in that situation produces the same delays with worse morale and a fortnight of leaving parties.

The right recommendation is then architectural: identify the two or three seams in the system that would let a team deploy alone, fund that work explicitly as the precondition for the org change, and move the boundaries afterwards so that they follow the seams rather than fighting them. Telling a director who has asked for an org chart that the answer is eighteen weeks of decoupling work is unwelcome and is the correct answer, and being able to say it with the measurement in your hand is the reason to take the measurement first.