A staff augmentation job description should tell the provider exactly who to find: what the engineer will own in their first 90 days, four or fewer must-have skills, the hard parts of the work, who they report to, and the hours they need to be online. The template below fits on half a page. The quality of the shortlist you get back is capped by the quality of this document. Send "senior full-stack developer, React and Node" and you'll get three reasonable profiles that could fit a thousand companies. Send a real brief and you'll get three people who could plausibly do your job.
Key Takeaways
- A staff augmentation job description is read by a matcher, not by candidates. Write it plainly and include the unflattering parts.
- Lead with outcomes: what the engineer will own and ship in the first 90 days.
- Keep must-haves to four or fewer, and name the exact overlap hours in a time zone.
- Half a page is enough. If it runs longer, you're probably describing two roles.
Staff Augmentation Job Description vs a Regular Job Description
| Regular job description | Staff augmentation job description | |
|---|---|---|
| Reader | Candidates | The person matching engineers |
| Goal | Attract applicants | Filter to the right few |
| Tone | Persuasive | Plain and candid |
| Content | Mission, perks, requirements | Outcomes, constraints, the hard parts |
| Length | One page | Half a page |
If you already have a job description, don't forward it as is. Most of it is marketing. How to write a job description for senior engineers covers that document; this post covers the one a provider actually needs.
The Staff Augmentation Job Description Template
Copy the first two columns into a doc and replace the examples with your own.
| Field | What to write | Example |
|---|---|---|
| Role in one line | Seniority, focus, what they'll own | Senior backend engineer to own our routing API |
| First 90 days | One or two concrete outcomes | Cut p95 latency on /routes from 2.4s to under 800ms; add a caching layer |
| Must-haves (max 4) | Skills without which they fail in week one, with depth | Node in production at scale; Postgres query tuning; Redis |
| Nice-to-haves | Everything else | Kubernetes; experience with logistics data |
| Stack | Languages, frameworks, database, cloud, CI | Node, TypeScript, Postgres, AWS, GitHub Actions |
| The hard parts | Legacy code, on-call, vendors, ambiguity | No tests on the routing module; original author left |
| Team | Who they report to, how many engineers, who reviews code | Reports to the CTO, who reviews every pull request |
| Overlap hours | Exact hours in a named time zone | 9am to 2pm Eastern, Monday to Friday |
| How you work | Sprints or kanban, release cadence, tools, AI tool policy | Kanban, daily deploys, Linear, AI tools allowed |
| Start window | Date range | Within four weeks |
| Deal-breakers | What rules someone out | No production incident experience |
How to Fill In the Hard Fields
The 90-day outcome. "Own the billing service and ship usage-based pricing by end of Q1" tells a matcher more than any list of skills. If you can't write this line, stop and figure out the role first.
Must-haves. A list of twelve gets you either nobody or someone who claims all twelve. Write depth, not keywords: "has run Postgres migrations on a live production database" beats "Postgres."
The hard parts. The right engineer has seen a 2019 monolith with no tests before and won't leave over it. The wrong one finds out in week two. Say it up front.
Overlap. "Available 10am to 3pm Eastern for meetings" is useful. "Some overlap" is not. Why time zone overlap matters explains how much you really need.
A Concrete Version
A logistics startup's first job description read: "Senior full-stack developer, React, Node, AWS, 5+ years, strong communication." The shortlist came back fine and generic. The CTO interviewed two people and neither felt right.
The rewrite used the template: "Own our route-optimization API. First 90 days: cut p95 latency on /routes from 2.4 seconds to under 800ms and add a caching layer. Must-haves: Node in production at scale, Postgres query tuning, Redis. Hard parts: no tests on the routing module, and the original author left. Online 9am to 2pm Eastern. Reports to the CTO, who reviews all pull requests."
The new shortlist had three profiles; two had done latency work on Node services. The CTO picked after one interview each. The rewrite took twenty minutes and saved him a second round of interviews.
The Honest Counterpoint
A very specific job description narrows the pool. If your must-haves describe one person who worked at your last company, the provider will either come back empty or stretch the truth to fill the slot. Specific outcomes are good; specific pedigree ("must have worked at a Series C fintech") usually isn't.
A template also can't fix a role you haven't figured out. If you can't write the 90-day outcome, you probably don't know yet what you need. Spend a week on that first, or start with a short scoped project and write the description once you've learned what the work actually is.
Frequently Asked Questions
What should a staff augmentation job description include?
The 90-day outcome, four or fewer must-have skills with depth, the hard parts of the work, team and reporting lines, exact overlap hours, how you work, and a start window.
What are typical staff augmentation requirements?
The requirements that matter are the ones tied to outcomes: the specific systems the engineer will own and the depth of experience they need with them. Years of experience and long keyword lists predict less than you'd think.
Should I send my existing job description to a staff augmentation provider?
You can include it, but write a separate brief using the template above. Public job descriptions are written to attract candidates and hide the hard parts a matcher needs to know.
The Bottom Line
Write the staff augmentation job description for the matcher, not the candidate. Lead with outcomes, cap the must-haves, and name the hard parts. When yours is ready, send it to us, read how to evaluate a staff augmentation provider to judge what comes back, and see the staff augmentation process for what happens after you hit send.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
