Managed Capacity: The Engagement Model Between Staff Augmentation and Managed Services

Last updated: September 30, 2026

By Tom Kenaley, President and Senior Partner, KORE1

Managed capacity is an engagement model where you pay a vendor a fixed monthly fee for a set-size team, point it at your own backlog, and let the vendor run, staff, and replace that team while you keep the priorities. It sits between staff augmentation, where you manage individual contractors by the hour, and managed services, where the vendor owns an outcome and you mostly stop seeing the people.

The federal government has bought work this way for decades. It just gave it a worse name. Much worse. In the Federal Acquisition Regulation it’s a firm-fixed-price, level-of-effort term contract. Try saying that in a budget meeting. The definition itself runs two lines. The contractor provides “a specified level of effort, over a stated period of time, on work that can be stated only in general terms,” and the government pays “a fixed dollar amount.” Swap “government” for “your company” and you have most of what the IT outsourcing market started calling managed capacity this year.

So it isn’t new. What’s new is that mid-market engineering leaders are asking for it by name, usually after a year of running six hourly contractors and discovering that managing them became somebody’s whole job.

A word on where I sit. KORE1 has placed contract IT people since 2005. We sell per-head staff augmentation services, and we also staff project and SOW teams where we run the pod. We make money either way. What follows is how the middle model actually works once the contract is signed, including the parts the vendor pages skip.

What Managed Capacity Means in a Contract

Managed capacity is a monthly subscription to a defined team, typically three to eight people with named roles, where the vendor is contractually responsible for keeping every seat filled, performing, and coordinated, and the client is responsible for deciding what that team works on. You buy throughput potential, not hours and not a finished deliverable.

Three things have to be written down for it to be the real thing.

The team shape. Not “five engineers.” A senior lead, two mid-level backend developers on Java and Spring, one React developer, one QA engineer with Playwright. Roles, seniority, and the stack, in the SOW.

Who replaces people, how fast, and who pays for the overlap. If the answer is “the client requests a replacement and the vendor makes reasonable efforts,” you bought staff augmentation with a monthly invoice.

And who runs the ceremonies. Somebody has to hold standup, groom the backlog with your product owner, and notice when the QA engineer has been blocked on a test environment for four days. In managed capacity that person is on the vendor’s payroll. Sometimes they’re a working tech lead. Sometimes a half-time delivery manager who covers two or three pods.

Miss any of the three and the label doesn’t matter.

Where It Sits Between Staff Aug and Managed Services

The cleanest way to see the middle is row by row, starting with what the invoice actually counts.

Look at the scope row, because it’s the one that makes the model worth anything. A managed services contract prices a scope, so a new priority is a change order and a negotiation. Managed capacity prices a team. If the priority moves from the claims portal to the billing API on a Tuesday, the team moves Tuesday. Nobody reopens the contract. The only limit is the team’s skills: a React-and-Java pod can’t suddenly become a Snowflake pod without a seat change. One common use is a standing team for patches, upgrades and L3 fixes, which keeps the product engineers on the roadmap.

We’ve written about the two ends separately, including a longer piece on staff augmentation versus managed services and what each one reprices after signature. There is also a three-way comparison that adds consulting. This post is only about the middle.

Delivery Risk, Split Into Its Pieces

Vendor pages say the vendor “owns delivery risk.” Some of it. Split the word “risk” into its pieces and read the SOW against each one, because the transfer is real on some pieces and marketing on others. Team risk (someone quits, someone underperforms, someone’s on medical leave for three weeks) moves to the vendor almost completely, and that’s the main thing you’re paying for. Ramp risk moves partially: a good SOW says replacements overlap with the person leaving for five to ten business days at the vendor’s cost, and a weak one says nothing, which means you pay for two people while one of them learns your codebase. Throughput risk moves a little, if the contract has a capacity-delivered clause, which I’ll get to. Product risk, meaning you asked the team to build the wrong thing well, never moves. Not in any version of this model. The vendor builds what your product owner put at the top of the backlog, and if that was a mistake, it was your mistake executed on schedule.

That last part matters more than it sounds. Outcome-based contracts try to move product risk too, by tying fees to a business result, and we’ve covered where outcome-based delivery works and where it breaks. Managed capacity deliberately doesn’t try. It’s a cleaner deal because of it.

