Running Internal and External Teams on the Same System

Two teams on one system collide in three places: deployments, shared data, and who gets called when something breaks. The collisions are not a people problem and they are not solved by better communication. They are a boundary problem, and the boundary has to be decided before either team writes code.

The good news is that the decisions are few and they are not technically difficult. They are just usually deferred, because they feel like details next to the architecture.

Key takeaways

• Three decisions before any code: Deployment independence, data ownership, and incident routing.
• Shared code is the coupling that hurts: Shared design decisions are fine.
• Every shared thing needs one owner: Two owners means no owner.
• Review at milestones, not continuously: Continuous review spends the capacity the arrangement exists to save.

Decision 1: can each team release without the other

This is the one that decides whether the arrangement works. If the external team's release requires your team's pipeline, your approval or your deployment window, then your team's calendar sets their pace, and you have created a dependency in the direction you were trying to avoid.

Separate repositories, separate pipelines, separate environments. The two systems meet at a defined interface, and each side can release anything that does not change that interface without asking.

When the interface itself has to change, that is a scheduled, two-sided event with notice. Which brings up the second decision.

Decision 2: who owns each piece of data

Every table, every entity, every piece of state has exactly one owner. The owner can change its shape. Everyone else reads it through an agreed route and does not write to it.

The failure mode is two teams writing to the same records with different assumptions about what the fields mean. This produces data corruption that appears weeks later, cannot be traced to a single change, and is expensive to unpick. It is by a wide margin the worst thing that goes wrong when two teams share a system.

Practically:

• Core business data stays owned by your existing system. The new product reads it through an API or a replica.
• Data the new product creates is owned by the new product.
• If the new product must change core data, it goes through an endpoint your team owns, which validates it. Not direct writes.
• Schema changes on either side require notice. Agree how much.

Decision 3: who gets called, and for what

Write down what happens when each system is the one that is broken. If the new product is down, who is paged and what is the response time? If your core system is down and the new product stops working as a result, who tells the new product's users?

The case people forget is partial failure: your system is slow rather than down, the new product times out, and both teams believe the other one has the problem. Agree in advance how each side reports its own health, so that question has an answer rather than a debate.

What to share and what not to

The pattern: share decisions, not infrastructure. Two teams agreeing on what a "customer" means costs one meeting and saves months. Two teams sharing a deployment pipeline costs something every week forever.

The review question

Your engineers will often want to review the external team's code. Understand the motive, because it determines the right answer.

If it is about quality, a one-off architecture review at a milestone gets you most of the assurance for a fraction of the time. If it is because the code will eventually be theirs to maintain, then the thing to settle is the handover plan, not the review process, and we cover that in who owns the new product after it ships.

Continuous review is the option that quietly undoes the whole arrangement, because it puts your senior engineers back on the critical path.