An Embedded Backend Engineer Works in Your Repo, Your Board, Your Review
Embedded means the same tools and the same definition of done as your team. It is not a weekly call, an agency bench, or a permanent seat you are afraid to open.
“Embedded” is a word agencies print on slides and contractors print on invoices. It usually means nothing until you name the artefacts: which Git remote, which board, whose review is blocking, which Slack channel, and who is allowed to say the change is done. An embedded senior backend engineer is someone who works in those artefacts as a teammate with a commercial wrapper. They are not a vendor who demos every Friday. They are not a hire you have not posted. They are not a fractional backend engineer unless you have also agreed the days per week and what happens on the days they are not there.
I sell this model, so the scepticism belongs up front. Embedded is the right shape when you already have a product team and you need senior PHP or Go capacity inside it. It is the wrong shape when you needed a delivery organisation, a manager, or a permanent owner and you are trying to buy those things by the day.
What “embedded” actually means
If you cannot point to the repository, it is not embedded. If the contractor has a shadow Jira, a separate GitLab group, and a project manager who translates your tech lead, you bought staff augmentation theatre or an agency delivery team. Both can be legitimate purchases. Neither is an embedded engineer.
Operationally, embedded means:
- Your repository. Same default branch, same CI, same CODEOWNERS, same merge rules. A fork they polish in private is a take-home test that never ended.
- Your board. The ticket they pick is a ticket your team already believed in, or a ticket they wrote that your team accepted. A parallel backlog is how work diverges in week three.
- Your review. Their pull requests go through the same reviewers. They also review other people’s pull requests. If their comments can be ignored because “they are external,” you are paying for opinions you have pre-decided not to use.
- Your channels. Standup, the incident channel, the architecture thread. Not a weekly steering committee as the only contact.
- Your definition of done. Merged is the minimum. Deployed to production, or behind a flag, should be explicit. “Sent a patch file” is not done.
Ownership is the part people skip because it sounds like management. Write down what they own, what they advise on, and what they do not touch. An embedded senior who is only allowed to implement pre-specified tickets is a mid-level seat at a senior rate. An embedded senior who can change the database schema without telling anyone is a risk. The workable middle is: they propose, they implement in the open, a named internal person can veto, and dissent is recorded.
PHP and Go both fit this model. The language is not the embedding. The embedding is the operating system of the team. A Symfony service and a Go worker can live in the same engagement if they live in the same product and the same review culture. Two unrelated codebases with no counterpart is two jobs.
Embedded versus an agency
An agency is a delivery organisation. It can grow headcount, replace people, and sell you a project manager. That is useful when you do not have a product team, or when the work is multidisciplinary and time-boxed: a new portal, a design-plus-frontend-plus-backend programme, a deadline with no internal owners.
An embedded senior backend engineer is one human. They will not staff a frontend. They will not absorb a missing product manager. They will go deep on the API, the data model, the workers, the deploy path.
The communication difference is the one that shows up in the first two weeks. With an embedded engineer, the person estimating a Messenger change is the person who will read the failing job. With an agency, that question often travels through a status meeting. If your engineering manager already runs the team, a second management surface is overhead. If you have nobody who can own an external squad, you may actually need the agency’s project layer — in which case stop interviewing individual contractors.
Handoffs are the agency’s structural product. Discovery team, build team, warranty team. Each handoff leaks why the outbox table exists. An embedded contractor has the opposite failure: context in one head. You mitigate that with decision records and an internal counterpart, the same mitigation you would use for any senior. You cannot mitigate rotation by putting “knowledge transfer” as a line item in week twelve.
Procurement sometimes prefers agencies because the legal entity is familiar. That is a real constraint. It is not an engineering argument. If the vendor onboarding for a Serbian B2B sole trader takes nine months and an agency you already use can start on Monday, say that out loud and pick. Do not pretend the architecture required the agency.
Embedded versus hiring another full-time engineer
A permanent hire is the right answer when you need a domain owner for years, on-call membership, and institutional memory that should not walk out at the end of a SOW. An embedded contractor is the right answer when the need is bounded, delayed by a hiring pipeline, or senior in a way the current headcount plan does not cover.
The mistake is using embedding as a way to skip the political cost of a headcount. Six months later you still have no owner, the contractor is the only person who understands the billing worker, and you are negotiating another extension. That is not embedding. That is a frozen hire with a day rate.
Time-to-capacity is the honest commercial difference. Senior backend hiring in Europe is often a quarter from opening the role to useful output. An embedded contractor who already works B2B can start after paper and a short paid evaluation. Speed is not automatically an argument for contracting. If the work is “own payments for the next four years,” spend the quarter. If the work is “this queue is eating the database and we cannot wait for a notice period,” the hiring pipeline is the risk.
Cost comparisons that put a day rate next to a monthly salary are still wrong. Load the employment side: contributions, leave, recruiting, ramp. On the contractor side, count only the days you need, and count the knowledge that will leave unless you insist it is written down. I will not repeat the full matrix here; the contractor versus full-time piece exists for that spreadsheet.
Embedded does not mean “in the office.” It means in the team’s systems. A contractor in Serbia with CET/CEST overlap is more embedded than a local hire who cannot get GitHub access for a week.
Embedded versus fractional
Fractional is a cadence: commonly two or three days a week, ongoing, enough to take decisions and review, not always enough to be in every merge. Embedded is a posture: same repo, board, review. You can be both. You can also be embedded at four or five days and not be fractional.
Use fractional when the bottleneck is senior judgement and the team can execute on the days the person is away. Use a heavier embedded cadence when the work is a tightly interleaved change, an incident-heavy period, or a migration that needs daily coordination.
The failure mode of calling everything “embedded” is under-buying days. A person at one day a week who is expected to own a service, review every PR, and pair on incidents is not embedded. They are a bottleneck with a nicer label. If the team cannot carry work between sessions, buy more days or hire. Do not solve a throughput problem with a ritual of “architecture Fridays.”
How to onboard an embedded engineer so week two is real work
Onboarding is where embedded engagements go to die, and it is almost never the contractor’s technical skill. It is access, a counterpart, and a first piece of work that exists in the real system.
Do this before day one, in writing:
- Identity and access. SSO, Git host, CI, artefact registry, staging, the observability tool you actually use. VPN if you still have one. The contractor should use their own machine; do not block a remote B2B engagement on a laptop procurement queue.
- A named counterpart. One engineer or tech lead who can answer domain questions the same day during overlap hours. A shared inbox is how questions wait until Friday.
- The first ticket. Production-relevant, bounded, valuable but not the money path on day one. A worker, an endpoint with a known issue, a migration staging already needs, a test suite that fails in CI. Not “look around and suggest architecture.”
- Observability. Read access to logs, traces, dashboards. Debugging PHP-FPM or a Go service through copied screenshots is not embedding.
- Communication contract. Which channel is for what, whether they attend standup, where decisions are written, what “blocked” means.
- Decision rights. Schema, public API, new queue, production data change: propose, or decide? Both work. Ambiguity does not.
Then look at the first pull request the way you would look at a new staff engineer’s. Diff size, tests that match the repo’s habits, rollback, whether they asked a question instead of inventing a bounded context. A 10-day paid pilot is this onboarding plus an evaluation, not a separate theatre.
Do not hide the messy parts. A sanitised demo branch measures whether they can write a tutorial. The value of an embedded senior backend engineer is friction with your foreign keys, your flaky job, and your review culture.
What to give them in the first two weeks
Access to staging is not a complete environment. They also need: the runbook that exists (even if it is a stale wiki page), the list of things that are unsafe to touch, the CI jobs that are allowed to be red, the Slack channel where incidents actually happen, and permission to say a ticket is wrong.
Pair on the first production-shaped change if the domain is dense. Pairing is cheaper than a week of silent wrong guesses. It is also how the team decides whether they trust the person in review.
Failure modes that look like “the contractor did not embed”
- No merge. Their PRs sit. You have evaluated your review bandwidth, not them.
- No counterpart. They invent product behaviour. You will blame “the external.”
- Shadow process. They were told to work in a vendor repo “until we trust them.” You will never trust them, because you never saw them in the real process.
- Heroics. They bypass CODEOWNERS because they “know this pattern.” That is the opposite of embedding.
- Ticket factory. You used a senior as a body-shop resource. They will deliver what you specified, including the mistakes.
- Indefinite bridge. The hiring search never opened. The service now has an owner who is contractually temporary.
If the team did not want an outsider, stop. An embedded engineer imposed as a verdict on competence gets polite standups and ignored comments.
Commercial shape, without pretending it is employment
My own version of this: PHP and Go, in your repository, at €300/day, up to five days per week, CET/CEST overlap, B2B, monthly EUR invoice. Start with ten paid days on real work. Stop or continue when the ten days are done. That is the embedded senior backend contractor offer, not a staff-augmentation marketplace and not a hire.
If you need a swarm, buy an agency. If you need a four-year owner, hire. If you need two days of judgement a week and the team can run between sessions, say fractional out loud. If you need one senior in the repo, the board, and the review queue, then “embedded” finally means something, and you should paper it that way.