Start with the question behind the question
When a team runs short of engineers, the conversation usually jumps straight to who to hire. The better first question is what kind of gap you actually have. There are three, and they call for different answers:
- A permanent gap. The work will be there for years, it's core to what you sell, and you want the knowledge to stay in the building.
- A capacity gap. You know what to build and how, but there aren't enough hands, or you're missing one skill, such as AI, DevOps or a senior architect, for the next six to eighteen months.
- A project gap. There's a defined thing to build, with a beginning and an end, and nobody on your team has the time or the background to own it.
Most bad staffing decisions come from treating one kind of gap as another: hiring full time for a capacity gap that will be gone in a year, or handing a core product to an outside agency because hiring was slow.
Hiring full time
Hiring is the right answer for a permanent gap. A full-time engineer builds context over years, carries your culture, and becomes the person who knows why the system works the way it does. Nothing replaces that for the core of your product.
The costs are mostly in time and risk. A search for a senior engineer often takes months, and the cost of recruiting is paid whether or not the hire works out. Then there's ramp-up before they're fully productive, and the cost of getting it wrong, which we cover in what a bad engineering hire really costs. Hiring also assumes you know what the role should be. For a new capability, such as your first AI work, that's often the thing you don't know yet.
Staff augmentation and embedded engineers
Staff augmentation means bringing in engineers who work inside your team, on your backlog, in your tools, under your direction, while someone else employs them. The best version is what we call an embedded team: the person is vetted for your role and your culture, sits in your standups, and is reviewed and supported by senior people on our side.
It fits a capacity gap. You keep control of what gets built and how, which you don't with an agency, and you don't carry the long recruiting cycle or the commitment of a permanent hire. It's also a low-risk way to find out what a new role really needs before you hire for it.
Where it goes wrong is when the provider is just a resume pipeline: people nobody has really checked, a recruiting fee up front, and nobody to call when it isn't working. The questions to ask any provider are who actually vets the people, what happens if someone isn't the right fit, and how much notice it takes to end it.
An agency or outsourced project
An agency, or any fixed-scope outsourced build, fits a project gap. You agree what will be delivered, the agency runs its own team and process, and you get a finished system. Done well, it's the least management overhead of the three: you're buying an outcome, not people.
The trade-off is control and continuity. The agency's engineers aren't in your standups, the knowledge leaves with them when the project ends, and changing direction mid-project usually means renegotiating. That makes an agency a poor fit for a core product that will change every week, and a good fit for a well-defined system with a clear finish line, especially if the contract gives you the code and documentation at the end.
| Hire full time | Embedded engineers | Agency or project | |
|---|---|---|---|
| Best for | A permanent, core gap | A capacity or skills gap | A defined project with an end |
| Time to start | Usually months | Usually weeks | Weeks, after scoping |
| Who directs the work | You | You | The agency, against an agreed scope |
| Who employs them | You | The provider | The agency |
| Commitment | Long term | Month to month, if the terms are good | The length of the contract |
| If it's the wrong person | A performance process, then a new search | The provider replaces them | The agency's problem, until it isn't |
| Knowledge stays with | Your company | Your team, if they work in your tools | The agency, unless it's handed over |
A simple way to decide
- Will this work still be there in three years, and is it core to what you sell? Hire, and consider embedded engineers to cover the gap while you search.
- Do you know what to build, but lack the people or one specific skill? Embedded engineers. You keep direction, and you can scale up or down as the work changes.
- Is there a defined system to build, with an end, that your team can't own? A fixed-scope project, with the code and documentation handed over at the end.
- Not sure yet? Start embedded or with a short discovery, learn what the work actually needs, then decide whether it becomes a hire.
How our embedded teams work
Our embedded teams are built for the capacity gap. We place product managers, architects, and AI, software and DevOps engineers inside your team, remote, hybrid or on-site as you need. People usually start within two weeks of agreeing the role. There's one monthly rate per person, with no recruiting fee and no hourly billing, and onboarding, senior reviews and cover are included.
Everyone we put forward goes through the vetting we describe here, and you interview them before they start. They stay employed by us, so you aren't taking on an employee. If someone isn't the right fit, we replace them, and engagements run month to month with notice agreed up front.
If what you need is a defined system built and handed over, we do that too, through product development and custom apps, with one agreed price and a free discovery first.