Hiring models · 7 min read
Staff augmentation, a dedicated team, or a fixed project? How to choose
A plain-English guide to the three main ways to add engineering capacity, what each is best for, and the questions that help you choose the right one.
By Bakaya Partners ·
When a roadmap outgrows the team, the first question is usually "who should we hire?" The better question is "what kind of help do we need?" Adding one engineer, adding a team and handing over a whole project are three different decisions with different trade-offs. Here is how we think about them.
Staff augmentation: adding one or two people to your team
In staff augmentation, an engineer joins your team and works to your plan. You set the priorities, run the standups and review the code. The engineer brings skills and capacity you don't have right now.
It works best when:
- You already have technical leadership and a clear backlog
- You need a specific skill, such as Kubernetes, mobile or LLM tooling
- The need is temporary or uncertain, and you want flexibility on hours
It struggles when nobody has time to direct the new person. An engineer without context or leadership will deliver far less than their ability suggests. Our engineer placement service is designed for teams that can offer that direction.
A dedicated team: a group that owns an outcome
A dedicated team is a small group, usually led by a senior engineer, assembled around a goal such as launching a product or rebuilding a platform. You decide what matters most. The team works out how to deliver it and carries the day-to-day coordination.
It works best when:
- The work needs several skills at once, such as frontend, backend and infrastructure
- Your own managers are stretched and can't coordinate more people
- You want one group accountable for results, not extra hands to manage
It struggles when the goal is vague. A team needs a clear outcome, even if the path to it is flexible. See how dedicated engineering teams work for the details.
A fixed project: handing over a defined result
With a project, you agree what "done" looks like and the provider takes responsibility for getting there, usually in milestones. It suits work with a clear shape: a migration, a data platform, an integration.
It works best when:
- The scope can be written down and agreed
- You don't have the specialist knowledge in-house to plan the work
- You want a result and a handover more than you want to manage the process
It struggles when requirements are still changing every week. In that case a team or an embedded engineer is a safer fit. Our consulting services start with a discovery step first, specifically to firm up scope before the build begins.
Five questions to help you decide
- Do we have someone with the time to direct this work? If yes, augmentation is viable. If no, lean toward a team or project.
- Is the outcome clearly defined? Clear outcomes suit projects. Fuzzy ones suit embedded engineers or teams.
- How many skills does the work need? One or two skills point to augmentation. Four or more point to a team.
- How certain is the timeline? Uncertain timelines favour flexible, hourly or monthly arrangements.
- What happens after it ends? If your team has to maintain the result, make handover and documentation part of the agreement.
You don't have to pick just one
Many companies start with a single embedded engineer to get moving, add a second as the work grows, and bring in a project team for a defined initiative such as a cloud migration. The models are tools, not commitments. The useful thing is to be honest about how much direction you can provide and how clearly you can describe the outcome.
If you're weighing these options, talk to us. We'll tell you what we'd recommend, including when the answer is "you probably don't need us for this."