ENGINEERING · SOFTWARE ENGINEERING

How we manage engineer performance when they work as part of your team.

Who reviews the work, who raises a problem, and what replaces the reporting theatre that usually fills the gap.

5 September 2026·6 min read·By Agile Labs

Who is actually responsible for the work?

Both parties, in different senses, and the confusion between them is where most embedded arrangements go wrong.

The client directs the work. They decide what gets built, set priorities, run the stand-up and own the definition of done. That is what makes the arrangement useful, and any supplier who tries to hold direction as well is selling a project rather than capacity.

The supplier remains responsible for the engineer: their level, their development, their conduct, and whether they are still the right person for this system. That responsibility cannot be delegated to the client, and it does not survive being reduced to an invoice.

What fills the gap

The failure mode is a supplier who disappears after placement and reappears when the contract renews. The usual substitute is reporting theatre: weekly status documents that describe work already visible in the client’s own tools, written to demonstrate attention rather than to produce it.

A better arrangement has three parts. The engineer is visible in the client’s own sprint artefacts daily, so progress is observed rather than reported. A tech lead on the supplier side runs a separate internal cadence with the engineer, which is where technical difficulty, frustration or a bad fit surfaces first. And a short monthly conversation brings the client lead, the engineer and the tech lead together.

That monthly conversation has one job: to surface anything that is not working while it is still a small conversation. Most placements that fail did so visibly in month two and were discussed in month five.

“Most placements that fail did so visibly in month two and were discussed in month five.”

— on why the monthly conversation is short and early

What should be measured?

Not individual output. Counting commits or story points per person measures the wrong thing and distorts the behaviour it measures, which is the oldest finding in this area.

The measures that hold are the team’s. Whether work is reaching production, how long a change takes to get there, how often a change fails, and how quickly a failure is recovered. DORA’s delivery measures were built for exactly this level of analysis, and an embedded engineer either helps those numbers or does not.

Alongside them sits a question no dashboard answers: is the team better able to run this system than it was three months ago. Bird and colleagues found ownership patterns related to defect rates, which gives the question an evidential base — an engineer who spreads familiarity is doing something measurable, even if the measurement is indirect.

When the answer is that it is not working

A fit window in the first weeks, at no penalty, gives both sides a way out before anyone is committed. After that, a written replacement commitment: a replacement proposed within a fixed number of business days, the first at no placement cost, with handover overlap so the context does not leave with the person.

Neither clause is unusual. What matters is that they are agreed before they are needed, when both parties are still reasonable.

Article

Published 12 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. Engineering management practice on embedded and outsourced teams.
  2. DORA, delivery measures, Google Cloud, 2024–2025.
  3. Bird, Nagappan, Murphy, Gall and Devanbu, “Don’t Touch My Code!”, ESEC/FSE, 2011.

Related articles

View all insights

Have something complex to build, fix or take over?

Build better software, with zero surprises