I had been building distributed teams for twenty years and I had never systematically talked to other people who were doing the same thing. I had my own hard-won knowledge. I had my own pile of mistakes. But I did not know what the people solving similar problems from different vantage points had learned.
There was also something more personal. I had been traveling to San Francisco for twenty years. My company had had a presence there for ten. And I had quietly noticed that I had not made a new friend in that city in the last decade. Not a real one. I kept attending the right events and meeting the right people and leaving with business cards and no real connection.
I started the PreVetted Podcast because I wanted to have real conversations with people who had built things and were willing to talk honestly about how. Three years and 150 episodes later, what I found was not consensus. It was pattern.
Many of the patterns below are drawn from specific conversations on the show. Karthik Krishnamurthy on what AI changes about senior engineering. Manisha Sahni on running teams across six time zones. Swati Swoboda on the engineer as translator. Charlene Li on speed as competitive advantage. Cameron Dutro on the philosophical layer underneath tooling debates. Shailin Saraiya and John Hooker on the mechanics of distributed engineering across cultures. There are 143 more like them. The patterns are theirs as much as mine.
The timezone gap is real. The compliance complexity is real. The currency fluctuation, the IP transfer process, the cultural misread that looks like a performance issue until it isn’t, all of it is real. But underneath all of it, in conversation after conversation, the same question kept surfacing without the person asking it realizing they were asking it:
How do you build a team that comes together across distance and still feels like one?
Not how do you ship faster. Not how do you reduce attrition. Not how do you scale the org chart. The question underneath was about the texture of the team itself, whether the people on it experienced themselves as members of one thing, or as separate parts of a transactional arrangement.
Almost every leader I talked to was, in some form, working on that question. Almost none of them had a name for it.
Healey Cypher, another founder who came on the podcast, has been studying human connection as a business problem. He told me that 64 percent of people say they feel alone, and that among people aged 18 to 24, the number is 79 percent.
I heard those numbers not as a data point but as a description of something I had watched happen slowly on every distributed team I had ever run. The productivity was usually fine. The connection was not. And the teams where the connection eroded first were always the ones where no one was watching for it.
Engineering leaders running distributed teams are operating on top of a baseline of human disconnection that has nothing to do with their company. The job, increasingly, is to design against that baseline rather than expect cohesion as a default.
Beyond the central question, five patterns kept repeating across the 150 conversations, patterns I didn’t go in looking for, but that surfaced in nearly identical form regardless of company size, geography, or stack.
1. The job is mostly translation. Almost every VP I talked to described their job, when pressed, as a translation problem. They translate engineering reality up to executives who want a single number. They translate executive ambition down to engineers who want a clear scope. They translate between product and infrastructure, between security and speed, between the team that built the system and the team that has to operate it next year. The leaders who thrived had quietly accepted that translation was the work. The ones who struggled were the ones still expecting the job to be technical leadership.
2. The hardest hires are not the senior engineers, it’s the senior engineers who can absorb context fast enough. Every leader I talked to had a story about the brilliant senior who didn’t work out. The pattern was always the same: validated in the loop, lasted four to nine months, left or was let go. The hires that worked were the ones where someone had asked, by the second interview: can this person learn how we work, fast enough, without breaking what’s already working?
3. The org chart lies about who actually runs the company. Every VP could name two or three engineers who, if they left, would take a year of institutional knowledge with them. They were rarely the highest-paid. The healthy leaders had a name for these people, load-bearing engineers, and a quiet, permanent project to make them redundant by spreading what they knew. The struggling leaders couldn’t name them and were one resignation away from a six-month productivity crater.
4. Most of the conflict isn’t about what people think it’s about. A lot of executive conflict in engineering organizations gets framed as disagreement about strategy or architecture. After 150 conversations I am almost certain it’s almost never about that. It’s about decision rights. Two leaders both believe they have authority over a domain, the company never made it explicit, and every architectural debate is actually a turf negotiation in disguise. The cost of leaving decision rights ambiguous is enormous and almost completely invisible on a P&L.
5. Loneliness is the single most underestimated risk. The most common honest answer when I asked what kept guests up at night was not stack rank, retention, the next round, or the architecture review. It was that they had nobody to talk to. Their CEO didn’t understand the engineering reality. Their reports couldn’t hear about the problems above them. Their peers in other companies were either competitors or too senior to be candid. The leaders I watched fail over the three years didn’t fail because they were bad at the job. They burned out and made one bad decision under exhaustion that cascaded faster than they could recover.
Last month, a CTO I have known for years called me after one of his best engineers in Buenos Aires gave notice. No warning. No escalation. Just a resignation email on a Tuesday afternoon. He asked me what I had been asked, in different forms, by dozens of leaders across the three years of the show: what did I miss?
I am still not sure I have a complete answer. But I know where to start looking. The map I started drawing from the 150 conversations is the foundation of The Invisible Distance, the book I’m writing now. Almost everything in it began as something a guest said on the show that I couldn’t stop thinking about for weeks.
The conversations didn’t give me a framework. They gave me a terrain. The book is my attempt to draw the map.
]]>He told me his junior product manager had ended the debate by spending one Saturday afternoon with Cursor and shipping a working prototype of all three approaches. Not pretty, not production-ready, but functional enough to demo. Monday morning the team picked the right one in twenty minutes.
The CEO told me this story expecting me to be impressed by the prototype velocity. What surprised me was where his attention actually was.
“The thing I keep thinking about,” he said, “is that we wasted four months because the engineers were arguing about implementation details and the only person who knew which approach would actually fit our customers was the PM. We didn’t have a code problem. We had a context problem.”
That conversation has been on my mind. I think it might be the most important thing I’ve heard about AI all year, and it has very little to do with AI itself.
The conventional framing is that AI dramatically lowers the cost of writing code. That’s true but undersells what’s happening. The cost of code is not just lower. It’s becoming approximately zero in a way that changes the structure of the work.
When code was expensive, you had to be careful about what you built because building was the bottleneck. The constraint forced a particular kind of discipline: think hard, scope well, choose carefully, ship slowly. Most engineering culture, most engineering leadership, most of the tooling we built up over twenty years assumes that constraint.
That constraint is dissolving. I don’t think we’re at the end state yet, but the trajectory is clear. A senior engineer with current AI tooling can produce in a day what used to take two weeks. A motivated PM with Cursor can ship a prototype that previously required an engineering ticket. The bottleneck has moved.
The new bottleneck isn’t writing code. It’s knowing what to write.
I want to be precise about what I mean by context, because the word does a lot of work and I’ve seen it abused.
I don’t mean documentation. I don’t mean RAG over your codebase. I don’t mean prompt engineering. Those are all useful, but they’re surface manifestations of something deeper.
Context is the accumulated, often unwritten understanding of:
This is the kind of knowledge that lives in the heads of senior people, gets transmitted in 1:1s, surfaces in retros, and never makes it into a Notion doc. It’s the thing a new senior engineer takes nine months to acquire even with good onboarding. It’s also the thing that makes the difference between a feature that ships and works and a feature that ships and gets quietly walked back two months later.
For most of the last twenty years, the durable competitive advantage in software was being able to hire and retain engineers who could write good code. The companies that did that well outcompeted the ones that didn’t. The cost of code was high enough that this difference compounded into product velocity, which compounded into market position.
That advantage is eroding. Not gone, code quality still matters, system design still matters, but the gap between a great engineer and a competent one with AI assistance is narrower than it was. The advantage that compounds the most isn’t being eroded by AI, though. It’s being concentrated by it.
The engineers who win in this environment are the ones who know what’s worth building. The teams that win are the ones whose engineers have enough context to make those calls quickly. The companies that win are the ones who have invested, over years, in building the institutional context that lets their teams make good decisions fast.
This is not a new idea. Tom DeMarco was writing about it in the 1980s. What’s new is that the constraint has flipped. Code used to be the scarce resource. Context is now.
I’ve been running engineering teams for a decade and the rules I used to apply have shifted under me in the last eighteen months. A few things I’m trying.
Tenure as a leading indicator, not a lagging one. I used to think of long engineer tenure as a result of having done other things right,culture, comp, work that mattered. I now think it’s also a cause of the things I want. The engineer who’s been on the codebase for three years can move ten times faster than the equivalent engineer hired last quarter. With AI tooling, that ratio gets bigger, not smaller, because the experienced engineer can deploy AI usefully in places where the new engineer doesn’t even know there’s a decision to be made.
I’m now willing to pay more to keep an engineer for a fourth year than I would have been to hire a stronger engineer at year zero. That’s a different math problem than I was solving five years ago.
Documentation as a forcing function for legibility. Not for the AI’s benefit, though that’s a side effect. For the team’s. The pressure to write down why decisions were made, who they affect, and what the tradeoffs were used to feel like overhead. It now feels like the thing I’m investing in. When the documented context is good, both the humans and the AI tooling can work from it. When it’s bad, only the humans can compensate, and only the senior ones, and only at the cost of their attention.
Hiring for taste over throughput. A junior engineer with good taste who uses AI well will outproduce a senior engineer with mediocre taste who’s still writing everything by hand. The throughput gap that used to favor seniority is closing. The taste gap is the one that matters now. I look for people who can articulate why they made a particular technical choice, not just whether they made it. The articulation is the proxy for taste.
Embedded models over project models. I’ve been making this argument for ten years for unrelated reasons. The new reason: an embedded engineer is a context-acquisition machine. Every standup, every PR review, every casual Slack thread is an opportunity to build the model of how the system works and why. A project engineer doesn’t get that. They ship what they were scoped to ship and leave.
In a world where context is the advantage, an embedded engineer is acquiring something durable that outlasts any specific feature they ship. A project engineer is producing output that is becoming commoditized.
I want to be careful here, because there’s a version of this argument that becomes a weak excuse for not investing in technical excellence. That’s not what I’m saying.
Code quality still matters. System design still matters. The ability to actually ship working software at scale still matters. AI tooling makes some of these things easier, but it doesn’t make them irrelevant, and in some cases it makes them more important,a system that’s been over-built for ease of AI iteration may be harder to operate or extend than one designed by an engineer who understood the constraints.
What I’m arguing is narrower: the relative value of writing the code is dropping, and the relative value of knowing what code to write is rising. Both still matter. The mix is shifting.
A few weeks after that conversation I asked the CEO what he was doing differently. He told me he’d reorganized his engineering meetings. Engineering used to spend an hour a week on architecture review. Now they spend an hour a week on customer review,specific customer use cases, specific feedback, specific decisions made because of that feedback. Architecture review still happens, but it’s been compressed to fifteen minutes and is mostly process.
“The architecture is the easy part now,” he told me. “I have eight engineers who can produce good architecture. I have two who can tell you which architecture our customers will actually use, and they’re so much more valuable than they were a year ago that I can’t quite believe it.”
That’s the shift. The work didn’t disappear. The leverage moved.
]]>Whether the practices I have built over twenty years, the hiring rigor, the belonging work, the local leadership, the visibility infrastructure, are still relevant when an engineer can generate a pull request in an afternoon that would have taken a week a year ago.
My answer is yes. But not for the reason most people expect.
I spent time talking with Karthik Krishnamurthy on the PreVetted Podcast. He’s the CEO and founder of Ascendion, a company that operates AI-native engineering teams across twelve countries including Mexico, Brazil, and Colombia. He has watched more AI transformations inside enterprises than almost anyone I know. He clarified something I had been circling around for months.
The old model of international software delivery, the one I built my early career around, was labor arbitrage. Find a labor pool where skilled engineers cost less. Deliver faster, better, cheaper. The efficiency gains were real: 30, 40 percent. That model is not wrong. But it is no longer where the frontier is.
The next model is what Karthik calls AI arbitrage. An engineering team that is truly integrated with an AI-native process can deliver outcomes that don’t improve the old benchmarks by 30 percent. They obliterate them. “Labor arbitrage helped you deliver 30, 40 percent,” he told me. “But now you’re talking about percentages which go over 100.”
He’s not talking about automating repetitive tasks. He’s talking about compressing the time between idea and shipped software by an order of magnitude.
The question I had to sit with was: which distributed teams are positioned to capture that, and which ones are not? The answer, when I thought it through, was not the answer I expected.
The teams that will not be able to capture AI arbitrage are the ones built on pure staffing logic. Engineers who rotate in and out, who do not accumulate institutional knowledge, who are not integrated into the client’s product thinking. Agents do not improve the output of a team that has no context to transfer. You cannot contextualize an agent around a domain the team has never understood deeply.
Karthik is relentless on this point. He called contextualization the highest-effort, most-overlooked part of enterprise AI: “We spend 25 to 30 work streams on contextualization before we open the platform for everybody to use.” The accumulated business definitions, the decision logic, the edge cases that were never documented because everyone just knew them, all of it has to be ingested before agents can operate at production quality.
That work requires people who have been there long enough to know what the context is. Engineers with two-year tenure on one client. Engineers who sat in the architecture discussions. Engineers who absorbed the product reasoning, not just the ticket acceptance criteria.
I have been building those teams for twenty years without calling it that. The low turnover wasn’t just a retention metric. It was the accumulation of context that an agentified process can now amplify.
Everyone is focused on what AI does to junior engineers. The fear is that AI will close the entry-level gap, that the path from bootcamp graduate to productive contributor will be automated away. That is a real concern.
But Karthik identified the more immediate problem. “I worry a lot for the senior developers now,” he told me. “The people that have held on to their Python code for too long, who haven’t spent enough time understanding domain, who haven’t spent enough time understanding the functions in which they belong so that they can actually validate the outputs of the agents more effectively.”
The senior engineer who built an identity around deep implementation expertise, who is the go-to person because they know the codebase better than anyone, is the one whose position is most at risk. Not because they’re being replaced. Because the codebase fluency they accumulated is increasingly reproducible by an agent that has been given the context they carry in their head.
The engineers who are not at risk are the ones who built their career on judgment, not implementation. The ones who understand why the system works the way it does, not just how to make it work.
Charlene Li, who came on the podcast, she’s tracked technology disruptions from the internet to social media to AI, made the same point from a different angle. “AI will give you the answers that are as good as the questions that you ask it,” she told me. “People who are experts in their fields do so much more with AI than somebody who is just starting out.”
This is another reason why distributed teams that invest in long tenure and career development are better positioned than the ones that optimize for cost and replaceability. The engineer who has been on the same product for four years and understands why the payment flow works the way it does can use AI to go ten times faster. The engineer who rotated in six months ago and is still reading the documentation cannot.
Charlene’s core argument is that the competitive advantage in an AI world is not adopting the tools. Everyone adopts the tools. The advantage is how fast an organization can adapt itself around them.
“Speed is the new moat,” she told me. “And what I mean by that is not just the adoption of AI, but the adaption of your organization. How quickly can you change your organization?”
An organization that deploys Copilot but does not redesign its review process, its QA culture, its approach to documentation, has not adapted. It has added a tool to an unchanged system. An organization that asks what it would look like to restructure how engineers spend their time, how product and engineering align, how decisions get made when AI handles implementation, that organization has adapted. The tool is the same. The lead is not.
The distributed teams I’ve built are, structurally, faster at this kind of adaptation than most co-located organizations. They have already had to design for async. They have already had to build explicit communication infrastructure rather than relying on proximity. They have already had to create the documentation and context-sharing practices that AI now rewards. The discipline that distributed work required turned out to be a rehearsal for what AI-native work requires.
Swati Swoboda, also a podcast guest, manages Vault at Shopify’s Office of the CEO. She described what this shift looks like inside a company that has already crossed into it. Her team of eight generates over one hundred pull requests in a single day. She reads far more than she writes.
“Every engineer has become a manager effectively,” she told me. “They are understanding a business use case and then telling it to a bunch of agents.”
The code is still being written. But the person writing it is increasingly the agent, and the person directing the agent is the engineer. The engineer’s job has become closer to a product manager’s job: understand the business problem, frame it precisely, evaluate the output against reality.
What that requires is the opposite of what most technical hiring has screened for. “The skills that are shining right now,” Swati said, “are the folks where they have paid attention to their communication skills. Being able to express a problem. Understanding why we are doing something.”
She framed the future in terms I found more honest than most AI predictions: more companies with engineers, fewer engineers per company. The accountant parallel, when Excel arrived, we did not need fewer accountants. We needed more, because more companies could now afford an accountant’s function. The same logic applies here. AI will not reduce the total number of engineers in the world. It will reduce the number required per company while expanding the number of companies that need engineering capability. The field will grow. Each company’s team will shrink.
What’s breaking is the model where a vendor sends you bodies and bills you hourly, where engineers rotate every twelve to eighteen months, where the relationship is transactional and the context resets with every change.
What replaces it is something that looks more like a partnership. Long-tenured teams. Engineers who own a domain for years. Local leadership that holds context across cycles. An operational discipline that treats accumulated understanding as the asset, not the headcount.
That model is harder to sell on a spreadsheet because the unit economics aren’t “engineer-hours × rate.” The unit economics are “what can a team that has been integrated for four years do that a team integrated for six months cannot.” That number is not in any benchmark, but it’s the only one that matters now.
The teams that figure that out get the AI compounding effect. The teams that don’t keep paying labor-arbitrage rates for outcomes that no longer benchmark to a market.
Staff augmentation isn’t dying because of AI. It’s dying because AI exposes what the model was actually missing: context. The replacement is the kind of team you build when you stop treating engineers as interchangeable.
]]>The releases were slower than projected. The Austin team was burning a lot of cycles redoing things that had come back wrong. There were no obvious failures, no missed deliverables, no individual engineer to blame. Just a pervasive sense that the team was working very hard for less output than the headcount suggested.
I spent two days going through the sprint history feature by feature. The pattern was the same one I had seen on my own teams. The rework wasn’t concentrated in any one engineer or any one type of work. It was distributed evenly, and it was always tied to the same shape: a question that needed an answer before the build could go right, and an answer that came back six hours later, when the build was already heading somewhere wrong.
I added it up. The total rework cost, in developer hours, was close to $80,000. The savings from the Argentina team’s lower hourly rate, compared to hiring four equivalent engineers in Austin, was about $30,000.
She had spent $50,000 more than she would have spent on a local team. And she felt like she’d saved money.
After that review, I started using a name for what I had been observing: the Correction Clock.
The clock isn’t about hourly rate. It’s about feedback velocity, how fast a wrong assumption can be caught, and how many wrong-assumption hours get burned before the correction arrives. An engineer at $40 an hour working six hours in the wrong direction costs $240 in wasted time, not counting the rework. An engineer at $70 an hour who catches the misalignment in two hours costs $140. On any given day, in any sprint with real ambiguity, the cheaper engineer was more expensive.
That math doesn’t always work the same way. When requirements are genuinely clear and the work is well-defined, the timezone gap shrinks as a cost factor. There are categories of work where an offshore team at a large offset makes obvious economic sense, and I’ve used that model effectively. But most software development, in most growing companies, is not that kind of work. Most software development is navigating ambiguity in real time. And navigating ambiguity in real time requires being able to ask and answer questions in real time.
The Correction Clock doesn’t stop running because you’re not watching it.
The structural half of the clock is what people try to solve with meeting schedules, async-first policies, and overlap windows. Those work, within limits.
The relational half is subtler, and the half most managers miss. The speed at which a question gets asked is not the same as the speed at which the question gets answered. If an engineer doesn’t feel safe enough to flag a misalignment, the question is never asked at all. It becomes an assumption, which becomes code, which becomes a feature reworked in week four.
Manisha Sahni, who had run a team across six time zones for several years, described it to me on the podcast: the teams that function best across distance are the ones where engineers know each other as people, not as roles. When you know someone as a person, you send them a quick message saying “I’m not sure about this.” When you know them as an avatar in your project management tool, you make an assumption and keep moving.
The clock runs slower on teams where people know each other. Not because they’re better engineers. Because the question gets asked faster.
You don’t need new tooling. You need one habit.
For the next ten things your team builds, write down two dates: the date the work began, and the date someone first noticed a meaningful misalignment with the original intent. The gap between those two dates, averaged across the ten, is your Correction Clock.
Under one day: you have a healthy team and a tight feedback loop. Under three days: normal. Over a week: a structural problem no amount of process documentation will fix, your team has lost the ability to detect its own drift.
The Correction Clock explains the cost structure of timezone gaps when requirements involve real ambiguity. It explains why a team that looks cheaper on paper can be more expensive in practice, and why some of the best distributed teams I’ve worked with have spent heavily on nearshore presence and relationship-building. The investment looks like overhead. It’s actually a reduction in rework.
The clock doesn’t explain every case of rework. If your product team genuinely doesn’t know what it wants yet, no amount of feedback velocity will save you, that’s a different problem. The clock also doesn’t tell you the right timezone offset for your team. Some teams run well at twelve-hour offsets. Some fall apart at four. What changes is the surrounding factors, not the offset itself.
The clock runs at the same speed everywhere. What you’re controlling is how often it costs you.
]]>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.
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.
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.
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 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.
]]>