Seven years engineering remotely from the Gulf
Lessons from years of remote and distributed work across Saudi fintech and academia — on communication, ownership, and doing work that speaks for itself.
I spent the better part of seven years working remotely and across distributed teams, first at Argaam in Riyadh and later leading digital projects at UBT in Jeddah. Remote work rewards a specific set of habits that are easy to underrate.
Here are the concrete lessons I have learned from shipping production software remotely in the GCC region.
1. Write everything down (Asynchronous Alignment)
In a distributed team, the written record is the team. If a decision, technical trade-off, or architectural design isn’t documented, it doesn’t exist.
Good writing is not overhead; it is how remote teams stay aligned without constant meetings. Over the years, I developed a simple template for proposing technical changes (similar to RFCs or Architecture Decision Records) that saved hundreds of hours of synchronous debate:
- Context: What problem are we solving?
- Proposed Solution: High-level design.
- Trade-offs: Why this approach over alternatives?
- Impact: Database migrations, breaking API changes, or deployment risks.
2. Own outcomes, not hours
Nobody is watching you type, and that is the point. Remote engineers who thrive are those who take a problem, drive it to a result, and surface blockers early.
Being recognized as Employee of the Year during fully remote service came down to owning outcomes:
- Be Proactive: Don’t wait for tasks to be assigned. Look at the product backlog and find bottlenecks.
- Communicate Blockers: If an API integration is down or a database schema update is blocked, flag it with options: “We are blocked on X. We can either do Y (adds 2 days but is cleaner) or Z (quick hack but adds technical debt). I recommend Y because…”
3. Let your work speak (Visibility through Delivery)
When you are not physically in the office, your shipped code and documentation represent your reputation. Trust is built through:
- Clean Commits: Commit messages that explain why a change was made, not just what was changed.
- Automated Tests: Shipping features accompanied by integration tests showing that you verified your own code.
- Impeccable Documentation: Keeping readme files, code symbols, and API specs up-to-date.
Takeaway
Remote engineering is less about tools and more about communication and discipline: communicate in writing, own results, and ship work you would be proud to be judged by.