Developer Workload Rebalancing Strategy
When a developer's queue becomes overloaded — or when high-priority tasks are deprioritized without AM awareness — the team uses a structured rebalancing approach to redistribute work without losing momentum on client commitments.
The Core Problem
Overload situations typically surface in sprint planning when a developer has accumulated too many tasks, has allowed lower-priority work to crowd out high-priority deliverables, or has unilaterally changed due dates to manage their own queue. All three of these are signals that rebalancing is needed.
Key rule: Developers cannot change task due dates without Account Manager approval. Due dates reflect client commitments and meeting schedules that the developer may not have full visibility into.
"Please do not change due dates without talking with the AM. I have a meeting with the client, blah, blah, blah." — Melissa, 2026-01-22 sprint planning
Rebalancing Process
1. Audit the Overloaded Developer's Queue
Review the developer's current task list and identify:
- Tasks that are genuinely in-progress vs. tasks sitting idle
- Tasks currently in client review (these don't require active developer time)
- Due dates that have been changed without AM approval — restore these immediately
- Which tasks are highest priority based on client commitments
2. Identify Tasks That Can Be Reassigned
Good candidates for reassignment are:
- New page builds that are templated or well-documented (low ramp-up time for another developer)
- Tasks where another developer already has site access or platform familiarity
- Tasks that are not yet started and have flexible timelines
Poor candidates for reassignment:
- Tasks with complex, client-specific logic the original developer already understands
- Tasks where access provisioning would cause more delay than keeping the original assignee
3. Match Tasks to Developer Capacity and Expertise
Check the receiving developer's current workload before assigning. Also consider platform expertise:
- Assigning a Salesforce Account Engagement email build to a developer unfamiliar with the platform will create delays — pair with someone who knows it, or assign to the developer who built the original system
- Templated page builds (e.g., location pages) are generally safe to hand off with good documentation
4. Ensure Content Is Ready Before Assigning
A common blocker: tasks are assigned but the developer has no content to work from. Before reassigning or unblocking a task, confirm:
- Content doc is attached to the task
- Copy is finalized or a clear draft exists
- The developer knows who to contact if they have questions
If content is missing, extend the due date accordingly and note the reason.
5. Communicate the Handoff Clearly
When reassigning a task:
- Note in the task description who the original developer is and that they can be consulted
- Confirm the new developer has site/platform access
- Set a realistic due date based on when content will be available, not an aspirational date
Case Study: 2026-01-22 Sprint Planning
Situation: Jeff's queue was overloaded. The Seamless page build had sat untouched for two weeks while other tasks took precedence. Jeff had also changed the Seamless due date without AM approval, which conflicted with a scheduled client meeting.
Actions taken:
| Task | Original Assignee | Resolution |
|---|---|---|
| Seamless page build | Jeff | Kept with Jeff; restored original due date; made top priority |
| Next Level site | Jeff | Kept with Jeff; Karly to provide missing email copy and recategorization instructions |
| Overhead location pages | Jeff (planned) | Reassigned to Raphael; Sebastian to provide content by end of following week |
| Advanced Health & Safety location pages | Jeff | Reassigned to Raphael; Melissa to update task assignment |
| Cora Italia email build (Salesforce) | Raphael (stalled) | Unblocked — Karly to attach missing content doc; due date extended one week |
| PaperTube email build | Raphael (planned) | Reassigned to Avoke; simpler text-only format suits her current capacity |
| Bluepoint 3-email flow (HubSpot) | — | Assigned to Raphael; Karly to handle automation setup |
| Aviary Webflow build | — | Confirmed with Eshock |
Why Raphael was a good fit for the reassigned tasks:
- He had previously built the Advanced Health & Safety site from scratch, so he had existing familiarity
- He had prior access to the Overhead WordPress instance
- His current queue had capacity
Why Avoke was a good fit for PaperTube emails:
- The PaperTube emails are text-only (no HTML/template complexity)
- Avoke was available and willing
- Keeping Raphael on the Cora Italia Salesforce build preserved his platform context
Related Processes
- [1] — how to assign email builds based on platform and complexity
- [2] — the rule on developer-initiated due date changes
- [3] — client context for the Seamless build referenced here
- [4] — Overhead location pages project
- [5] — Advanced Health & Safety location pages
- [6] — Cora Italia Salesforce email build