I Rejected a Flexi-Work Request in Three Lines and Lost the Engineer: the 7 Steps I Use Now

A backend engineer on a team I was advising asked to work from home three days a week. Her mother had moved in after a fall and the 50-minute commute each way had become the problem in her life. Her manager replied the same afternoon, in three lines, that the team was office-based and the request could not be accommodated. He was not being cruel. He answered quickly because he thought a quick answer was respectful, and he gave no reason because he did not think he had to. She resigned five weeks later for a role paying roughly the same money with two fixed remote days. Replacing her took four months and a 14 percent salary increase on the backfill.

Nothing about that outcome was required. This is the process I wrote afterwards, and it has handled every request I have seen since without losing anyone.

What changed in Singapore, briefly

The Tripartite Guidelines on Flexible Work Arrangement Requests took effect on 1 December 2024. The substance for an employer is narrow and often misreported, so it is worth stating plainly what it does and does not do.

It expects you to have a process for properly considering a formal request, to respond within two months of the date the request was made, and to give a reason if you refuse, with reasons that are generally business-related such as cost or feasibility. Employers should not refuse requests for reasons unconnected to business outcomes, such as not believing in flexible work.

It does not require you to approve anything. It does not cover informal arrangements agreed between an engineer and their lead. And it does not override a genuine operational constraint. What it changes is that a decision now has to be a decision, documented, rather than a reflex.

For an engineering organisation that is a low bar and a real improvement, because the reflex answer is what cost my client an engineer and four months.

Step 1: Write the process down before the first request arrives

Every failure I have seen happened because a manager was answering a request for the first time, alone, with no template. Produce one page that says: where a request is sent, who decides, who else is consulted, how it is recorded, and what the employee receives at the end.

Circulate it to every engineering manager and team lead. The cost is an afternoon. The thing it prevents is a well-meaning lead firing off a three-line refusal on a Tuesday because he is between meetings and thinks he is being efficient.

Time: one afternoon. Output: a one-page process document in your team handbook.

Step 2: Confirm what kind of request you have received

Developer requests almost always fall into one of three families, and they are assessed differently:

Get the request in writing and establish the start date and whether it is permanent or time-boxed. Many requests that look like place requests are really hours requests in disguise: the engineer does not want to be at home, they want to avoid a commute during a specific window. Those are much easier to grant.

Step 3: Start the clock and say so

Acknowledge the request in writing on the day it arrives. Three sentences: I have received this, I will decide by this date, and if we can agree something sooner we will start sooner.

You have two months, counted from the date the request was made. Most engineering decisions take a week. The window is genuinely useful only when the request affects an on-call rotation or a client commitment that has to be renegotiated.

But the acknowledgement matters out of proportion to its effort. An engineer who has asked for something that affects their family and heard nothing for nine days has already started composing a different plan. I have seen that interval, specifically, produce two resignations.

Step 4: Assess against delivery, not against preference

This is the step that makes the rest defensible. Write the assessment against four specifics:

1. Overlap hours. How many hours per day does this team genuinely need everyone available for review, pairing and incident response? Most teams, asked this directly for the first time, discover the honest answer is four, not eight.
2. On-call coverage. Does the arrangement leave a gap in the rotation, and if so can the rotation be rebuilt rather than the request refused?
3. Co-located value. Which specific activities are better in a room? Onboarding a junior, architecture arguments and incident retrospectives usually are. Writing code and reviewing pull requests usually are not.
4. External constraints. Client contract terms, or a regulated environment where work must happen from a controlled location. These are real, and when they apply they are the cleanest reason you can give.

Write a paragraph against each. The whole assessment takes twenty minutes and it produces either an approval you can explain to the rest of the team or a refusal you can put your name to.

The test I apply to my own drafts: could I read this back to the engineer in a room without flinching? If the honest answer involves “we prefer people in the office”, I do not yet have a reason, I have a preference, and the guidelines are explicit that reasons should be business-related rather than a view about flexible work.

Step 5: Offer the nearest workable alternative before you refuse

Almost no request is binary, and treating it as binary is how a solvable problem becomes a resignation.

If four remote days break your onboarding plan but two do not, offer two. If a 7am start kills the standup, ask whether the standup can move, because standup times are a convention and a caregiving arrangement is not. If a reduced week is impossible this quarter because of a committed delivery, say so and offer a start date after it.

In the case I opened with, the engineer wanted to avoid a 50-minute commute twice a day while her mother recovered. Two fixed remote days would have solved it. Nobody asked what she was actually trying to achieve, so nobody discovered how cheap the solution was.

Ask the question directly: what are you trying to make possible? The answer is usually smaller than the request.

Step 6: Put the decision in writing, with the reason

Short, specific, and dated. A refusal that works reads something like this:

