Return to office disagreements in tech teams: setting a rule people can live with

On a Tuesday afternoon, a founder opens the office entry log and sees eleven badge swipes for a team of sixty. Two days later, the head of engineering says three of his best backend developers will leave if attendance becomes compulsory. Both are right about what they see. Neither has a rule to point to.

Return to office arguments in software firms rarely end because someone wins. They end when the company writes a rule that is specific, explained and applied the same way to everyone. This guide sets out how to get there in a few weeks.

Most firms drifted into remote work during an emergency and never wrote down what they had agreed. So managers hold different private rules. One lead lets a developer work from his hometown for a month. Another refuses a single day. People compare notes on the team chat, and the grievance becomes fairness, not location.

The founder, meanwhile, has real concerns that are easy to dismiss. New joiners learn slowly on video calls. Design reviews go better around one screen. Clients ask to meet the people who run their account. These are fair reasons, but they apply to some roles and some weeks, not to every person every day.

• Work reasons: onboarding, design and architecture sessions, incident response, client workshops, mentoring.
• Cost reasons: lease commitments, desks that sit empty, travel and food arrangements.
• Culture reasons: whether people know each other, and whether juniors have someone to ask.
• Trust reasons: a worry that output is falling, without any data to show it.

Write which of these is actually driving the push. If it is the lease, say so. If it is a slow release cycle, look at the cycle before blaming the location. A rule built on the wrong reason will be tested and ignored.

1. 1

   Collect facts for two weeks

   List each team, its work pattern, which meetings truly need people in a room, and how many desks you have. Pull attendance from the access log and the leave record, not from memory.

2. 2

   Hear the managers and a sample of staff

   Run short group sessions by role: developers, testers, support, project managers. Ask what work suffers at home and what suffers in the office. Write down the answers without comment.

3. 3

   Choose a model

   Pick from fixed anchor days for the whole company, team-chosen days within limits, role-based rules, or fully flexible with set events. Decide which fits your work, not which sounds modern.

4. 4

   Draft the policy in plain words

   State who it covers, the expected days or events, who approves exceptions, how client-site and travel days count, and what happens if someone is away from their base city for long.

5. 5

   Pilot with a review date

   Run it for a fixed period, publish the review date, and collect the same facts again. Change the rule only at the review, not in between.

6. 6

   Train the managers

   Walk managers through ten sample cases. They must give the same answer to the same request.

1. Purpose: the work reasons, in two or three sentences
2. Scope: which roles and locations are covered, and who is excluded and why
3. Expected presence: anchor days, team days or event-based days
4. Core hours and availability when working remotely
5. Equipment, internet and workspace expectations, and who pays for what
6. Working from a different city or state for a short stretch: approval route and limits
7. Exceptions: medical, caregiving, relocation, with who decides and how it is recorded
8. Client-site and travel days: how they count
9. Data security at home and in public places
10. Review date and the owner of the policy

Three cases decide whether people trust the rule. The first is the senior engineer who lives far from the office and is critical to a release. The second is the junior who needs to be in more often to learn. The third is the person who asks to work from a native place for several weeks because of a family situation.

Decide the principle for each case now. A senior with a heavy delivery role may have a different pattern from a fresher in the first year, and that is acceptable if the reason is written. Exceptions should be rare, recorded, and reviewed. A manager should never grant one in a corridor chat.

A developer who is told that attendance is compulsory hears control. A developer who is told that sprint planning and code walkthroughs go better in person, and that the team chose two days, hears a reason. Give the reason every time. Also say what the company will do in return, such as fixing seating, cutting meeting-heavy days, or reimbursing a transport arrangement if that is the company's decision.

Attendance expectations touch appraisals, because a manager might rate someone down for being absent while the policy allows it. They touch resignations, because people who feel the rule is unfair start interviewing. The appraisal cycle design article explains how to keep ratings tied to work, not to where the person sat. See also how software development companies set up their wider HR.

If you want help writing the document, GullyHR's work from home and hybrid policy service covers the draft, the manager briefing and the review plan.

• The reason for the change, in two sentences, with no blame.
• The rule, with three examples of how it applies.
• The date it starts and the date it will be reviewed.
• The route for exceptions and who answers questions.
• A short question and answer note posted in the same place as the policy.

Hold a live session with a question round. Send the note afterwards so those who missed it have the same words as everyone else.

At the review date, look again at the data you gathered at the start. Compare release delays, onboarding feedback, attrition conversations and desk use. Ask managers which cases were hard. Change what the evidence supports, and leave the rest alone. A rule that is reviewed honestly gets more respect than one defended forever.