Belonging is not a feeling. It is a system.
An engineer who never missed a deadline still walked out at month eight. The reason wasn't visible in any dashboard. It crystallized in the first ninety days.
He didn’t crash the system.
He didn’t miss a deadline. He didn’t send a passive-aggressive message in a public channel or file a complaint with our EOR. He went quiet.
I noticed it in month three. I’ll call him Arjun. He was a backend engineer we had hired through our entity in India to work on payments infrastructure. His first two weeks were exactly what you want from a remote hire, responsive in Slack, present at every standup, clean pull requests, good questions, laughed at the right moments.
Then around week ten, something shifted. It wasn’t dramatic. He still said yes to every ticket. He still hit every SLA. He never complained. But the questions stopped. The jokes stopped. And the quality of his work settled into a very specific zone: technically correct, completely uninspired. He was doing exactly what was asked, and absolutely nothing more.
I spent two weeks trying to figure out if it was a performance issue. It wasn’t. He was delivering. Then one afternoon I was looking at our team dashboard and I realized what was actually happening. Arjun had stopped committing code to anything that wasn’t explicitly assigned to him. He had stopped participating in architecture discussions. He had stopped reviewing other people’s pull requests. He had stopped reacting in Slack to anything that wasn’t a direct question.
He hadn’t stopped working. He had stopped belonging.
He left at month eight, with the most thorough handoff document I have ever received. Every edge case, every dependency, every known bug logged with a proposed fix. He had been carrying all of it quietly for months.
The Belonging Window
After Arjun, I started tracking something I’d been observing intuitively but hadn’t formalized. I call it the Belonging Window.
The first ninety days of a distributed engineer’s engagement are the period when belonging is either established or permanently undermined. Engineers who feel integrated by day ninety tend to stay for years. Engineers who don’t have already started quietly looking. This is not a metaphor. It is a deadline.
It works in three phases.
Days 1–30: the engineer is evaluating you. Watching how the team communicates, how decisions get made, how conflict is handled, how their manager shows up. They’re forming initial impressions that are surprisingly sticky.
Days 30–60: the engineer is testing. They take a small risk. They push back on a minor decision. They share an opinion that wasn’t directly solicited. How the team responds determines whether the engineer escalates or retreats.
Days 60–90: the engineer is deciding. The tests are complete. The pattern is set. They have enough data to answer the question: am I a member of this team, or am I a vendor? If the answer is member, they settle in. If the answer is vendor, they start looking. Not actively. They just open the door, they start noticing recruiter messages, start browsing job boards. The decision has been made. The departure is just logistics.
After day ninety the window is closed. You can still improve an engineer’s experience after day ninety. You cannot change their fundamental assessment of whether they belong.
Belonging is a system, not a vibe
Most leaders aren’t ready for what belonging actually requires. Manisha Sahni, Senior Director of Engineering at AppOmni, told me on the podcast: “Building that culture, building that sense of unity and belonging is something that people underestimate, because it takes a lot of time, it takes a lot of conversations, and that’s something that a manager or a leader of a global organization needs to be ready to do.”
She’s right that most leaders aren’t ready for it. They plan for the technical setup, the tooling, the laptop shipping. They do not plan for the fact that belonging requires a sustained, deliberate investment of time and presence that has no clear deliverable and no sprint ticket.
The concept I keep coming back to is going from avatar to friend. On day one, a distributed engineer is an avatar in your project management software, a name, a profile photo, an email address. The belonging work is converting that avatar into a person your team actually knows.
I once described this to Manisha on the podcast as the difference between knowing someone’s name and having played mini golf with them. The dynamic between me and a product owner I work with shifted the day she beat me at mini golf. We had a running reference. We had a shared memory that had nothing to do with sprints or deadlines. When I showed up on a call the next week, I wasn’t just a manager. I was the person who lost. Manisha’s response: “Yes, for sure.” She’d seen the same thing on her own teams.
The texture of interaction changes when there’s a real relationship underneath it. That shift, from avatar to person, is the first belonging deposit.
The deposits
After Arjun, here’s what we started doing in each phase of the window. None of it is expensive. The cost of not doing it is an engineer who goes quiet in month three and leaves in month eight, and you never know why.
Days 1–30: Every new engineer has at least three one-on-one conversations that are not about work. Not “how’s the project going.” Real conversations. Our VP of Engineering started scheduling fifteen-minute calls with new distributed hires specifically to get to know them as people. We learned about their families, their hobbies, what they did before engineering, what they cared about.
Days 30–60: We explicitly ask distributed engineers for their opinion on decisions that are still in progress, not after they’re made. Not “here’s what we decided, any questions?” but “we’re thinking about doing X, what do you think?” The first phrasing tells them they’re a vendor. The second tells them they’re a member.
Days 60–90: We do something we call a belonging check. Not a performance review. Not an engagement survey. A direct, human conversation where the manager asks: do you feel like you’re part of this team? Is there anything making you feel like an outsider? We don’t ask this in a Slack survey. We ask it on a video call, face to face, because the answer lives in the pause before the words, not in the words themselves.
The honest accounting
The Belonging Window is something I built because of Arjun. Not for him. He was the data point I didn’t know I was collecting. The version of this story where I knew what to look for doesn’t exist. What exists is the version where I noticed too late, understood afterward, and changed what we did for the engineers who came after.
He left. I learned something. I wish those two things had happened in the other order.