We cannot approve fully remote work in this role. The team needs four overlapping hours daily for review and incident response, and this role holds a weekly on-call slot that we cannot cover from outside Singapore hours. We can approve two fixed remote days, Tuesday and Thursday, starting 1 November, and we will review the arrangement on 15 January.

That is three sentences: the decision, the business reason, and the alternative. It is the difference between an engineer who feels heard and one who opens LinkedIn.

Record the decision in the personnel file. Not because anyone is likely to ask, but because the next manager who inherits this team will otherwise reverse an arrangement they did not know existed, which is its own resignation waiting to happen.

Step 7: Approve with a trial and a review date

Do not write the arrangement into the employment contract. That makes it a contractual term that cannot be changed without agreement, and the fear of that permanence is exactly why many employers refuse requests they could otherwise accommodate.

Instead: a separate written arrangement, referenced from the personnel file, stating what is agreed, the measures it will be reviewed against, and a review date eight to twelve weeks out. Three measures work well with engineers because all three are things they control:

• Review turnaround. Time from pull request opened to first substantive review.
• Incident response participation. Availability during their on-call windows, measured, not impressionistic.
• Delivery against commitments. What they said they would ship in the cycle, versus what shipped.

This reframes a conversation about trust into a conversation about evidence, which engineers tend to find fairer than the alternative. It also gives you a legitimate basis to adjust later without the engineer experiencing it as betrayal.

What the three-line refusal actually costs

It is worth putting numbers on this, because the refusal feels free and the replacement does not.

Singapore engineering teams compete for developers against employers who will offer flexibility without being asked twice. That is the actual competitive context, independent of any guideline. The guidelines simply mean that when you refuse, you have to say why, which turns out to be a useful discipline because a reason you cannot write down is usually a reason you should not act on.

If you are working on retention more broadly, our guides on retaining senior developers in Singapore and setting up a hybrid engineering team cover the surrounding policy, and handling counteroffers covers what happens when you get to step six too late.

Frequently asked questions

How long does an employer in Singapore have to answer a flexible work arrangement request?

Two months from the date the request was made. That window exists so employers can work out what the arrangement would mean for the rest of the team, check feasibility and plan the implementation if it is approved. You can agree to start the arrangement earlier if you and the employee reach a suitable arrangement before the deadline, and in practice most engineering teams decide well inside two months. In my experience the full window is useful only when the request affects an on-call rotation or a client commitment that needs renegotiating. Whatever you do, acknowledge the request on the day it arrives and state the date you will decide by, because an unanswered request reads as a refusal long before the two months are up.

Can I reject a developer flexible work request in Singapore?

Yes. The Tripartite Guidelines on Flexible Work Arrangement Requests require employers to consider formal requests properly and to give a reason if they are rejected. They do not require approval. The reasons should generally be business-related, such as cost or feasibility, and employers should not reject requests for reasons unconnected to business outcomes, such as simply not believing in flexible work. For an engineering team that means your rejection should point at something specific: the overlap hours needed for code review and incident response, a client contract term, a regulated environment that requires work from a controlled location, or coverage in an on-call rotation that cannot be rebuilt. Write that reason down in a short paragraph. If you cannot state it in two sentences without referring to a manager preference, you probably do not have a business reason yet.

Do flexible work arrangements hurt engineering delivery in Singapore?

Not by themselves. The arrangements that cause problems in engineering teams are the ones that reduce overlap below what review and incident response require, or that leave an on-call rotation with a gap nobody noticed until an incident. Those are both solvable by specifying overlap and coverage explicitly rather than by refusing the arrangement. What I see damage delivery far more often is the opposite failure: a blanket return-to-office rule applied to a team spread across four MRT lines, which produces attendance without collaboration and quietly pushes the two or three engineers with young children or long commutes onto the market. Singapore teams compete for developers against companies that will offer flexibility, so the practical question is not whether to allow it but how to specify it tightly enough that delivery is unaffected.

Should a flexible work arrangement be written into the employment contract?

Usually not into the contract itself, and this matters more than it sounds. Writing an arrangement into the employment contract makes it a contractual term that cannot be adjusted without agreement, which is why many employers refuse requests outright rather than accept a permanent commitment. The pattern that works is a separate written arrangement, referenced from the personnel file, that states what is agreed, the measures it will be reviewed against, and the review date. The engineer gets something real and documented rather than a verbal promise that evaporates when their manager changes. The employer keeps the ability to revisit the arrangement on evidence. Review turnaround, incident response participation and delivery against commitments are the three measures I have found engineers accept as fair, because all three are things they already control.

Reference

• Tripartite Guidelines on Flexible Work Arrangement Requests, Ministry of Manpower, in effect since 1 December 2024, for the response window and the treatment of reasons for refusal.

Sebastian

Mobile App & Hiring Expert at HireDeveloper.sg. Advises Singapore employers on engineering hiring and retention, and has spent more time than he would like reconstructing teams that lost people over arrangements that could have been granted.