Staff augmentation vs dedicated team: how the two differ

In staff augmentation, your engineering manager assigns tickets, runs the standup and reviews every pull request, while the vendor supplies the person and handles payroll, leave and the laptop. Your process stays as it is. There is nothing new to learn.

A dedicated team moves part of that direction to a lead on the vendor side, while your product owner still sets priorities in the backlog. The lead splits those priorities into tasks, assigns each task to a named engineer and answers for the sprint outcome, the demo and the handoff to the test team.

Ask a blunt question. Does a senior engineer on your side have spare hours every week to direct a newcomer, review pull requests and answer questions about the legacy modules? If not, the new hire stalls by week two, waiting on answers that nobody has time to give, while the sprint slips without anyone saying so.

A single engineer extension is one named person on a contract of a few months, with a notice period on both sides. You interview that person. The name, the weekly hours and the start date are known before you sign anything, and the first ticket can be agreed in advance.

A dedicated team is several named people, typically a mix of backend, frontend and test engineers, and the size follows your roadmap rather than a fixed headcount. Some vendors name only the lead at signing and promise the rest later, so ask for every name, title and start date before you sign. Blanks are a warning.

A managed team with a lead adds a coordinating role, often part time, so check whether that lead joins your standups or only the monthly report. The first is useful. The second is overhead.

When an extension engineer leaves, the gap is yours until the vendor finds someone, so agree the replacement window and the handover days in writing. Also settle who absorbs the ramp-up weeks of the replacement, the vendor or your own team, and get that answer signed before the first invoice.

In a dedicated team the vendor carries more of that risk, because the lead can move another engineer across and keep the sprint going. That cover costs extra. Ask how often the vendor has used that cover and how many days the sprint slipped when it did, and ask to speak to a client who saw it.

Ask about removal rights too. A clause that lets you request a replacement without giving reasons saves an awkward conversation later, especially when the engineer is technically fine but a poor fit.

Whatever the model, the repository organisation, cloud console, CI service, ticket board and password manager should sit in your company’s name. Vendor engineers get seats inside them. They bring none of their own.

Vendors sometimes run a team from their own GitHub organisation or Jira site because it is easier for them, and nobody questions the arrangement until the contract ends. Moving later means exporting ticket history, rewriting pipeline secrets, re-pointing deploy keys and reissuing signing certificates, and the whole job can take weeks.

Write the account owner into the contract. Add a line that every credential issued to the team is revoked on the end date, with a named person on your side who confirms it in writing.

If you have a strong technical lead and a clear backlog, a single extension is the lightest way to add hands. Without both, extra hands will not help.

With a roadmap but no spare management time, a dedicated team fits, since the vendor lead splits the work and answers for each sprint. Lacking a technical lead as well, you want a managed team with a lead, though one senior reviewer should still sit in your own office.

Before you talk to vendors, fill in the comparison sheet for your own situation, then send the same sheet to each vendor and compare the answers line by line. Note every blank.