Developers must not change task due dates without explicit approval from the responsible Account Manager (AM). Due dates on tasks reflect client commitments, meeting schedules, and review cycles that the AM is accountable for — unilateral changes by developers can cause missed client deadlines without the AM being aware.
Developers may not modify task due dates without first consulting and receiving approval from the Account Manager assigned to that client.
If a developer believes a due date is unrealistic given their current workload, they must raise the concern with the AM proactively — before the deadline is at risk, not after it has already been changed.
Due dates in the task management system are not internal estimates — they are tied to:
When a developer silently pushes a due date, the AM may not notice until the day of a client call, leaving no time to recover.
This rule was reinforced during the [1] after a high-priority page build for [2] sat untouched for two weeks. The developer had moved the due date to the end of the month without notifying the AM, who had a client meeting scheduled and was expecting deliverables. The due date was restored, and the issue was used as a team-wide reminder of the policy.
"Please do not change due dates without talking with the AM. I had two weeks for these pages to be built. I have a meeting with the client."
— Melissa Cusumano, Sprint Planning 2026-01-22
A similar pattern had been observed on other accounts, reinforcing the need for a standing rule rather than case-by-case correction.
To reduce ambiguity, AMs should include client-facing context directly in the task description when creating or assigning work. This helps developers understand the stakes of the deadline before they begin.
Recommended task note format:
"First client review is scheduled for [DATE]. Please flag any blockers at least 2–3 days before this date so we can adjust expectations with the client if needed."
If a deadline feels unachievable: