Most teams have rules that nobody follows. You know the ones: respond within 24 hours, update your status daily, join meetings on time. They’re written down somewhere, maybe in a welcome doc or pinned in Slack. And yet people ignore them constantly.
The problem isn’t that your teammates are careless. It’s that these rules feel like homework nobody signed up for. When guidelines come from the top down, or get copied from another company’s playbook, they rarely match how your actual team works. People nod along in the meeting, then quietly do their own thing.
Remote teams face an extra challenge here. When everyone’s in different time zones and you can’t just tap someone on the shoulder, clear agreements actually matter. But making them stick requires a completely different approach than traditional rule-setting.
The secret is surprisingly simple: let people help create the rules they’ll be expected to follow. When your team co-designs their own remote work guidelines, something shifts. These aren’t imposed standards anymore. They’re shared commitments that reflect real needs and real schedules.
This doesn’t mean endless meetings or design-by-committee chaos. It means asking the right questions, listening to what actually frustrates people, and building agreements that solve problems your team genuinely has. The rules that emerge tend to be fewer, clearer, and way more relevant than anything a manager could dream up alone.
When team members feel ownership over the guidelines, they don’t need reminders or enforcement. They follow through because the rules make their work easier, not harder.
Start with the real problems your team is feeling
Before you write a single rule, you need to know what’s actually broken. The best remote team agreements don’t come from someone’s idea of best practices. They come from the messy, annoying moments your team experiences every single week.
Start by asking people to share specific examples of when work felt harder than it should. Not general complaints like “communication is bad” or “people aren’t responsive.” You want actual stories. The moment someone waited three days for feedback that blocked their entire project. The time a quick question turned into seventeen Slack messages because no one knew who owned the decision. The meeting that could have been an email, or the email that desperately needed to be a meeting.
These concrete situations are gold. When someone says “I never know if I should Slack or email,” dig deeper. What happened last time they guessed wrong? When did a message get lost? What was the actual consequence? The more specific you get, the clearer the pattern becomes.
You’re looking for pain points that multiple people recognize, even if they experience them differently. Maybe your designers feel bombarded by notifications while your project managers feel like they’re shouting into the void. Those opposite experiences often point to the same underlying problem that a good agreement can solve.
Write these situations down as stories, not complaints. “Last Tuesday, the client asked for an update and three of us sent different answers” is much more useful than “We need better coordination.” Real moments make it obvious why a new norm might actually help.
Write rules that are specific enough to use in the moment
The problem with most team agreements is they sound inspiring in the meeting room but useless on a Tuesday afternoon. A rule like “communicate proactively” feels good to write down, but when you’re actually deciding whether to send that message, it tells you nothing.
Good remote team agreements work like recipes, not poetry. They tell you exactly what to do, when to do it, and where it happens. Instead of “keep everyone in the loop,” try “post a quick update in #status by 3pm if your task will take longer than expected.” Notice the difference? One makes you nod along. The other tells you precisely what action to take.
Each useful agreement needs three parts: the situation that triggers it, the specific behavior expected, and the place it happens. “Respond to messages quickly” is too vague. “Reply to questions in #support within two hours during your working day” gives everyone the same mental picture. When someone doesn’t follow through, you can point to something concrete rather than arguing about what “quickly” means.
Here’s the tricky part: you need to be selective. A 20-point document of team norms just becomes wallpaper. Pick the three or four interactions that cause the most friction or confusion right now. Maybe it’s how you hand off work between time zones, or when to use async messages versus calling a meeting. Focus on the moments where people genuinely don’t know what’s expected, not every possible scenario.
Your agreements should feel more like helpful reminders than rules imposed from above. If you can’t imagine someone actually checking them before taking action, they’re probably not specific enough yet.
Put agreements where work actually happens
The best agreements in the world won’t help if nobody can find them when they need them. That Google Doc you created three months ago? It’s already lost in someone’s downloads folder.
Instead, put your agreements exactly where your team already spends their time. If you use Slack or Teams, pin the most important agreements right at the top of your main channels. Update channel topics with quick reminders like “async updates by 10am” or “no meetings Thursdays.” When someone joins a channel, they’ll see it immediately.
Connect agreements to the moments when people actually need them. Paste a quick reminder about standup format at the top of your standup channel. When someone creates a new project channel, drop in a note about how your team handles decisions or shares feedback. Add a line about response time expectations to your team’s onboarding checklist.
You can also weave agreements into recurring meetings. Start your weekly sync with a rotating reminder about one team norm. Keep a simple note in your meeting agenda template that links to communication guidelines. The goal isn’t to nag people, it’s to make following through feel automatic.
Think of it like putting your running shoes by the door instead of in the closet. You’re not creating more rules or more documentation. You’re just making it easier to remember what you already agreed to do. The less effort it takes to see your agreements, the more likely everyone is to actually follow them.
Treat agreements as experiments you can revise
The best remote team agreements aren’t carved in stone. They’re more like recipes you’re still perfecting. When you create a new rule, treat it as something you’re trying out, not something permanent.
Start by piloting a few agreements for two or three weeks. Pick something specific, like response time expectations or meeting-free afternoons. After the trial period, ask your team a simple question: is this actually helping? You don’t need a formal survey. A quick chat or a few messages in your team channel will tell you what’s working and what isn’t.
Some rules will need tweaking. Maybe your agreement about same-day responses feels too tight when someone’s dealing with deep work. Adjust the wording. Maybe your no-meetings-before-10am rule doesn’t account for your new colleague in Sydney. Expand the scope or retire it entirely.
Speaking of retiring rules, don’t be afraid to drop agreements that aren’t pulling their weight. If nobody remembers a rule exists, or if it’s causing more confusion than clarity, let it go. Your team agreements should be a helpful guide, not a growing list of forgotten commitments.
Certain moments naturally call for revisiting your norms. When someone new joins the team, check if your agreements still make sense. When you add a new time zone, your coordination rules might need updating. If the same question or conflict keeps popping up, that’s a signal too. Major workload shifts, like launching a new project or wrapping up a busy season, are also good times to pause and ask what still fits.
The goal is keeping your agreements alive and relevant, not creating endless meetings about meetings. A lightweight check-in every few months is usually enough.
