Staffed vs shipped: when new capacity starts delivering

Why does new capacity not convert into delivery immediately?

Because a new engineer starts as a cost to the receiving team before becoming a contributor to it. That cost is normal, predictable and plannable. What makes it damaging is pricing it at zero.

Where the first weeks go:

• Access. Accounts, permissions, environments. Administrative, and therefore easy to postpone until day one.
• Codebase. Conventions, structure and the reasoning behind past decisions, most of it undocumented.
• Review load. Early pull requests get reviewed by people who already have a queue.
• Domain knowledge. It moves through conversation, at the pace of whoever holds it.

This is where a provider earns its fee. Shortening that period is real work: pre-briefing the engineer on the client's stack and domain, preparing access before day one, and keeping someone accountable for integration after the start date rather than at it.

The evidence points the same way. In a study published in IEEE Transactions on Software Engineering, researchers at Google surveyed 622 developers across three companies and found that the factors correlating most strongly with self-rated productivity were non-technical ones: job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. The finding carries caveats. It measures self-rated productivity rather than output, and the paper dates from 2019, so read it as a durable signal about working conditions rather than a current benchmark.

The conditions around an engineer sit partly in the client's team and partly in the provider's people model. They are either designed or left to chance.

How do you measure whether a team is actually shipping?

Use DORA's software delivery performance metrics. DORA is a research programme run by Google Cloud, and it now works with five metrics split into two groups.

One detail worth keeping straight: DORA places failed deployment recovery time under throughput, not under stability, which is where most secondary summaries put it.

The definitions are the easy part. What follows changes how the numbers should be used.

Speed and stability are not opposites. DORA's research finds that the metrics correlate for most teams, with top performers doing well across all five and low performers doing poorly across all five. A team that ships slowly is usually not buying safety with the delay.

The metrics belong to an application, not to a person. DORA is explicit that they are best suited to one application or service at a time, and that blending them across teams or comparing very different systems can mislead. Attached to an individual engineer, especially a new one, they produce a number that describes the pipeline and gets read as a verdict on a person.

Targets corrupt them. DORA lists setting metrics as a goal, in the style of "every application must deploy multiple times per day by year end", as a common pitfall. It invites teams to play the measure instead of improving the system.

The way to use them when adding capacity is simple. Take a baseline before the new people arrive, then look again after a full quarter. The question is whether the system delivers more than it did before, and whether it broke more often while doing so.

Which signals show that delivery has started?

The first standup, the first pull request, the first release and the first check-in. Each proves that a specific piece of the integration worked, and together they tell you more in the first month than any status report.

The first standup. Presence on day one. It sounds trivial until it fails, and when it fails the cause is almost always administrative: accounts, repository permissions, VPN, calendar invitations.

Integration isn't a phase. It's day one. Which means the administrative work behind it has to be finished before the engineer arrives, and owned by someone before there is anyone to own it for.

The first pull request. Small, reviewed and merged. This is the first hard evidence that context transfer worked, because code that fits an unfamiliar codebase requires conventions nobody wrote down. A first pull request that is large and slow to review usually means the engineer got a task before they got context.

The first release. A change containing the new engineer's work reaches production. This is the moment staffed becomes shipped, and it is the first data point that belongs in a delivery conversation rather than a recruitment one.

The first check-in. A structured conversation about how the engagement is going, held with someone whose job is the engineer's experience rather than the ticket queue.

At KWAN that person is the People Experience Partner, assigned to every engagement from the start. The role sits outside the delivery line on purpose. A PEP does not run the backlog and does not report to the client's engineering manager, which is what makes it possible for an engineer to say early that the work is not what was described, or that nobody has given them anything to do yet.

That separation is the whole value. Continuity problems announce themselves months before anyone resigns, usually as small signals with no channel to travel down. A check-in cadence turns them into something a client can act on while acting is still cheap.

It is also the least abstract definition of governance available in a staffing arrangement: a named person, a fixed cadence, and a conversation that happens whether or not anything is on fire. More on how the role works in People Experience Partners: what they are and how they benefit your business.

Those signals are the evidence. What produces them is a different list: capability, context, access and continuity, the four assets set out in The Shipping Season Playbook, which also covers how to work out a realistic shipping window and test each new role against one question: will this capacity ship before year end?

Timing deserves honesty. These milestones cluster in the first weeks, and the exact week depends on the codebase, the release cadence and the review capacity of the receiving team. A partner promising a specific day is describing a sales process. What a client can require is that each moment is expected, watched, and explained when it slips.

For a view of the same weeks from the engineer's side, KWAN covered it in what integrated feels like: a nearshore engineer's first 30 days.

What should you require from a partner in the first 30 days?

Ask questions that have answers with names and dates attached, rather than adjectives.

