In this article
Before you start
This question belongs to the people-and-delivery part of the engineering manager interview guide; the people management round shows where it usually sits.
Why interviewers ask this
A delay answer shows whether a manager can protect the plan and the team at the same time. The question is reported by candidates in engineering manager (EM) loops, and it separates people who react from people who diagnose.
A weak answer says "we work harder and add people." It treats the delay as a speed problem and hides it until the deadline. A strong answer measures the slip, names the cause, offers choices with their costs and tells stakeholders early. A Staff-level answer adds the limits of each choice, especially the limit on adding people, and ties the plan back to how the team works day to day, as in your management philosophy.
Handling a delayed project from first principles
- Schedule compression
- Schedule compression is the set of techniques that shorten a project's duration without changing its scope, such as adding resources or overlapping tasks, and it only pays off when applied to critical-path work.
- Brooks's law
- Brooks's law is a rule of thumb from Fred Brooks's book The Mythical Man-Month that adding people to a late software project makes it later, because newcomers need time to become productive and everyone must stay in sync.
In plain words
Picture a road trip that is running late. You can drive faster, which costs fuel and adds risk. You can skip a stop, which changes what the trip delivers. You can bring a second driver, so the car keeps moving through rest stops. The analogy breaks here: a second driver helps at once, while a new engineer needs weeks to learn the code before adding speed.
In one precise sentence, a strong answer confirms how late the project is, finds the cause on the critical path, chooses a lever (cut scope, overlap work or add people), tells stakeholders early with options and re-baselines the plan.
Step 1: Confirm the slip and find the cause
A manager starts by measuring how late the project is and why, because the right fix depends on the cause. Check first whether the project is truly late or whether the original schedule was too optimistic; the Brooks's law article notes that scheduling mistakes account for many late projects.
Then sort the cause. Typical causes are an optimistic estimate, scope that grew, a blocked dependency on another team, or lost capacity from attrition or a production incident. A late task only matters if it sits on the critical path, because compression has to target critical-path activities to shorten the project. Input: the plan and the status. Output: a named cause and the amount of critical-path time at risk. You now know what to fix, so the next step is how.
Step 2: Choose a lever: cut scope, overlap work or add people
A manager has three levers, each paid in a different currency: scope, risk or coordination. Cutting or renegotiating scope changes what ships; this is a separate lever from schedule compression, which by definition keeps scope fixed.
Compression has two classic forms, both defined in the Project Management Institute (PMI) Lexicon. Adding resources is called crashing and almost always costs money. Running tasks in parallel is called fast tracking and often raises risk, because work that was meant to follow another task starts before its input is final. Asana notes that the cost of crashing is harder to measure in knowledge work such as software development.
Adding people is the lever with the trap. Brooks wrote in his 1975 book that adding manpower to a late software project makes it later, a rule set out in chapter 2 of The Mythical Man-Month, anniversary edition (1995), because new people need ramp-up time. In the anniversary chapter "The Mythical Man-Month after 20 Years" Brooks called it an outrageous oversimplification, so the answer is "it depends on timing and on whether the work divides."
Step 3: Tell stakeholders early, with options, then re-plan
A strong answer tells stakeholders about the delay as soon as it is clear, with two or three options, not at the deadline. Each option states what it costs (scope, risk, money or people's time) and the date it delivers. Recommend one and say which decision you need and by when.
After the decision, re-baseline: write the new dates, update the dependency list and set a short, regular check so a second slip shows up early. Keep the team in the loop as well, since overtime as a hidden fourth lever burns capacity you will need later; the team health page covers how to read that signal. Input: the options and their costs. Output: a decision, a new plan and a rhythm of updates.
Step-by-step description
- Confirm the slip and find its cause.
- Scope, overlap or people, each with a cost.
- Tell stakeholders early, then re-baseline.
- A strong answer confirms how late the project is and finds the cause on the critical path.
- It chooses a lever: cut scope, overlap work or add people.
- It tells stakeholders early with options and re-baselines the plan.
What each lever buys on a twelve-week plan
A hypothetical project shows how the levers compare in weeks. The plan is twelve weeks. At the end of week eight, seven weeks of critical-path work remain (illustrative), so the project would finish in week fifteen, three weeks late.1
Fast tracking two weeks of that work leaves five weeks, so it finishes in week thirteen. Cutting one week of critical-path scope finishes in week fourteen. Overlapping two weeks and cutting one week of scope recover all three weeks, finishing in week twelve.1
For adding people, assume five engineers, thirty-five person-weeks of remaining work and three joiners (illustrative). With a two-week ramp and a twenty percent capacity loss for the existing five, the project ends about 1.4 weeks late. With a five-week ramp and a fifty percent loss, it ends about 3.8 weeks late, worse than doing nothing, even though these cases assume the work divides perfectly.1 If the remaining work is one sequential chain, extra people change nothing and the project stays three weeks late.1
| Option | Assumption (illustrative) | Finish week | Weeks late |
|---|---|---|---|
| Do nothing | Seven weeks of critical-path work remain | 15 | 3 |
| Overlap two weeks of work | Rework risk accepted | 13 | 1 |
| Cut one week of scope | Stakeholders agree | 14 | 2 |
| Overlap and cut | Both levers | 12 | 0 |
| Add three people, quick ramp | Two-week ramp, 20% capacity loss | about 13.4 | about 1.4 |
| Add three people, slow ramp | Five-week ramp, 50% capacity loss | about 15.8 | about 3.8 |
| Add three people, work cannot split | One sequential chain | 15 | 3 |
Text description of the diagram
- Overlapping work and cutting scope together recover all three weeks.
- Adding people with a slow ramp ends about 3.8 weeks late.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
What do you do when the project gets delayed?
First I confirm how late we really are and whether the plan was optimistic, then I find which critical-path work is slipping and why. Then I choose a lever. I can cut or defer scope, overlap work that is normally sequential and accept the rework risk, or add people, but late additions often cost more in ramp-up and coordination than they return, so I add early or only for work that splits cleanly. I take two or three options with their costs to stakeholders as soon as I see the slip, not at the deadline, then re-baseline and check weekly.
What makes it Staff-level: it names the cause before the fix, gives each lever a cost, states the limit of adding people, and commits to early communication.
The rubric
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Diagnosis | Assumes the team is slow and pushes harder | Checks how late and why, including an optimistic estimate | Separates estimate, scope growth, dependency and capacity causes, and fixes the cause |
| Levers | Adds people or overtime by default | Names scope, overlap and people, with a cost for each | Targets critical-path work only and states each lever's risk |
| Communication | Tells stakeholders at the deadline | Tells them when the slip is clear, with options | Brings a recommendation, the decision needed and its date |
| Trade-offs | States none | Says what each option costs | Ties options to team capacity and the real deadline |
| Follow-up readiness | Stumbles on "would you add people?" | Cites Brooks's law with its limits | Explains when adding people works (early, divisible work) and when it does not |
Three variants of this question
Tell me about a time a project you led was delayed
Interviewers usually ask this as a past story, and the answer uses the same three steps as a situation, action, result story. The result must include what you changed afterwards. Here is an illustrative example, a third-person composite with no company named.
- Weak: the manager says the release was hard, the team worked weekends and the project shipped a month late.
- Strong: the manager says a billing migration planned for twelve weeks showed, at week eight, seven weeks of critical-path work left because another team's work was blocking it. She told the product lead that day with three options, cut one reporting feature, overlapped two weeks of testing and shipped in week twelve. Afterwards she added a weekly dependency check and a buffer to estimates.
What do you do if you find the delay a week before launch?
At that point the useful levers are scope and the launch plan, not people, because newcomers cannot ramp up in time. Tell stakeholders immediately, propose a reduced first release with the rest to follow, and name the risk of each cut.
What if the stakeholder refuses to move the date or the scope?
Then the only remaining currencies are risk and people, so say that plainly. Show what overlapping work or extra effort would cost in rework and burnout, and ask the stakeholder to choose which cost they accept in writing.
Common mistakes
- "We just add more engineers to catch up." (wrong) Late additions need ramp-up and add coordination, and Brooks's law says this often backfires. (right) "I add people early or for work that divides cleanly, and I cut scope or overlap work first."
- "The team is slow, so I ask for overtime." (wrong) The estimate may have been optimistic, and overtime hides the real cause. (right) "I check whether the plan or the pace was wrong before choosing a fix."
- "Crashing and fast tracking are the same thing." (wrong) They are different levers. (right) "Crashing adds resources and cost; fast tracking overlaps tasks and adds risk."
- "I would shorten the schedule by cutting scope, which is compression." (wrong) Compression keeps scope fixed. (right) "Scope is a separate lever, and I renegotiate it with the product owner."
- "I tell stakeholders once I have a fix." (wrong) They lose the time to choose. (right) "I tell them when the slip is clear and bring options."
Follow-up questions
Does Brooks's law mean you should never add people to a late project?
No. Brooks called it an outrageous oversimplification in the anniversary edition of The Mythical Man-Month, and the law is about projects that are already late. People added early, or on work that divides well, can be absorbed; the Brooks's law page lists ramp-up time and communication as the costs.
What is the difference between crashing and fast tracking?
Crashing adds resources and usually costs money; fast tracking performs tasks in parallel and raises risk. Both shorten the schedule without changing scope.
How do you tell stakeholders about a delay?
Do it as soon as the slip is clear, with the cause, two or three options, their costs and your recommendation. Say what decision you need and by when, then follow up in writing.
How do you know if the project is really late or the estimate was too optimistic?
Compare the plan with the work actually required and with similar past work, and check it with the team in one-on-ones. Optimistic schedules are a common cause of lateness, and if the plan was the problem, adding effort does not fix it.
What if the new people join in week two instead of week eight?
Early additions have more time to pay back their ramp-up, so the case for adding people is much stronger. The same ramp-up cost applies, but it is spread over a longer remaining schedule. To handle the people side of a struggling team, see how to handle a low performer and growing engineers.
- Confirm the slip and find the cause first; the plan may have been optimistic.
- Compression shortens the schedule without changing scope and works only on critical-path tasks.
- Crashing adds cost; fast tracking adds risk; scope is a separate lever.
- Adding people late often backfires, but it is not absolute.
- Tell stakeholders early with options and a recommendation, then re-baseline.
Sources
- PMP Exam Tip: Crashing & Fast Tracking explained — Project Management PrepCast (quotes the PMBOK Guide), 26 Oct 2026
- The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (ISBN 0-201-83595-9) — Addison-Wesley (Brooks), 1 Jan 1995
- PMI Lexicon of Project Management Terms — Project Management Institute, 26 Oct 2026
- Brooks's law — Wikipedia (summarises Brooks, The Mythical Man-Month, 1975), 4 Sep 2026
- Fast Tracking vs Crashing — Asana, 26 Oct 2026
- Schedule compression — Wikipedia, 26 Oct 2026