A real example of the team-risk transfer, from last spring. A logistics software company in Ontario, California, had a four-person pod with us working a Node and React backlog for their carrier portal. Their senior developer, the one who knew the rate-shopping service cold, gave notice in week eleven. Under a per-head contract that’s the client’s problem to raise, approve a replacement, interview, and absorb the ramp. Under the capacity SOW it was ours. The replacement started nine business days later, overlapped with the departing developer for six of them, and the client paid for one seat the whole time. Their VP of Engineering heard about it in the Monday capacity review, after it was already handled. No interviews. No ramp invoice.

That’s the product. Honestly, most of it.

How Managed Capacity Is Priced

One monthly number. Underneath it is simple arithmetic, and you should ask any vendor to show it to you.

Here’s an illustrative US onshore pod, using seat rates inside the bands in our IT staff augmentation cost breakdown and a 173-hour billing month:

So the same four people cost about 22% more as managed capacity than as four hourly contractors. Is that a lot? Depends. That premium is the whole argument, in both directions.

What does the $15,666 buy? A person who runs the pod so your engineering manager doesn’t, and a vendor that has pre-funded its own replacement problem. Now price your alternative honestly. Take whatever your engineering manager costs you fully loaded. If it’s $20,000 a month and four contractors eat half their week, that’s $10,000 of management you’re already paying for under staff aug, just on a different line. The real gap shrinks to around $5,700 a month. Whether that’s cheap depends entirely on what your manager would do with the time back.

Some things belong inside the fee, and a vendor quote that pulls them out is a staff aug quote in disguise:

• Backfill for any seat that goes empty, including resignations, terminations, and long leave.
• Paid overlap during a handoff. Five business days is the floor we’d accept.
• The delivery lead’s time, all of it, including the hours spent in your planning meetings.
• Onboarding a replacement. You shouldn’t see a separate ramp charge. Ever.

And a few things usually don’t, which is fine as long as they’re written down: your cloud and tooling costs, travel, and any seat you add mid-term.

One clause buyers forget, and it costs them. Holidays and PTO. Under an hourly contract, a contractor’s week at the lake isn’t billed. Under a fixed monthly fee, you pay for that week unless the SOW says otherwise. The fix is a capacity-delivered clause: if the pod delivers less than, say, 95% of contracted hours in a month and the vendor didn’t cover the gap, the difference comes back as a credit. Ask for it by name. A vendor who resists it is telling you the fixed fee has slack built in for their benefit. Small clause. Real money.

Governance Without Micromanaging

The line between staff augmentation and managed capacity is really a line about supervision. The federal rules draw the same line, for their own reasons. FAR 37.104 says a service contract turns into a personal services arrangement, the kind agencies mostly aren’t allowed to buy, once government staff are directing the contractor’s people more or less nonstop. Borrow that test. It works for you too. If your engineering manager is assigning tickets to the vendor’s developers by name every morning, you’ve drifted back into staff aug, and you’re paying the managed capacity premium for it.

What you should control is narrower. Not the tickets. The backlog order. Acceptance criteria. Architecture decisions that touch the rest of your platform. Access. That’s it.

Two meetings. That’s the rhythm on most pods we staff. Your product owner and the vendor’s lead spend a half-hour each week on priorities, and once a month your engineering leader sits down for a capacity review that covers hours delivered against contracted, seat changes and what triggered them, throughput trend, and anything blocked on your side. Blocked-on-your-side is the item people skip. It’s usually the biggest one. Test environments, code review from your staff engineers, a security approval stuck in a queue. When a capacity team underdelivers, that’s where I’d look first.

On metrics, don’t put story points in the SLA. Points are an estimate the team produces, so tying the fee to them teaches the team to estimate higher. That’s Goodhart’s law, and DORA’s guidance on software delivery metrics warns specifically against setting metrics as goals. Use DORA’s measures (change lead time, deployment frequency, change fail rate, and failed deployment recovery time) as a trend you both watch, and keep the contractual commitments on things the vendor fully controls. Seats filled. Replacement time. Hours delivered.

Hourly staffing has the opposite problem. An hourly contract pays the same whether the contractor is efficient or not, so somebody on your side has to watch the work, and in most companies that somebody is your engineering manager’s calendar. Managed capacity moves most of the watching onto the vendor’s lead. Then it charges you for it.

When It Beats Per-Head Staff Augmentation

Four conditions. I’d want at least three before recommending it, and I’ve said no with two.

