Skip to content

Adding engineers

Engineers who work inside your process, not around it

You have a team, a codebase and a way of doing things. Adding people from outside usually costs you something in review load, context transfer and meetings before it gives anything back. This page is about how we keep that cost low.

Engagement models

Two ways to add people

Which one you need depends on where your management capacity is.

Model 01

Embedded engineers

Our people join your team and work your backlog. You direct the work, run the standups and set priorities. We handle employment, cover and replacement.

Best when You have engineering management capacity and need hands.

You direct We staff and cover Notice agreed up front

Model 02

A separate workstream

We take a defined area of the product and run it with our own lead, reporting into you. You get outcomes and a readable status rather than tickets to assign.

Best when Your engineering managers are already at capacity.

We lead You receive readable status Scope held in writing

Working agreements

Agreed before anyone writes code

Every item below becomes an argument later if it is not agreed first.

Overlap hours
At least four hours shared with your team's day, agreed up front.
Response expectations
Same day for blockers; agreed cadence for everything else.
Review and merge rights
Your standards, your repo rules. Our engineers do not self-merge.
On-call
Only if your rota includes them, compensated, never assumed.
Ramp-down terms
Handover notes and a winding-down window, in the contract, not improvised.
Your stack
You stay the operating system of the team; we plug into it, we do not replace it. Repositories, tracker and CI stay yours, exactly where they are.

These are the defaults we propose on day one. Every one of them moves if you have a reason.

Ownership

What you own

From the first commit, everything belongs to you. Not at handover. From the beginning.

  • Code and repositories

    All of it, in accounts you control. There is no private framework underneath and no dependency on continued payment to keep the thing running.

  • Infrastructure and keys

    Cloud accounts, domains, credentials and certificates are created in your name. We hold nothing that you cannot revoke yourself.

  • Documentation

    Decisions, diagrams and runbooks are written while the work happens, so the knowledge leaves with the documents rather than with the people.

  • The freedom to leave

    If you stopped paying us tomorrow, the product would keep running without us. That is the test we design against.

Straight answers

What engineering leads usually ask

Including the two questions most pages dodge.

What happens when an engineer is not good enough?

We say it first. Underperformance gets raised with you by us, early, and the replacement is managed at our cost. Anyone who joins your team afterwards is interviewed against the same standard as the first engineer. The failure mode we design against is an engineer quietly coasting for months while nobody says anything.

Do your engineers work on other clients at the same time?

Embedded engineers do not. They are dedicated to your team full time; that is what the word means here. Separate workstreams sometimes share a specialist between them, and when one does, you are told who, for how much of their week, and why before it starts. What never happens is silent double booking.

How fast can someone start?

In weeks rather than months, though we will not quote a precise date we do not control. Even staffing engagements begin with discovery, because dropping an engineer into an unplanned situation is how placements fail. The first call settles what you need and the honest earliest window we could staff it.

Can we meet the engineers before anything starts?

Yes. You interview everyone who works on your product, to your own standard. Names only get put forward when we are prepared to back them with the replacement terms above, which keeps our suggestions honest.
Agreed before code

Tell us where you are short

A call about capacity is usually short. What you need, when you need it, and whether we can staff it.