How to Hire a Dedicated Development Team in Five Gates
In this article
- Gate one: write the brief, and name the person who will run the team
- Gate two: send the same written questions to every vendor
- Gate three: interview the engineers yourself
- Gate four: read the contract before anyone starts
- Gate five: make the first two weeks the real test
- How long the five gates take
- Frequently asked questions
- Take the five gates to a real conversation
Quick Answer: To hire a dedicated development team, pass five gates in order: write the brief, shortlist vendors on written answers, interview the actual engineers, read the contract, then treat the first two weeks as the real test. At Full Scale, engineers can start in as little as 7 days, and the first two weeks carry a money-back guarantee, so the test is cheap.
A dedicated development team is really five separate decisions dressed up as one, and there's a cheap way to say no at each stage. Too often people treat the whole thing as one decision, and decide it based on a sales call or a shiny slide deck. I already outlined the model in our guide to dedicated development teams (with pricing and use cases). Here's the other half: the right process for hiring a dedicated development team, and why you should bail at each step if things don't add up. If you're looking for the fastest way to get your feet wet, Full Scale specializes in building these kinds of teams. Visit our page for hiring dedicated developers to learn more.
Gate one: write the brief, and name the person who will run the team
For a dedicated team, I like a one-page brief that tells them what you're building, the skills they need, how much overlap you want, and what success looks like for the first 90 days. Everyone includes that. What almost no one includes is this: who on your team will be giving the team their instructions.
A dedicated team is a group of engineers taking direction from you. If there's nobody on your end who can prioritize the work, review pull requests, and push back on things, then the team has nothing to take direction from, and you just bought a very costly lesson. I've long believed in having technical leadership in house; here it becomes a concrete requirement.
The other big mistake I see in briefs is describing the people, not the problem. "Senior full-stack developer, strong communicator, team player" describes pretty much everyone with a LinkedIn account. Tell them about the work: the product, the technology, the next two quarters of the roadmap, and what the team will own. I write in my book Product Driven that you don't need rockstar developers, you need rockstar requirements, and it starts with the brief.
If you can't name the person or your roadmap isn't clear yet, walk away from this hiring process until those questions are answered.
Gate two: send the same written questions to every vendor
Phone sales pitches are a great way to find out what a vendor would like you to think. Written responses are a far better way to discover what a vendor actually commits to, since you can place three different responses next to each other and spot which one has dodged.
The same 5 questions should be sent to each vendor on your list. Full Scale anticipates that prospective clients will ask us these questions, so the table below illustrates a good answer and what our answer is.
| Question | A good answer sounds like | What Full Scale answers |
|---|---|---|
| Who employs the engineers, and who signs my contract? | A named legal entity that employs the engineers and answers to you | The engineers are Full Scale employees, and the contract is with Full Scale, a US company, so disputes run under US law |
| What is your retention rate, as a number? | A specific figure and what the vendor counts | 93%+ annual developer retention |
| Can I interview every engineer and talk to them directly? | Yes, and there is no relay in the middle | Yes, you interview the engineers yourself and work with them directly |
| How fast can people start? | A range tied to bench availability | As little as 7 days when someone suitable is on the bench, and as little as 24 hours to add a bench developer to an existing team |
| How do I leave if it is not working? | Specific terms, in writing | A two-week money-back guarantee, then 30 days' notice with no long-term contract |
Two of those deserve a comment. The direct-access question is by far the most useful, since many vendors have a setup where the real engineers hide behind a single account manager, so the client ends up with a translator in between. The retention question is important too, since it's difficult for a team with high turnover to truly be dedicated, regardless of what the sticker says. I cover both of these in more detail in my article on choosing a staff augmentation company and in how to vet a software development company.
The price question comes last for a reason. At Full Scale, we start at $35/hour fully loaded, which for most of our clients means they pay about 50-70% less than they would for the same role in the US. Choosing on price alone is a habit I call cheapshoring, and it tends to be the most expensive way to save money. Any vendor that doesn't respond in writing, or that requires all engineering questions to go through their sales team, is disqualified.
Gate three: interview the engineers yourself
After the second gate, your team's engineers become the product. You wouldn't hire a senior engineer without meeting them. That the vendor employs them doesn't matter. Do the interview over video, and invest the time in questions a resume won't answer. Whether someone can quote an algorithm from memory is less important to me than whether they will speak up if they don't know the answer, or challenge a spec that isn't right. This is far more important than the cost per hour on any invoice.
There are three questions I ask that cover most of the ground:
- Give them a real problem from your codebase. Present a small piece of your codebase for them to pull-request (one commit, for example) and have them walk through what they'd do.
- Explain something non-trivial and ask them to say it back in their own words. "Yes" on a call means nothing. Having a conversation where they paraphrase it correctly means something.
- Ask what they would change about your approach. Someone with an opinion on your implementation is someone who will take ownership.
The full guide how to interview offshore developers is here. It's worth reading before you make your first call. If you can't meet the people who would do the work before you agree to a contract, you're just buying a promise and calling it a team.
Gate four: read the contract before anyone starts
Contracts are boring because people skim them. Five clauses hold almost all the risk when you hire a dedicated team, and the table below is what our contract states about each so that you have something to benchmark against.
| Clause | What to look for | At Full Scale |
|---|---|---|
| Payment | Short terms, clear billing cycle | Paid up front, autopay through ACH, net 10 |
| Rate increases | Disclosed on day one, with a cap | A built-in 6% yearly escalator, applied as two 3% increases, written into the contract |
| IP ownership | Assignment of everything built to you | What we build for you stays yours, and we never reuse a framework or module built for one client on another client's work |
| Cancellation | Notice period, and no lock-in | 30 days' notice to drop a developer, no long-term contracts |
| Who signs | A reachable legal entity | A US company, with an unbroken contract chain from you to Full Scale to the engineer |
The IP clause is the one that needs a lawyer. In the US Copyright Office's circular on works made for hire, they state that a work created at someone else's request can be considered made for hire only if it falls into one of nine categories and there's a written agreement signed by both parties stating that it is. Software doesn't fall on that list, so you shouldn't assume that any code from a contractor becomes yours. You should ask for a written assignment, and you should make sure that it's in the contract before the first line is written. I'm not your lawyer, so let yours review the wording.
Our guide to staff augmentation contract terms includes a complete list of items to negotiate. If the vendor doesn't share a sample contract with you, then you have your answer.
Gate five: make the first two weeks the real test
An interview is a forecast. Two weeks of work is evidence. That's why you should consider those two weeks an audition with scoring criteria you establish prior to day one, rather than onboarding that you hope will go well. Evaluate three things after two weeks:
- Questions. Did the engineers ask questions about your product and the 'why' behind the work, or were they only waiting to be told what to do?
- Review effort. Does a new engineer's pull request take about the same review effort as one from your local team?
- Bad news. Did someone tell you something you didn't want to hear, early enough to make a difference?
A team with high marks on all three can move to the extended onboarding process we lay out in our developer onboarding guide and the division of responsibility described in how to manage a dedicated development team. A team with low marks on two is giving you a warning while the money-back guarantee is still active.
Schedule the review for day 12, so there's plenty of time to make a decision. The two-week money-back guarantee is for this exact purpose, and even after it has passed you can drop a developer with 30 days' notice. A bad local employee is a different kind of problem, since the true costs don't surface until months later and require additional paperwork.
If the answer to all three questions is no, then accept the refund, as it is meant to be.
How long the five gates take
Vendor side: fast. At Full Scale, if we have someone suitable on the bench, we can be ready in as little as 7 days, and take about 14 days for onboarding to your code. The bottleneck usually comes from your side. Your internal interview rounds, your decision makers, and your contract approval process can drag on for weeks.
| Gate | Who on your side owns it | Where the time goes |
|---|---|---|
| Brief | Engineering leader | Getting the roadmap and the owner agreed internally |
| Vendor answers | Engineering leader and ops | Waiting on written replies and comparing them |
| Engineer interviews | Engineering leader, plus a senior engineer | Scheduling video calls |
| Contract | Legal or the CEO | Review and approval cycles |
| Two-week trial | Engineering leader | Almost none, since the clock is already running |
Want to shorten this process? Focus on the middle rows. These are where the bulk of calendar time gets spent.
Frequently asked questions
How do you hire a dedicated development team?
Hire a dedicated development team in five gates: write a brief that names who on your side directs the work, send the same written questions to a few vendors, interview the actual engineers yourself, read the contract before anyone starts, and treat the first two weeks as the real test. At Full Scale, the first two weeks carry a money-back guarantee, so the trial itself is low risk.
How long does it take to hire a dedicated development team?
At Full Scale, an engineer can start in as little as 7 days when someone suitable is on the bench, and full onboarding into your codebase takes about 14 days. The slower part is usually the buyer's own process, meaning internal interviews, decisions, and getting a contract approved.
What should you ask a dedicated development team vendor before hiring?
Ask who employs the engineers and which company signs your contract, what retention rate the vendor can state as a number, whether you can interview every engineer and talk to them directly, how fast people can start, and exactly how you leave if it is not working. Put the questions in writing so you can compare vendors line by line.
Should you interview the developers before signing with a dedicated team vendor?
Yes. Interview the engineers who would actually work on your product, on video, before you sign. A vendor that offers only a sales lead or a project manager to talk to is telling you how the engagement will run.
What if the dedicated team is not working out?
At Full Scale, the first two weeks carry a money-back guarantee, and after that you can drop a developer with 30 days' notice and no long-term contract. Schedule your trial review before day 14 so the decision lands inside the guarantee window.
Take the five gates to a real conversation
Come with your brief, come with your questions, come with your skepticism. Schedule a call with Full Scale and we'll give you written answers for all five of these, as we expect you would ask any vendor.
