How to Discuss a Moonlighting Policy With Your Employer in English
Learn the English phrases for asking about or clarifying your company's policy on taking on additional paid work outside your main job.
“Moonlighting” refers to taking on paid work outside your main job, and company policies on it vary widely — some allow it freely, some require disclosure, and some prohibit it in specific circumstances. Asking clearly, before you commit to anything, protects you from an unintentional policy violation.
Asking About the Policy Directly
Start by understanding what’s actually allowed before making any commitments.
- “Does the company have a formal policy on taking on additional paid work outside of regular hours, and is there somewhere I can review it?”
- “I want to make sure I understand the rules before committing to anything — is moonlighting generally permitted here, with or without disclosure?”
- “Is the policy different depending on whether the additional work is in a related field versus something completely unrelated to my role?”
Disclosing a Specific Opportunity
If you’re considering something specific, be concrete rather than vague.
- “I wanted to flag a freelance opportunity I’m considering outside of work hours — it’s in [unrelated field], and I want to confirm it doesn’t conflict with any company policy.”
- “Before I commit to this, I want to be transparent: here’s what the work would involve, roughly how many hours, and why I don’t believe it creates a conflict of interest.”
- “I want to disclose this proactively rather than have it come up later — is there a form or process for reporting outside work?”
Addressing Conflict of Interest Concerns
If your employer raises concerns, engage with them directly rather than getting defensive.
- “I understand the concern — to be clear, this work isn’t for a competitor and doesn’t touch any of our proprietary information.”
- “I’m happy to adjust the scope of this if there’s a specific concern about conflict of interest, rather than assume it’s automatically fine.”
- “Would it help if I got written confirmation from the other party that this work doesn’t overlap with anything we do here?”
Clarifying IP and Time Boundaries
Establish clear boundaries around intellectual property and working hours.
- “I want to confirm: does any IP assignment clause in my contract extend to work I do entirely outside company time and resources?”
- “I’ll make sure none of this happens during work hours or using any company equipment — is that the main boundary the policy is concerned with?”
Responding If the Answer Is No
If moonlighting isn’t permitted for your role, respond professionally.
- “I appreciate the clarity — I won’t move forward with this, given the policy.”
- “Understood. Is there a process for requesting an exception in specific cases, or is this a firm restriction across all roles?”
Vocabulary Reference
| Term | Meaning |
|---|---|
| Moonlighting | Taking on additional paid work outside of one’s primary job |
| Disclosure | Formally informing an employer about outside activities that might be relevant |
| Conflict of interest | A situation where outside work could compromise loyalty, confidentiality, or objectivity |
| IP assignment clause | A contract term giving the employer ownership of certain intellectual property created by an employee |
| Exception | A departure from a standard policy, granted for a specific case |
Key Takeaways
- Ask directly about the company’s moonlighting policy before committing to any outside paid work.
- Disclose a specific opportunity concretely, including the field, time commitment, and reasoning for why it doesn’t create a conflict.
- Engage directly with any conflict-of-interest concerns your employer raises, rather than becoming defensive.
- Clarify whether IP assignment and time-boundary rules apply only during work hours or extend further.
- If the answer is no, respond professionally and ask whether exceptions are ever possible.
Navigating Nuances: Professional English for Developers
We’ve already covered the fundamentals of discussing a moonlighting policy with your employer – focusing on clarity, professionalism, and demonstrating that it won’t negatively impact your primary role. But let’s be honest; effective communication isn’t just about knowing what to say, it’s also about how you say it, especially when dealing with nuanced topics like flexible work arrangements. For developers, particularly those whose first language isn’t English, mastering the specific vocabulary and phrasing around this subject is crucial for building trust and securing a positive outcome. This section will focus on equipping you with the tools to articulate your request confidently and respectfully.
One common area of confusion arises when discussing prioritization. Instead of saying something vague like “Can I work on another project?” – which can sound demanding – try phrasing it as, “I’d like to discuss how my time commitment to this additional role might affect my current sprint goals. Could we perhaps schedule a brief sync to review the timelines and dependencies?” This demonstrates you’re considering the impact on your existing workload and are proactively seeking solutions. Similarly, when responding to feedback during a code review, avoid simply stating “I’m working on another job.” Instead, if someone comments on the quality of your work, you could reply with: “Thank you for this valuable feedback. I appreciate you pointing out these areas for improvement and will address them immediately. I’m also mindful of my workload across all projects.” This shows receptiveness to criticism while managing expectations transparently.
Another frequently encountered scenario involves proposing the idea through Slack or similar communication channels. Rather than a direct request, consider starting with an observation: “Just wanted to check – has there been any recent discussion about the company’s stance on employees taking on side projects? I’m exploring some opportunities that could enhance my skills and experience.” This opens a dialogue without immediately putting your manager on the defensive. Following this, you can then directly ask for clarification if needed: “Could you point me to any relevant documentation or policy outlines regarding this?” This approach frames your inquiry as seeking information rather than demanding permission.
Finally, when drafting a Pull Request description outlining your work, avoid overly casual language. Instead of “Adding some stuff,” try something like “Implementing [feature name] based on requirements outlined in [ticket number]. This includes [briefly list key tasks] and adheres to the established coding standards.” Adding this level of detail demonstrates professionalism and respect for the review process – a critical element in any development team. Remember, clear, precise language builds confidence and reduces misunderstandings.