Make a New Process Stick on Remote Teams

We switched code review to a new tool on a Monday. The lead wrote a clear, friendly message in the engineering channel at 10am his time in Chicago, explained why we were moving, linked the setup doc, and asked everyone to start using it that week. Seven people reacted with a thumbs up. By Friday three of them had actually moved, four were still opening pull requests the old way out of habit, and the two engineers in Manila had never seen the message at all. It had landed at 11pm their time and scrolled under a full night of other traffic before they logged on.

Nobody fought the change. There was no debate, no one defending the old tool, no politics. The process just didn't take. A month later we were quietly running two review systems in parallel and pretending that was a reasonable way to live.

That failure had nothing to do with the tool and everything to do with how we introduced it. We treated a change like news, something you say once and it's done. On a distributed team a change is not news. It's a campaign, and run like an announcement it dies the way ours did, not with resistance but with a slow fade into two parallel habits nobody chose.

The office enforces a change for you

Think about how a new process actually spreads in a shared building. Someone announces it, sure, but the announcement is the smallest part. The real work happens after. You see the person next to you using the new thing and copy them. You start to do it the old way, and a colleague says "oh, we're doing that in the tracker now" before you get three steps in. The change is in the air, reinforced a hundred small times a day by people who can see each other, until it stops being a rule and becomes just how things are done here.

None of that is written down anywhere. It's proximity doing the work of a rollout, continuously, for free. You never notice it because you've never had to build it.

Remote switches every bit of it off. Nobody watches you keep doing it the old way, so nobody corrects you in the moment. There's no ambient sense of what everyone else is doing, so you fall back on whatever your hands already know. The announcement that would have been a starting gun in an office is, on a distributed team, often the entire effort, and it's nowhere near enough. This is the same reason teams adopt async-first communication and still struggle for months: writing the principle down is easy, and getting a scattered group to change what they do every day is the hard, separate problem.

An announcement is not a rollout

The first mistake is the one we made: assuming that because you said it, people heard it. On a team spread across eight zones, a single message reaches the fraction of people who happen to be online at that minute, and it's invisible to everyone else. Half your team meets your important change as a line buried in a backlog they skim at 9am their time, half-awake.

So a change has to be delivered the way anything important gets delivered to a distributed team: in a durable place, not a disappearing one. Pin it. Put it in the handbook. Say it in the written weekly update where people who missed the live moment still find it. The goal is that someone logging on twelve hours late, who was asleep for the whole original conversation, can still land on a clear statement of what changed and when it starts, without having to reconstruct it from a thread that scrolled away. A rollout that lives only in one channel message at one moment is a rollout you've agreed to let half the team miss.

Write down the change, and the reason behind it

A pinned "we're moving to the new tool, please switch by Friday" is better than a vanishing one, but it's still thin. People follow a process they understand and route around one they don't, and across timezones you won't be awake to explain it when the confusion hits.

Write the why, not just the what. "All design feedback goes in Figma comments now" is a rule people will quietly ignore the first time Slack feels faster. "All design feedback goes in Figma comments now, because feedback in DMs disappears and the designer in Lisbon loses half of it, so we keep it where the whole thread lives next to the work" is a rule people understand well enough to hold onto at the moment it's inconvenient. This is the same discipline as recording the reasoning behind a decision and not just the outcome: the reasoning is what lets someone six hours away make the right call without pinging you, and a process is really just a decision you're asking the whole team to make the same way every day.

Start with one pod, not the whole team

There's a strong pull to flip the switch for everyone at once. It feels decisive and fair. It's usually a mistake, because a new process always has rough edges you can't see from the announcement, and discovering them across your entire team at once means discovering them in a dozen timezones where you can't be present for any of them.

Run it with one small group first. A single pod, ideally one that shares enough hours that they can work out the friction together in real time and tell you what broke. Let them hit the setup snag, the step the doc forgot, the case the new tool handles worse than the old one. Fix those before you widen it. Then the version the rest of the team meets is the one that already works, instead of a half-formed idea you're debugging live against people you can't reach. A contained mess in one timezone is recoverable. The same mess smeared across the whole map at once is how a change earns a bad reputation it never shakes.

Put a name on it

A process with no owner drifts back to the old way the moment it meets resistance, and nobody notices until you're running two systems again. Someone has to own the adoption, not just the announcement. They answer the questions, chase down the people still doing it the old way, and rule on the edge cases the rollout never anticipated.

This is the same rule as giving every piece of work a single named owner, applied to the change itself. And the owner has to be reachable by the people hitting friction, which on a distributed team is a timezone question, not just an org-chart one. If the one person who can unblock the new workflow is asleep every hour the APAC pod is awake and confused, that pod stalls on the old habit for a week, and a week of the old habit is often enough to lose them for good. Pick an owner with real overlap with the people adopting, or pick more than one.

Close the old door

Here's the step almost everyone skips, and it's the one that quietly kills more rollouts than resistance ever does. If the old way still works, the old way wins. Habit is a current, and as long as the old channel is open, people drift back down it without deciding to, especially at the tired end of their day when the familiar path is the one their hands take.

So close it. Archive the old channel and turn off the old integration, so there's nothing left to drift back down to. Make the new path the only path, not the recommended one. This is the same reason a decision has to move out of the busy channel into a durable home instead of coexisting with the old scattered version: two live options on a distributed team isn't a transition period, it's a permanent split, because nobody's in the room to notice the team quietly forked into two camps on opposite sides of the planet.

If you run the team

The trap here is measuring the wrong thing. Seven thumbs-up reactions on your announcement tell you seven people saw a message. They tell you nothing about whether anyone changed what they do, which is the only thing that matters, and the gap between the two is exactly where our code review rollout died. Watching reactions instead of behavior is the adoption version of managing by the green dot instead of by output: a comfortable signal that measures the performance of compliance rather than the real thing.

So check the behavior directly. Are pull requests actually opening in the new tool, or are four people still on the old one? Is the far-timezone pod running the new process, or did they never fully get it and you just can't see them not using it? Go look, in each cluster, rather than assuming silence means success. And give a change longer than a week before you judge it, because a distributed team adopts anything more slowly than a co-located one, not out of reluctance but because the reinforcement that used to happen in a day now has to cross nights to reach everyone. Most of all, use the new process visibly yourself. Your team copies what they can see the leads doing, and on a distributed team they watch your written behavior more closely than you think, because it's most of what they have to go on.

Let Timely Carry the Clock Math

Half of rolling out a new process is coordinating when it starts and who's covering what, and that falls apart the moment "we go live Thursday at 9" means a different hour to everyone reading it. When someone posts "new tool is mandatory starting Monday 9am ET" or "pilot wraps Friday 5pm Berlin," Timely reads each person's Slack timezone and converts every time into their own local clock, so the whole team hits the same deadline without a round of "wait, when is that for me?"

Add Timely to Slack — Free · See how it works