Where an external team plugs into your engineering org

Key takeaways

• Where an external team plugs in depends on two answers: what it owns, and how it talks to your team. Four placements cover almost every case: inside a team, as a second team, as an enabling team, or as a specialist component team.
• The lead of an external team reports to whoever owns the outcome for that part of the product, at the level of your own team leads. A procurement owner or a vendor-management office is the wrong answer.
• Team size is a communication problem. A team of ten has 45 pairwise channels. A team of six and a team of four have 21 between them, plus the few links you design on purpose.
• Keep the what and why internal: product ownership, the engineering manager for the stream, security sign-off and production access. Engineers, designers, QA and a tech lead can all be external.
• Don't copy a topology wholesale. Use the two questions and draw your own map.

Why this question matters

You're about to add an outside team to an engineering org that already has a structure, and every guide you can find assumes that structure is all employees. Squads, two-pizza teams and stream-aligned teams don't say where an external pod goes or who its lead answers to. If you don't decide, the default decides for you: the pod gets attached to whichever team has the most pain, its lead reports to nobody, and by month three nobody can say who owns the code it wrote.

This guide is about software development team structure, meaning where the external team sits and who it reports to. How to make external engineers feel included and productive day to day is covered in embedding contractors alongside FTEs.

The frame: What it owns, and how it talks to your team

Every placement is an answer to two questions. The first is what the external team owns: a few seats on your team, a slice of the product, a capability gap, or a specialist component. The second is how it interacts with your people.

Team Topologies gives the vocabulary, and it's the most useful public one for this. It names four team types: stream-aligned (aligned to a flow of work from a business domain), enabling (helps a stream-aligned team overcome obstacles and detects missing capabilities), complicated subsystem (where significant specialist expertise is needed) and platform. It names three interaction modes: collaboration for a defined period, X-as-a-service where one team provides and one consumes, and facilitation where one team helps and mentors another. It also insists on respecting cognitive limits, since overloaded teams make poor decisions and move slowly.

You don't need to adopt the rest of it, and you shouldn't adopt any named model wholesale. Jeremiah Lee, a former Spotify engineer, reports that the squad model Spotify published in 2012 was only ever aspirational and was never fully implemented there. The same caution applies to anything you copy from a diagram. Take the two questions, ignore the labels you don't need, and draw your own map.

zoom_in

What software development team structure works when part of the team is external?

Four placements cover almost every case. The table below is the one to take into planning. The columns that decide it are the last two: when it works and when it breaks.

A few things the table can't show.

The second-team placement is the default for a pre-assembled team. A pod that arrives with its own lead and its own standup fits as a second stream-aligned team, because it already behaves like one. DORA's 2025 research lists loosely coupled architectures among seven capabilities that magnify the benefit of AI, and the same property is what makes a second team workable. If your codebase has no seam where one team could own one side of it, fix that first or choose the inside-your-team placement.

The enabling placement is rarer than it looks, and it's where a seat gets shared. At a govtech client, A.Team staffed two parallel teams with one shared AI architect, so both teams took their architecture calls from the same person. That works because the architect is acting as an enabling seat across two teams, facilitating without leading either. It stops working when the shared person is also the delivery lead for one of them.

The specialist placement has the worst exit. A complicated-subsystem team is fine for as long as it stays. When it leaves, you inherit a component nobody inside understands, which is why the knowledge transfer guide matters most here.

Who does the external lead report to?

The external lead reports to whoever owns the outcome for the part of the product the team works on, at the same level as your own team leads. For an inside-your-team placement that's your engineering manager. For a second team it's the manager or director who owns that stream, alongside your existing leads. It isn't a procurement contact, a vendor-management function or a program office, because none of them can settle a technical or priority dispute.

Settle three things in the first week, in writing:

1. Who sets priorities. Your product owner, with the external lead present in planning.
2. Who settles technical disputes. The lead inside the team, with a named senior engineer or architect on your side as the tiebreak across teams.
3. Who gets the escalation. One named person above both, with a standing slot in the calendar.

The dedicated development team guide sets out the three models for where the lead sits: your manager above the team, a vendor manager above it, or a senior lead inside it. This guide assumes the third, which is how A.Team's team engagements work: the lead is in a builder seat inside the team, under one MSA with each builder on their own service order, with no managing-partner fee on a standard team engagement. The reporting line runs from that lead to your outcome owner. If you buy the vendor-manager model instead, the line runs through the manager, and you should decide up front who your technical counterpart is.

What is the optimal size of a development team when part of it is external?

There's no single optimal size, but there is a ceiling worth designing around. The 2020 Scrum Guide says a team is small enough to stay nimble and large enough to finish significant work in a sprint, typically 10 or fewer people. Amazon's rule, quoted in AWS's DevOps whitepaper, is that a team shouldn't be larger than two pizzas can feed. Both are rules of thumb, and both point the same way.

The reason is communication overhead, and Brooks's law makes it concrete. Fred Brooks's 1975 book The Mythical Man-Month gave the formula for the number of pairwise channels in a team of n people: n(n-1)/2. It's a model, not a measurement, but the arithmetic is useful for this decision.

Folding a pod of four into a team of six takes it to ten people and triples the channels, from 15 to 45. Keeping two teams leaves you with 21 inside the teams, plus whichever lead-to-lead and API-level links you choose to build. Those links are cheap because you picked them. The 24 extra channels in the merged version are expensive because nobody did.

So the sizing rule for an external pod is to ask whether the combined headcount approaches ten. If it does, make a second team. If it doesn't, the pod can join yours, provided you've chosen the inside-your-team placement on purpose. The same logic applies to a growing pod: when the external side approaches the ceiling on its own, split it and give each half a lead.

Which software development team roles can be external?

Most can, and a short list shouldn't. The test is whether the role owns the what and why for your business or the how for a defined piece of work. The what and why stay with you. The table is built on that split, and it's an editorial position, not a standard.

Product team structure follows the same split: an external pod can include engineers, a designer and QA, and it still needs an internal product owner to direct it. The pod isn't a product team on its own, and treating it like one is how you get a roadmap nobody inside the company set.

Onboarding the pod into this structure is covered in onboarding an external engineering team. If part of your team is AI agents as well as external engineers, the agent-to-engineer question is in team composition with agents.

How do you know the structure is wrong?

Four signals show up early. The external lead has no manager on your side who returns their messages the same day. Pull requests from the pod sit for days because no internal reviewer has been named. The pod's interface to your code changes weekly because nobody owns the contract. Or nobody inside the company can explain what the pod built last month. Any one of them means the placement was chosen by default, and you should revisit it before month three.

What to do next

Write down what the external team will own, then pick the placement from the table. Name the person its lead reports to and the senior engineer who breaks ties. Check the combined headcount against the ten-person ceiling, and decide now what you'll do when the pod grows.

If you're adding a whole pod, A.Team's team engagements put a senior lead inside the team, and the team is in your standups within 48 hours of sign-off.