Deadline Enforcement Rule — Developer Approval Required

Overview

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.

The Rule

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.

Why This Matters

Due dates in the task management system are not internal estimates — they are tied to:

Scheduled client review meetings
Agreed-upon delivery windows communicated to the client
Sprint planning assumptions that other team members depend on

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.

Origin

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.

Best Practice: Set Context in the Task

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."

What Developers Should Do Instead

If a deadline feels unachievable:

Notify the AM immediately via Slack or task comment — do not change the date first.
Explain the conflict — what other tasks are competing, and what the realistic timeline looks like.
Let the AM decide — the AM will either reprioritize other tasks, negotiate with the client, or reassign the work.

^[3]
^[4]
^[5]