SoftGodam has been fully remote since we founded the company. No office, no co-location option, no hybrid — just distributed teams across multiple timezones delivering software to clients who expect the same quality they'd get from a co-located agency.
Three years in, here's what actually works.
1. Written Communication Is the Core Skill
In a remote team, writing is not a soft skill — it's the primary technical capability. Engineers who communicate clearly in writing are 10× more productive than engineers who communicate well in person but poorly in text.
In interviews, we evaluate this explicitly. We send candidates a written brief about a technical problem and ask them to respond in writing. We're not testing their knowledge — we're testing whether their writing is precise, structured, and complete. Engineers who pass this screen consistently outperform those who don't, regardless of technical skills.
What we do: Every significant technical decision has a written proposal (we call them "decision docs") — a short document covering the problem, the options considered, the decision made, and the rationale. These live in the project repository permanently.
2. Async-First, Not Async-Only
Async-first means the default assumption is that communication doesn't require an immediate response. Meetings are for decisions that require real-time negotiation — not status updates, not questions that can be answered in writing.
In practice, this means: - Standups are written (a Slack message at the start of the day: what I did yesterday, what I'm doing today, any blockers) - Questions are asked in public channels, not DMs — so the answer is searchable - Decisions are made in tickets or decision docs, not in ephemeral video calls
What we do: We have a rule: if a decision was made in a video call, it hasn't been made yet. It needs to be written up and acknowledged in a ticket before anyone acts on it.
3. Demo Culture Is Non-Negotiable
Every sprint ends with a live demo to the client. No slides, no "almost ready" explanations — working software in a staging environment. This practice serves two purposes: it creates a forcing function for shipping (nothing focuses a team like a scheduled demo), and it surfaces misaligned assumptions before they compound.
We extended this internally: every engineer demos their work to the team at the end of each sprint. This keeps everyone aware of what's being built, surfaces integration risks early, and creates a healthy peer accountability loop without micromanagement.
4. Documentation Is the Product
In a remote team, undocumented systems are inaccessible systems. There's no desk to walk over to, no whiteboard session to explain how something works. If it's not written down, it's as if it doesn't exist.
Our documentation standard for every project: - A README that lets a new engineer run the project locally within 30 minutes - An architecture document that explains why things are structured the way they are (not just what they are) - A runbook for every deployment and every recurring operational task - ADRs (Architecture Decision Records) for every non-obvious technical choice
We audit documentation at the end of every sprint — not just at delivery. Documentation written retrospectively is always incomplete.
5. Hiring Filters for Remote Work
Not every engineer thrives in a remote environment. The filter we've found most predictive:
Does this person have strong opinions and communicate them clearly in writing? Engineers who hold their opinions loosely and communicate them vaguely produce no friction in team discussions — and no useful intellectual pressure either. Remote teams need people who will push back, clearly, in text.
Can they work for long stretches without external structure? We ask: "Tell me about a project you worked on alone for more than two weeks. What did you do when you were stuck and had no-one to ask?" The answer reveals whether someone is a self-directed learner or a dependency-seeker.
Do they treat communication as an engineering problem? The best remote engineers optimise their written communication the same way they optimise their code — concise, precise, no ambiguity, anticipating the reader's questions.
6. The Practices That Didn't Work
For balance:
Scheduled social calls — We tried weekly "virtual coffee" sessions. Attendance dropped to two people by week six. Forced socialisation doesn't survive remote.
Status dashboards — We built elaborate project health dashboards that nobody read. What worked instead: a weekly written summary from the PM in Slack, which everyone actually read because it was in the channel they were already in.
Rigid sprint ceremonies — We tried running the full Scrum ceremony set. Retrospectives in particular felt performative at 45 minutes on a video call. We now run async retrospectives (a shared document, everyone adds notes, PM synthesises themes) with a 20-minute sync only when there's a genuine issue to resolve.
The Honest Truth
Remote engineering teams work extremely well when you hire the right people and build the right habits. They work poorly when you take a co-located team's practices and apply them to a distributed context without modification.
The practices above are not remote-work tips — they're engineering discipline. It turns out that discipline is the only thing that makes remote work. And it turns out that teams with that discipline produce better software than co-located teams without it.