A Q&A with Josh Arnold, VP of Engineering at BetterEngineer
Managing a globally distributed engineering team is now the norm, but doing it well is still rare. Time zones, communication gaps, and uneven visibility can quietly slow teams down or burn them out.
In this post, Josh Arnold, VP of Engineering at BetterEngineer, shares how he thinks about building and leading high‑performing remote teams. In a candid Q&A, he talks through the habits that actually keep work moving, the mistakes leaders make when they try to “remote‑ify” an office culture, and how to set clear expectations in an AI‑assisted world.
Josh: Day to day, great collaboration mostly looks like a lack of waiting.
On healthy remote teams, people don’t sit quietly blocked for half a day. They write a short, clear message: what they tried, what’s blocking them, what decision they need, and by when. Then they switch to parallel work instead of stalling.
If we hit a third‑party API limitation, I don’t see “blocked on API” for three days. I see: here’s the constraint, here are a few options, here’s my recommendation, and here’s the decision I need. That’s what keeps a distributed team moving.
Josh: Leaders unconsciously promote and trust the engineers they see most. In a distributed team, “seeing” someone means reading their work — their PRs, their Slack threads, their design docs. Leaders who don’t train themselves to evaluate written presence over video‑call presence end up with a two‑tier team: visible people and invisible people.
Fixing this starts with a brutal bit of self‑awareness as a leader: Am I actually reading what my team writes? Am I forming opinions based on artifacts, or on who makes me feel good in Zoom calls? On a global team, fairness and good judgment both depend on your willingness to treat written work as the primary way you “see” your engineers.
Josh: A lot of leaders assume burnout comes from too much work. In my experience, it usually comes from unclear expectations.
If people don’t know what “responsive enough” looks like, they default to “always on.” If they don’t know which channels are for urgent vs non‑urgent questions, everything feels like a fire. That constant low‑grade anxiety is what wears people down.
So you work with the team to eliminate as much ambiguity as you can: write down what’s expected for response times, how you handle after‑hours issues, which meetings are really mandatory, and when it’s totally fine to be offline. Then you stay close to how that’s landing through frequent 1:1s.
And whenever you can, meet in person a couple of times a year. A few days together build enough trust that the async communication in between feels a lot less brittle.
Josh: Honestly, the rituals that stick are the ones that solve problems we actually hit.
Daily standups keep everyone visible and synced — when you’re remote, it’s very easy to go heads‑down for days and drift without realizing it. A simple daily check‑in forces you to surface what you’re doing, where you’re stuck, and where plans have changed before it turns into a bigger problem.
PR reviews became almost religious for us after we realized how fast knowledge silos form when everyone’s working in their own corner. Reviews aren’t just about catching bugs; they’re how we spread context, coach engineers, and keep patterns consistent across the codebase. On a distributed team, that shared understanding doesn’t happen by accident.
And we do in‑person meetups whenever possible. A few days together gives you months of smoother async collaboration. Once you’ve sat next to someone at a whiteboard or had dinner with them, you read their Slack messages a lot more generously.
Josh: In the AI‑assisted development world, our expectations around ownership have actually gotten more explicit.
Engineers are ultimately accountable for every line of code in a commit, whether they typed it or a model suggested it. That means understanding it, being able to defend it, and approving it deliberately before it goes up for review. “The AI wrote it” is not an excuse if it breaks in production.
From there, every PR gets a second set of eyes from another engineer on the team. The expectation is that the original engineer can answer any question about the code under review— the reasoning behind an approach, what alternatives were considered, and what breaks if this changes. If you can’t answer those questions, the code isn’t ready to merge. That standard applies regardless of how the code was written.
On responsiveness, we try to be just as clear. We define reasonable response windows for reviews and production issues, and we respect people’s offline hours. Ownership doesn’t mean being glued to Slack 24/7; it means knowing which areas you’re responsible for and showing up thoughtfully when those areas need you.
Josh: The most reliable thing I’ve found is consistent 1:1 investment — showing up prepared, following through on what I say I’ll do, and asking questions that aren’t about status.
“What's been frustrating this week?” is a better 1:1 opener than “What did you ship?” If all we ever talk about is output, people won’t tell me about the process problems, the collaboration issues, or the ideas they’re not sure are “good enough” yet. Psychological safety lives in those conversations, not in a slide deck about culture.
I also make it a point to attribute good ideas to the people who had them. In a remote team, visibility is important. If someone proposes a change that we adopt, I’ll use their name when I talk about it with leadership or in a wider channel. That’s a small thing that adds up over time.
Remote and globally distributed teams aren’t automatically better or worse than co‑located ones — they’re just less forgiving of fuzzy habits. What Josh keeps coming back to in this Q&A is pretty simple:
Do those things consistently, and a globally distributed engineering team stops feeling like a compromise — it becomes a natural, even powerful, way for your team to build and ship software together.