What I learned from 150 podcast conversations with VPs of Engineering
Three years, 150 episodes, and one question that kept surfacing in nearly every conversation, usually without the person realizing they were asking it.
About three years ago I realized something that should have been obvious sooner.
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 question underneath every other question
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.
The loneliness statistic
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.
Five patterns I didn’t expect
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.
The Tuesday afternoon call
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.