How to Push Back on Unpaid Overtime in English

Unpaid overtime often creeps in gradually — one late night becomes an expectation. This guide gives you the English for naming the pattern, pushing back on a specific instance, and resetting expectations going forward, without sounding uncooperative.

Naming the Pattern

Point out that what’s being asked has become routine, not occasional.

• “I’ve noticed this is becoming a regular expectation rather than an occasional exception, and I want to flag that before it becomes the norm.”
• “This is the third week in a row I’ve worked past six without it being compensated — can we talk about whether that’s actually sustainable?”
• “I don’t mind occasionally staying late for something urgent, but this has started to feel like an unspoken requirement rather than an exception.”

Declining a Specific Ask

Turn down a particular request for unpaid extra hours clearly.

• “I’m not able to stay late tonight — is there a way to scope this down so it fits within regular hours, or can it wait until tomorrow?”
• “I want to help get this done, but I can’t do it unpaid past my contracted hours — can we either compensate the time or push the deadline?”
• “I’ll pick this back up first thing tomorrow rather than staying tonight — is that workable given the deadline?”

Asking About Compensation Options

Raise whether overtime should be paid, banked as time off, or otherwise formally recognized.

• “Is there a process for logging overtime, whether that’s paid or banked as time off later?”
• “If this kind of crunch keeps happening, can we talk about either overtime pay or comp time, rather than it just being absorbed for free?”
• “I want to be flexible when it’s genuinely needed, but I’d like that flexibility to be reciprocated with either pay or time back.”

Raising It With a Manager Directly

Escalate the broader pattern rather than only declining individual requests.

• “I wanted to raise something before it becomes a bigger issue — I’ve been doing several unpaid extra hours a week for the past month, and I don’t think that’s sustainable long-term.”
• “Can we look at the workload together? I think the current scope genuinely requires more hours than a standard week, and either the scope or the hours need to change.”
• “I’m committed to this team, but I want to be clear that consistently unpaid overtime isn’t something I can keep absorbing indefinitely.”

Protecting the Boundary Going Forward

Reinforce the boundary once it’s been raised, so it doesn’t quietly slide back.

• “I appreciate you understanding last time — I want to make sure this doesn’t become a recurring assumption again.”
• “Just a reminder that I mentioned I can’t consistently do unpaid overtime — let’s make sure that’s factored into how we scope sprints going forward.”

Vocabulary Reference

Key Takeaways

• Name the pattern explicitly once occasional overtime starts becoming a routine, unspoken expectation.
• Decline specific requests clearly, and offer an alternative like rescoping, pushing the deadline, or picking it up the next day.
• Ask directly whether overtime can be compensated through pay or time off rather than absorbed for free.
• Raise the broader pattern with a manager if individual pushback isn’t changing the underlying workload.
• Reinforce the boundary after it’s initially raised so it doesn’t quietly become the norm again.

Navigating Nuance: Specific Phrasing for Non-Native Speakers

Let’s be honest – even native English speakers sometimes struggle to articulate their boundaries when it comes to working extra hours. For developers who are still refining their professional vocabulary, this can feel particularly challenging. It’s not just about saying “no”; it’s about doing so with clarity, respect, and a focus on maintaining positive relationships within your team. The key is choosing the right phrasing that demonstrates you understand the project’s needs while simultaneously protecting your time and wellbeing.

One common issue arises during code reviews. Imagine receiving a comment from a senior developer like this: “This PR could benefit from further refinement to address the performance bottleneck – consider adding some logging for debugging.” A simple, direct “no” might feel confrontational. Instead, you could respond with something more nuanced. Try saying, “Thank you for highlighting that, [Senior Developer’s Name]. I appreciate your feedback on the performance. I’ve added some basic logging as requested; however, to fully address the bottleneck, a deeper analysis of the algorithm is likely required – perhaps we could schedule dedicated time for this next week?” Notice how using phrases like “appreciate your feedback,” “likely required,” and “perhaps we could schedule” softens the response and frames it as a collaborative effort. It avoids sounding dismissive while clearly stating your understanding of the issue.

Another scenario might occur via Slack. A team lead sends out a message: “Can someone please review this new feature implementation for the upcoming release? We’re really tight on time.” Reacting with immediate agreement, especially if you already have commitments, can be problematic. Instead, consider a reply like: “Thanks for flagging this, [Team Lead’s Name]. I’m currently focused on [briefly state your current task], but I’m happy to prioritize reviewing this feature after I complete it by [estimated timeframe]. Could you let me know if there are any specific areas of concern you’d like me to focus on?” This demonstrates responsiveness without immediately committing to additional unpaid work. The use of phrases like “currently focused,” “happy to prioritize,” and “specific areas of concern” provides control and manages expectations.

Finally, when creating a Pull Request description, be proactive in setting boundaries. Instead of simply stating you’re adding a feature, consider: “This PR implements the core functionality as requested. Further optimization for performance will require dedicated time – I’ve documented potential bottlenecks for future investigation.” This anticipates potential requests and subtly communicates your limitations without directly rejecting the task. Using phrases like “further optimization,” “dedicated time,” and “documented potential bottlenecks” provides a professional justification while protecting your workload. Remember, clear and thoughtful communication builds trust and demonstrates professionalism—essential qualities in any developer’s toolkit.