The backlog is long and steady. Six months minimum of work you can describe only loosely today, the exact situation the FAR definition was written for. A pod needs about a month to find its rhythm on an existing codebase, learning which tests are flaky and whose code review actually gates a merge, so a three-month engagement spends a third of its life ramping and you pay the management premium for all of it. Bad trade.

You need roles that have to work together. Three or more of them. One Salesforce admin doesn’t need a delivery manager. A backend developer, a frontend developer, and a QA engineer shipping the same feature do, and somebody has to own the handoffs between them.

Your managers are the bottleneck. This one is the tell. If your engineering manager already runs eight direct reports and you’re about to hand them five contractors, the math above stops being close.

And you can live with the vendor’s process. Their standup, their tracker conventions, their way of doing code review, within your guardrails. Some teams can’t. If you need every contractor inside your exact rituals, buy seats.

When it doesn’t beat staff aug, it’s usually obvious. One or two specialists filling a hole in a team you already run well: hourly contract staffing is cheaper and simpler. A defined deliverable with a hard date, like a migration or a go-live, is better bought as a fixed-scope project staffing engagement, where the team rolls off when the thing ships. If a statement of work is on the table, our guide to how SOW engagements get priced compares the pricing structures side by side. Keep-the-lights-on operations with ticket SLAs belong in managed services. And a core platform team you intend to own in two years should be hired permanently, not rented, however you bridge to it.

We’ve talked clients out of capacity deals for each of those reasons. It isn’t a better model. It’s a narrower one that fits a common situation very well.

What Finance and Engineering Each Want to Know

Is managed capacity just a dedicated team with a new label?

Close, and the difference is who manages. A dedicated team gives you named people who work only for you, but you usually direct them yourself, while managed capacity adds a vendor-side lead and makes seat replacement the vendor’s contractual problem.

In practice vendors use both labels loosely. Ignore the name on the proposal and read the replacement clause.

Realistically, what does a four-engineer pod cost per month?

$75,000 to $95,000 a month for a typical US onshore pod of four engineers plus a part-time delivery lead, based on seat rates we bill in 2026.

Senior-heavy pods in specialized stacks (Guidewire, SAP, or ML platform work) run well above that. Nearshore pods usually land lower. The premium over the same seats billed hourly is usually 15% to 25%.

Can we swap someone out, or add a sixth seat mid-quarter?

Swapping a person is part of what you’re paying for, and adding a seat is normally a written amendment with 30 days’ notice and a new monthly fee.

Removing a seat is the one to negotiate up front. Most capacity SOWs lock the team size for a minimum term, often 90 days, because the vendor has committed people. Ask what a step-down costs before you sign, not when budget season arrives.

Who owns the code?

You should, and the MSA needs to say so in plain assignment language, not “work for hire” alone.

That gets trickier when the vendor’s people are 1099 subcontractors rather than W-2 employees. We wrote a separate piece on who owns contractor-written code because it trips up more buyers than pricing does.

What happens if the team misses a sprint goal?

Usually nothing contractual. Managed capacity commits the vendor to a staffed, functioning team, not to a feature list.

That surprises people. If a missed sprint traces to the vendor (a seat left empty, a lead who didn’t escalate a blocker), it shows up in the capacity review and the credit clause. If it traces to changing priorities or a blocked environment on your side, that’s the model working as designed. You kept the steering wheel. You also kept what happens when you turn it.

How long until a new capacity team is actually productive?

Four to six weeks for a pod joining an existing codebase, and faster when at least one member has worked in your stack before.

Getting the people is the quicker part. Our IT searches close in 17 days on average, which puts a four-seat pod in place within about a month of the SOW. The ramp after that depends mostly on your access provisioning. Laptops, VPN, repository permissions. We’ve watched a team lose its whole second week to a single pending security approval.

Sketch the Pod Before You Pick the Model

Start with the shape of the work, not the model. Write down the roles you’d need for the next two quarters and who on your side would manage them. If the answer to the second question is “the same overloaded person,” price a capacity deal next to the hourly one and compare the real numbers, management time included.

When a vendor promises to keep seats filled, ask what its retention looks like, because that’s the promise in numbers. Ours is 92% at twelve months, on contract and project teams in 30-plus metros. If you want the arithmetic run against your own backlog, talk to our project team staffing group and bring the role list.