Collaborative Coding in a Remote World
Breaking down silos and finding issues before they become problems.
When the world went remote, I got the same question at least once a week: "How do we keep our engineering culture alive when nobody's in the same room?"
The answer surprised a lot of people. Open source projects have been doing this for decades. Thousands of developers, scattered across timezones, building some of the most critical software on the planet. They figured it out. We can too.
The grass is always greener where you water it.
Git Workflows: The Foundation
If you haven't defined a workflow for managing changes, start there. Without one, you'll see duplicate work, conflicting changes, and the wrong code deploying to production.
Questions to ask:
- • How many environments do we deploy to?
- • How often do we need to hotfix production?
- • How complex can we afford for the team to learn?
Whether you use GitHub Flow, GitFlow, or something simpler, pick one, try it, and pivot or persevere based on what you learn.
Open Pull Requests Early
Push developers to open pull requests as soon as they start working on something. Add WIP or Draft to the title to signal it's in progress.
Visibility
Others know what's being worked on
Early feedback
Teammates can comment before you're too invested
Reduced duplicate work
No one else picks up the same task
Making changes easy to share and comment on is one of the keys to remote collaboration. Done beats perfect—get it visible early.
Localize Everything
Remote teams create new demand on shared pipelines. More people pushing code means more queue time, longer waits for feedback, and frustrated reviewers.
The fix: make it easier to run checks locally than to push and wait. If tests and linting run faster on a developer's machine than in CI, they'll do them before pushing.
| Do | Avoid |
|---|---|
| Fast local test suites | Tests that only run in CI |
| Pre-commit hooks for linting | Linting failures discovered after push |
| Docker Compose for local services | "It works on my machine" syndrome |
Traceability: Link Everything
Remote collaboration isn't just about developers. Product managers, QA, customer support—they all need visibility into what engineering is building.
Link code changes to requirements. When a pull request references a Jira ticket or GitHub Issue, everyone can trace from requirement → code → deployment.
Tools for Traceability
- •Jira — Smart commits link to issues
- •GitHub — Keywords close issues on merge
- •GitLab — Cross-linking between issues and merge requests
- •Linear — Branch names auto-link to issues
Validation Environments
Non-technical teams need a place to see changes without asking a developer to spin up a local environment. Having at least one staging environment that mirrors production lets:
Product managers validate features
On their own schedule, without developer coordination
QA runs manual tests
Independent verification without scheduling demos
Stakeholders see progress
Visibility without blocking engineering time
Notify the Right People at the Right Time
With traceability and environments in place, you can automate notifications to the people who care about specific changes.
Development team → Slack
When a pull request is merged
QA → Jira ticket
When it hits staging
Customer support → Release notes
When it ships to production
The goal is the right information, to the right people, at the right time, in the channel they're already watching.
Remote collaboration isn't about replicating the office. It's about building systems that work better than the office ever did. Async-first, visible by default, with guard rails that catch problems before they ship.
The grass is greener where you water it. Invest in these practices, and remote becomes a strength, not a limitation.
Building a remote engineering team?
I've helped teams set up the practices that make remote work. Let's discuss your challenges.