• Who is accountable for this engineer's integration after the start date, and what is that person's name?
• What will be in place on day one: accounts, repository access, environment, calendar?
• Which delivery signal will we look at in week two, who reports it, and to whom?
• What happens, contractually and practically, if the fit is wrong in month two?
• What is your talent continuity rate, how is it calculated, and what does it exclude?

KWAN's answers, for the record:

• Who owns integration: a named People Experience Partner on every engagement.
• Continuity: roughly 70% talent continuity rate (excluding internalisations). The exclusion matters, because engineers hired directly by the client are a good outcome that would otherwise flatter the figure.
• Employment: most consultants are KWAN employees, which makes continuity a company responsibility rather than a market outcome.
• Security and privacy: ISO/IEC 27001 and ISO/IEC 27701, with a certified scope covering contracts, talent management and IT outsourcing of consultants.

There is a longer version of this checklist in IT staff augmentation: 7 things to check before a long-term engagement, written for engagements that will run past a single quarter.

How fast can KWAN put someone into a team, and what cannot be compressed?

First vetted profiles in under five days, a full recruitment process closed in around three weeks, and then a start date that depends on the person. Those numbers get collapsed into one in most sales conversations, and keeping them apart is the difference between a plan that holds and a plan that slips.

• Under five days: first vetted profiles presented. From a brief clear enough to source against. This is where a pre-vetted pipeline earns its keep, because a provider that starts sourcing when the brief lands cannot do it.
• Around three weeks: the recruitment process closed. From brief to signed offer, covering requirements, engagement terms, interviews and selection.
• Then the start date, which depends on the person. Someone available between engagements can start almost immediately. Someone employed elsewhere works to a notice period.

Those are KWAN's own figures rather than a market benchmark, and worth asking any shortlisted partner to match phase by phase. A supplier answering with one number for all three is describing a hope.

Those timings assume conditions worth naming at kick-off: a role scoped clearly enough to source against, decision-makers free for interviews in the same week, and a stack where vetted profiles already exist. Rare or highly specialised skills take longer, and so does a brief that keeps moving, or feedback that arrives a fortnight later. Response time on each side moves the three weeks more than anything a provider controls alone.

The last phase is the one nobody controls. A notice period sits between the candidate and their current employer: partly set by contract, partly by law, and sometimes shortened when the employer agrees to release someone early. That decision is theirs. Where a start date has to be soon, the honest route is to look first at who is already available, which is why KWAN publishes an available talent list.

On sustained pace, KWAN's published work with Critical TechWorks covers 66 professionals integrated over two years, 24 of them within a single six-month period.

Does the solution type change when delivery starts?

The signals stay the same, though where they show up differs between IT Staffing & Team Augmentation, where the first pull request happens inside the client's own process, and Dedicated Teams, where early delivery appears at team level.

Turning a hiring decision into a shipping quarter

If the roadmap for this quarter depends on capacity that does not exist yet, the useful conversation is about what has to be true in the first weeks for those people to produce a release.

Two ways to start it. Work through the maths independently with The Shipping Season Playbook, which ends in a checklist for testing a role against the year-end date.

Or tell KWAN what the roadmap needs. The answer will come with the timeline, the constraints, and the parts that cannot be compressed.

Frequently asked questions

1. What does "staffed" mean compared with "shipped"?

Staffed means a role is filled: a contract exists and a person has started. Shipped means a change written by that team reached production. Between them sit access, context transfer and the receiving team's capacity to review and release, which is why a fully staffed quarter can still deliver nothing.

2. How long before a new engineer contributes to delivery?

It depends on the codebase, the release cadence and the review capacity of the receiving team, so watch the sequence rather than a fixed date: presence at the first standup, a small merged pull request, then a release containing their work. If the first pull request has not merged after several weeks, the cause is usually context or access rather than capability.

3. Which metrics show whether new capacity improved delivery?

DORA's five software delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Take a baseline before the capacity arrives, then compare after a full quarter at the level of one application or service. DORA advises against blending these across different teams or systems.

4. Can an IT staffing partner guarantee a start date?

A partner can commit to the phases it controls: KWAN presents first vetted profiles in under five days and closes a full recruitment process in around three weeks, up to a signed offer. The start date itself depends on the person, because a notice period is agreed between the candidate and their current employer. The way to protect a hard deadline is to ask which candidates are available now, before the shortlist is built.

5. What is a talent continuity rate and why does the exclusion matter?

A talent continuity rate measures how many placed engineers stay with the client team over time. KWAN reports roughly 70% (excluding internalisations), so engineers hired directly by the client are taken out rather than counted as departures. Ask any provider for the figure and its exclusions, because the definition does more work than the percentage.

Written for engineering and technology leaders planning the fourth quarter. If one part of the delivery timeline is the real constraint, that is a better place to start than a role count.