There are three ways to add engineering capacity: one or two contractors, a dedicated development team, or a permanent hire. They are not interchangeable. The difference that matters is how long the need lasts and who carries the risk.
What a dedicated team is
A dedicated development team is a group of engineers who work on your project through a supplier rather than on your payroll. They are not shared across other clients, and they normally include the roles a project needs, not only developers: designers, QA and DevOps as well.
The label is not the important part. What matters is that the supplier carries the hiring, the contracts, the replacement risk and the equipment, and you direct the work. If a supplier offers a "dedicated team" but rotates people between clients, it is staff augmentation with a better name.
How they compare
| One or two contractors | Dedicated team | Permanent hire | |
|---|---|---|---|
| Best when | A narrow, well-defined skills gap | A plan that will run for quarters, with too few people | The role is indefinite and the knowledge should stay in your company |
| Speed to start | Fastest | Slower than a contractor, faster than hiring | Slowest: notice periods and recruitment |
| Hiring and replacement risk | You or an agency | The supplier | You |
| Easiest to stop | Yes | Within the notice period in the contract | No |
| Cost shape | Day rate | Per person, per month or per day | Salary plus employer costs |
Questions worth asking any supplier
- Who exactly is on the team? Names, seniority and what else they are working on. If you cannot find that out before signing, you will not find it out afterwards.
- Who owns the code? It should be you, by default, in your own repositories and accounts.
- What happens if this does not work? Notice period, how work in progress is handed back, and whether the documentation is part of the work or an extra.
- Who do I talk to when something is wrong? An engineer on the team, or an account manager relaying messages.
How to tell it is working
Set this before the team starts, not after the first disagreement. The useful signals are boring ones: work reaching your users at a steady rate, questions that show the team understands the business, and problems surfacing early instead of at the deadline. Agree what "done" means for the first piece of work.
When it is the wrong answer
If you do not yet know what you are building, a team will build the wrong thing efficiently. If the work is short and well-bounded, one specialist is simpler. And if the knowledge needs to stay in the company for years, hire.
The full version, with the step-by-step process, cost points and UK contract checks, is on the Cognivise blog. If you are weighing up a team, how we set up dedicated development teams explains our approach.
Top comments (0)