Working Alongside Your In-House Team

Why this arrangement goes wrong

The friction is rarely technical. It is that an internal team was not consulted about hiring an agency, or suspects the agency is a step towards replacing them, or is being held to standards the agency is not.

All three are addressable, and all three get worse if nobody names them. We raise it in the first joint session rather than pretending everyone is delighted.

Split by feature, not by layer

The common instinct is to give the agency the frontend and keep the backend, or similar. It reliably produces a coordination tax on every change, because almost nothing is confined to one layer.

Split vertically instead: one team owns the reporting module end to end, the other owns the ordering workflow end to end. Each can ship without waiting for the other.

A horizontal split means every feature needs both teams. A vertical split means most features need one, and that is the whole difference.

One standard, both directions

• The same review requirements for both teams
• Cross-team review — we review theirs, they review ours
• One definition of done, agreed at the start
• One CI pipeline and one set of quality gates
• Architecture decisions documented and open to both

Cross-review in both directions is the single most useful practice here. It transfers knowledge, prevents two divergent styles, and makes clear that the agency is not being held to a lower bar.

Deciding who decides

1. Technical decisions inside a team's own area: that team
2. Anything crossing the boundary: joint, with a named tiebreaker
3. Architecture affecting both: joint, written down
4. Priorities: yours, always

Name the tiebreaker before the first disagreement. Usually your most senior engineer, and it should be them rather than us — you live with the consequences.

Knowledge transfer as a deliverable

If the intent is for your team to take over, that is a deliverable with a plan, not something that happens by proximity.

• Pairing sessions on the areas they will inherit
• Documentation written for them, reviewed by them
• Their developers making changes in our area, with our review, before handover
• A defined handover date rather than a gradual fade

The conversation to have on day one

With the internal team present, without the agency's commercial contact talking for them: why are we here, what happens to your roles, who decides what, and what would make this go badly.

That last question produces the most useful answers. Internal teams usually know exactly how it will go wrong, and they are usually right, and nobody has asked them.

Frequently asked questions