I’ve built remote engineering centers from scratch twice now. The first one grew to over two hundred people over several years. The second is eight, and it’s not clear yet whether it’ll get bigger. Different companies, different products, different scales. The process is more similar than I expected.
Starting from one
The first time, I helped set up the remote center while still at headquarters, then moved there as it grew. The second time, I was the first hire. Both times, the main engineering team was somewhere else – a team that had been working together for years.
The first task isn’t technical. It’s earning trust from a team that can’t see you. You don’t do that with presentations or status updates. You do it with code.
Code review as the bridge
When you get someone you’ve never met in person to review your code, and they come back with insightful feedback – something clicks. The next review, you look at their code more carefully. The loop iterates. The frequency matches. After a few weeks of this, you know how they think. They know how you think. The gap vanishes.
No amount of video calls or alignment meetings does what consistent code review does. Review sessions are scheduled and structured. Code review is daily, asynchronous, and honest. The code speaks definitively – there’s no room for ambiguity in a diff. You either handled the error or you didn’t. You either thought about the edge case or you didn’t.
At two hundred people, code review was how the remote center proved it could own services, not just execute tasks. Teams in headquarters would review our PRs, and we’d review theirs. Over time, the review direction stopped mattering. The feedback was peer-level, not supervisory. That’s when we knew it was working.
At eight people, the same thing happened, just faster. Fewer people means every reviewer sees more of the codebase. The trust loop tightens because the same two people are reviewing each other’s work every day.
What scales down
The process remains intact. Service ownership, deploy practices, code review culture, incident response – all of these work at eight the same way they work at two hundred. You downscale to fit the available people and bandwidth, but the shape doesn’t change.
What changes is specialization. At two hundred, you have dedicated teams for search, payments, logistics, infrastructure. At eight, everyone touches everything. There’s no infra team – you are the infra team, and also the backend team, and also the person who debugs the CI pipeline at the end of the day. That’s not a disadvantage. At eight, everyone has full context. Decisions happen in a conversation, not a meeting.
The second time around, the anticipation is better. Communication is more deliberate. I know which things need to be written down and which can stay verbal. I know which decisions to make locally and which to escalate. The external factors are harder this time – market conditions, hiring timelines, approved headcount deferred to next quarter. You build with what you have and adjust when the plan changes.
The work is the same. Earn trust through code. Own your services. Review each other’s work until the distance stops mattering.