ENGINEERING · SOFTWARE ENGINEERING

Working inside another engineering team

An embedded engineer adopts the client’s process. What should travel with them anyway, and what should not.

20 August 2026·6 min read·By Agile Labs

Whose process wins?

The client’s. An engineer joining an existing team adopts its branching model, its review conventions, its ticket hygiene and its definition of done, including the parts they would have designed differently.

This is not a courtesy. A team with one person following different conventions has two processes, and the cost of that lands on everyone else. Where the local process is genuinely harmful, the response is to say so once, clearly, to the person who owns it, and then work within it until it changes.

What should travel anyway

A small floor, and it should be short enough to state in a sentence. Tests arrive with the change rather than after it. Estimates are honest, including the ones nobody wants. Review is treated as engineering work rather than a formality. Decisions that will outlive the sprint get written down somewhere the team will find them.

None of that conflicts with adopting the client’s process, and all of it is what distinguishes an engineering company placing its people from a supplier renting seats. It is also what a client is actually paying the difference for.

“A team with one person following different conventions has two processes.”

— on adopting the local way of working

Where does the friction actually come from?

Rarely from skill. Usually from an engineer who disagrees with something local and does not say so, then works around it. The workaround is invisible for a while and then becomes a second way of doing things that only one person understands.

The second source is ambiguity about who decides. If the engineer takes direction from the client lead on Monday and from a supplier manager on Wednesday, both are being helpful and the engineer is being pulled apart. Direction sits with the client; the supplier holds the engineer’s development and level.

The third is cognitive load, in the sense Team Topologies uses. A team already at its limit does not get faster by adding a person who needs context from them. The first month costs the team time, and pretending otherwise makes the arrangement feel like a failure at precisely the point where it is going normally.

What the receiving team should supply

Where those five exist, most placements settle quickly. Where they do not, the arrangement is being asked to compensate for a gap that was already there.

Article

Published 19 August 2026

By Agile Labs

Agile Labs is a Singapore enterprise software engineering company. We design, build and secure enterprise software and AI systems.

Sources

  1. Skelton and Pais, Team Topologies, 2019.
  2. DORA, delivery measures and capability findings, Google Cloud, 2024–2025.
  3. Embedded engineering practice from boutique consultancies.

Related articles

View all insights

Have something complex to build, fix or take over?

Build better software, with zero surprises