Senior engineers in a client's team, and the reporting line

Most of the friction in an embedded engineering arrangement traces back to a single question nobody settled at kickoff: whose instruction the engineer follows when the client's technical lead and our delivery manager want different things in the same week.

Left unanswered, it gets answered repeatedly and badly, by whoever asked most recently or most insistently. Everyone then describes the result as a communication problem, which it is not.

The default we work to

On Engineering Services work the engineer reports to the client's technical lead for what gets built and in what order. Sprint priorities, review standards, definition of done, the shape of the working week: that belongs to the client. We do not run a parallel backlog and we do not hold a private second opinion about the roadmap.

Three things stay with us. Career management, including reviews and progression, because a client cannot promote someone they do not employ. Cover for holiday, illness and departure. And a technical escalation path the engineer can use without going through the client's lead.

What the escalation path is for

• A request that would breach the client's own security or compliance policy. This happens more often than anyone expects and is almost always accidental, usually under deadline pressure from someone two levels above the person asking.
• Sustained pressure to work in a way the engineer considers unsafe for the system: skipping review to hit a date, deploying without a rollback, disabling a check because it is noisy.
• Scope that has drifted far enough from the agreement that it needs a commercial conversation rather than a technical one.

Everything else goes to the client's lead. If an engineer is routinely bringing us decisions their lead should be making, the arrangement has already gone wrong and the reporting line is the first place to look.

Two ways it fails

The shadow team

A client brings in four engineers for capacity, then gives them their own standup, their own board and eventually their own repository. A year later there are two codebases and two sets of conventions, and merging them is a project with its own budget and its own risk register. Our engineers push back on this early, which can read as awkwardness in the first month. It is cheaper than the alternative.

The invisible supplier

The opposite failure, and the more comfortable one. The engineer is absorbed so completely that nobody at either organisation is checking whether the engagement is still the right shape. Two years on they are doing maintenance well below their level, the relationship is warm, and the client is paying senior rates for it. We review capacity quarterly for exactly this reason, and the review sometimes ends with us proposing a smaller team than the one we are being paid for.

The performance conversation

When an embedded engineer is struggling, the client's lead usually notices first and tells us last. Raising it feels like complaining about a supplier rather than giving feedback to a colleague, so it waits until it is serious enough to be awkward for everyone.

We ask for it in a short monthly call with the lead that exists for nothing else. Fifteen minutes, no agenda beyond how each individual is doing and whether anything needs to change. It reliably prevents the situations that otherwise end in a replacement request, a soured relationship and an engineer who never understood what went wrong.

Write it down at kickoff

The reporting line belongs in the engagement document alongside the rates. Who sets priority. Who approves leave. Who runs the performance review and who contributes to it. What the escalation path is and who sits at the end of it. Who decides when the engagement changes size.

It takes an hour to agree while everyone is getting along and it feels like bureaucracy at the time. It pays for itself the first quarter that two people with genuine authority want different things on the same Thursday afternoon.