A new engineer hasn't shipped yet: how to find where delivery is stuck

Why is "nothing shipped yet" hard to diagnose?

Because the same result comes from very different causes, and in the first weeks most of them sit outside the engineer's control. An engineer without repository access, a pull request waiting days for review and a team that releases once a month all look identical in a status report: nothing shipped.

Skipping the diagnosis has a concrete cost. A setup problem treated as a performance problem leads to a replacement, and the next engineer walks into the same missing access and the same review queue. A performance problem treated as a setup problem costs another month.

KWAN's article on staffed vs shipped sets out the four delivery signals in the order they usually appear. Each signal depends on the one before it, so the first missing signal is where the diagnosis starts.

Where the bottleneck appears also depends on how capacity was added. An engineer joining an existing team depends on that team’s access, review and release process. A dedicated squad brings more of its own delivery rhythm, so the constraints tend to move to the interfaces with the client: decisions, dependencies and release approvals.

What does a weak first standup tell you?

It tells you the engineer is present but not yet equipped. When a new engineer has little to say at standup in the first days, the cause is usually one of two things:

• Access is still pending. Accounts, repository permissions, environments or VPN haven't arrived, so there is no real work to report on.
• There is no scoped first task. The engineer has access but nothing specific to pick up, so the update is about reading documentation.

The receiving team owns both. A staffing partner can prepare a lot before day one, such as briefing the engineer on the stack and domain and chasing access requests, but it cannot grant permissions inside the client's systems.

The question to ask by day two or three is simple: "What are you blocked on, and who have you asked?" If the answer is a ticket in an IT queue, escalate the ticket. If the answer is nobody, name a person.

Why hasn't the first pull request merged?

Look at where the pull request is. A first pull request tends to get stuck in one of three places, and each needs a different fix.

It hasn't been opened. The task is usually too big or too vague for someone without context. Swap it for a smaller change with a clear definition of done: a bug with a reproducible case, or a missing test for behaviour that already exists.

It's open and waiting for review. This is a capacity question for the receiving team. Google's published engineering practices set one business day as the maximum time to respond to a code review request. A new engineer waiting several days for a first response loses context and momentum, and starts the next task with the first one still open.

It's open with round after round of comments. Most early review comments are about conventions nobody wrote down. An hour of pairing, or pointing the engineer to recent merged pull requests as reference, tends to shorten this faster than more review rounds.

For the same moment from the engineer's side, KWAN covered how to ship a first pull request on a codebase you just joined.

Why has merged work not reached users yet?

Because merging and releasing are separate events, and the gap between them belongs to the release process. If the team releases on a fixed cycle, a new engineer's first release can't come before the next cycle, whatever their pace.

Other common reasons merged work waits:

• The change sits behind a feature flag nobody has switched on.
• It depends on work from another team that hasn't landed.
• The engineer has no visibility of the release pipeline, so nobody noticed the change missed it.

The question to ask is: "When is the next release, and is this change in it?" If the answer is weeks away, that is a planning fact, and it belongs in the plan rather than in a conversation about the engineer.

What should you do when a check-in raises something the team hasn't seen?

Treat it as the earliest version of a delivery problem. Some things an engineer will say at a check-in long before they say them at standup:

• The work is different from what was described at interview
• They spend more time waiting for tasks than working on them
• They don't know who to ask about the domain
• The work doesn't match the seniority of the role

At KWAN, the check-in is the job of the People Experience Partner assigned to every engagement. The PEP sits outside the delivery line on purpose: no backlog, and no reporting line into the client's engineering manager. That separation is what makes it possible for an engineer to raise these things while they are still small.

For the client, the useful response is a short conversation about what came up and who acts on it, before it turns into missed sprints.

How do you tell a setup problem from a fit problem?

Fix the setup first, then watch the next signal. If access is in place, the first task is scoped, reviews come back within a day and a release is within reach, and the next signal still doesn't come, the question becomes fit: the profile, the seniority or the domain may not match the work.

Raising a fit concern in the first month costs far less than raising it in the fourth. Ask your partner before you need it what the replacement route is and how long it takes.

It is also worth asking how the partner measures whether engineers stay. KWAN reports a talent continuity rate of ~70% (excluding internalisations), which means engineers hired directly by the client are taken out of the figure rather than counted as departures.

A diagnostic table for the first weeks

Use this when a new engineer hasn't shipped yet. Start from the last signal that happened and read across.

Does the diagnosis change with a Dedicated Team?

The sequence stays the same, and the unit changes. With IT Staffing & Team Augmentation, the signals happen per engineer, inside the client's own team and process, so the table above applies row by row.

With a dedicated team, the signals show up at team level: the squad's first planning session with the client's product owner, its first merged change and its first release. What changes is where things get stuck. Inside a squad, conventions and reviews are shared from day one, so the pull request stage often moves faster. The stalls move to the boundary with the client:

• Decisions. Product questions wait for someone on the client side who hasn't been given time for them.
• Dependencies. APIs, data or environments owned by other client teams arrive later than planned.
• Release. The squad's work still goes through the client's approval and release process.

For a squad, the question at each stage shifts from "who is reviewing this?" to "what is the squad waiting for from us?". More on how Dedicated Teams are set up, and on what each model looks like in its first two weeks, in KWAN's guide to team extension vs dedicated squads.

How do you keep the diagnosis repeatable when several people join?

Fix each cause at process level the first time it appears. If repository access took a week for the first engineer, it will take a week for the next one too, unless someone changes how access is requested.

A light way to see the pattern is to note the date of each signal for every new starter. After two or three people, the stage where time leaks tends to be obvious, and it is usually the same one each time.

This matters most when capacity arrives in waves. KWAN's work with Critical TechWorks covered 66 professionals integrated over two years, 24 of them within a single six-month period. At that pace, a setup problem that isn't fixed once gets repeated with every person who joins.

If one of the signals hasn't come

Start with the table. Find the last signal that happened, ask the question in that row, and give the answer a few days to work before looking further down the sequence.

If the real constraint is planning rather than setup, for example a role that has to ship before year end, The Shipping Season Playbook works through the maths of a realistic shipping window.

And if you'd like a second view on where a stall sits, tell KWAN which signal is missing and the team can look at it with you.

Frequently asked questions

1. How long should it take a new engineer to open their first pull request?

Days rather than weeks, for a small and well-scoped first task. The size and clarity of that task matter more than the engineer's speed. If nothing has been opened after the first week or two, check access and task size before anything else.

2. When nothing has shipped, is the problem the engineer or the team?

Often both parts of the system are involved, which is why the order of signals matters. Check access, task scope, review response and release timing first, because those sit with the receiving team. If all four are in place and the next signal still doesn't come, look at fit.

3. What is a reasonable code review response time for a new engineer's pull request?

Google's published engineering practices set one business day as the maximum time to respond to a code review request. That is a response, not necessarily an approval. For a new engineer, a slow first response costs more than usual, because they are still building context.

4. What's the difference between merged and released?

Merged means the change is accepted into the codebase. Released means it has reached users through the team's release process. A change can be merged and still wait for the next release cycle, a feature flag or another team's dependency.

5. When should you raise a fit concern with a staffing partner?

Once the setup is fixed and the next signal still hasn't come. Raised in the first month, a fit concern is a conversation about the profile. Raised months later, it is also a delivery delay and a continuity problem.