At the end of a planning meeting, the work, the people and the dates appear to fit. I’m all for enjoying it. Briefly.
Now suppose an incident pulls away the engineer who was meant to review a release. Another project needs the same specialist. Friday’s date has stayed exactly where it was.
You can leave three meetings with three reasonable commitments and still have more work than one team can do. The team still has one 100%.
Keeping those commitments workable means deciding what can move, with the people doing the work and those depending on it.
1. Count the work that does not look like a project
Mentoring, incident response, code reviews and helping other teams all use capacity. Leaving them out makes the roadmap look wonderfully achievable.
Before planning the next two weeks, look back at the last two with your team. Count the incidents handled, the mentoring time and the reviews for other teams. Calendar and ticket histories give you a starting point; ask what those records missed.
Put that work beside the projects when you discuss capacity. Recurring support needs an allowance in the plan, and an unusually demanding week may require a different set of commitments.
Where two projects depend on the same specialist, agree on the order of work with the other project owners before either plan assumes that person is available.
2. Plan through to running the thing
“Code complete” can leave plenty of work before a customer gets anything useful.
For that Friday release, the remaining work might include testing an external integration, verifying the rollback procedure and arranging support during rollout. Those jobs need time and owners before Friday becomes a commitment.
Trace the work from design and implementation through review, integration, testing and rollout. Include rollback and support. Agree who owns each handoff, and check external commitments with the people expected to meet them.
A coding agent can draft a first pass from the feature brief and repository context, flagging unknowns and citing relevant files. Review it together and allow time to verify the output.
Once work is under way, watch where it queues. If completed changes are waiting for review, redirect capacity toward finishing them before asking the team to start more features.
3. Change the plan when its assumptions fail
Suppose the external integration fails testing on Tuesday. The core workflow passes, but the full release now needs an investigation that was never in the estimate.
Ask the team whether the core workflow can ship safely on its own. What would separating it take? What remains unknown about the integration? Use those answers to decide whether to narrow scope, resequence work, arrange help or revise the date.
“We’ll absorb it” needs an explanation of how. Which work will move, and who needs to agree?
Staffing changes need the same attention. After layoffs, find critical tickets still assigned to someone who has left. Check the runbooks and recurring responsibilities too: an updated ticket board will not tell you everything that person used to handle.
Confirm coverage with the team, assign temporary owners where needed, and set a date to review the arrangement. Revisit the commitments those people already had. Giving a responsibility a new owner does not make room for it in that person’s week.
4. Communicate while people can still help
The integration problem is worth raising while product can still choose a smaller release. Waiting for a perfect estimate can use up the time available to make that choice.
If the team confirms that the core workflow can ship separately, the update could be:
The integration issue puts Friday’s full release at risk. The core workflow has passed testing, so I recommend releasing that first. We need product’s agreement by Wednesday. I’ll update the remaining scope estimate after tomorrow’s investigation.
Follow through on that request. If the decision is overdue, escalate it and explain what the delay means for Friday.
If the team is already behind, agree on a revised forecast with the people doing the work and explain its basis to stakeholders. Where uncertainty remains, give a checkpoint and say what you expect to learn.
When an engineer flags a risk, make the call, arrange help or accept a consequence. Repeatedly replying “find a way” makes the next warning less likely.
5. Remove work that no longer needs doing
I’d start with the meetings and approvals I ask of other people. It is easy to recommend efficiency from the side of the table that creates the work.
Who uses the report? Does every change need this approval? Could somebody else make the decision I keep insisting on reviewing?
Choose one recurring obligation and agree with the relevant owner on what can be simplified or stopped. For an old feature, check usage and obligations with the team before proposing retirement. Estimate the migration work too; removing a feature can create work before it releases capacity.
If a gap remains, resolve the choices within your authority and take the rest to the appropriate leader with a recommendation. Give the team a clear account of what it is still expected to deliver.
Before your next planning meeting, pick one commitment and ask the team what work it depends on that is missing from the plan. Agree what you will change if that work needs more time. Bring that choice into the meeting before accepting another commitment.