An engineering team between Cairo and Riyadh: 7 operating rules learned from fifty distributed projects
Remote work is no longer a debate; it is the default reality for any Arab software company selling to the Gulf. But “remote” makes some teams succeed and others fail with equal force. These seven rules are what made our …
Remote work is no longer a debate; it is the default reality for any Arab software company selling to the Gulf. But “remote” makes some teams succeed and others fail with equal force. These seven rules are what made our distributed teams deliver on time — and what we learned the hard way before that.
1. Writing before meeting
Every decision starts as a short document: the problem, the options, the recommendation. The meeting decides; it does not explore. When we applied this, meetings dropped 40% and decision quality rose because everyone read before speaking.
2. Overlap hours are sacred
From 10 AM to 3 PM Riyadh time, everyone is available — however their day is arranged. Outside that, work is asynchronous. The engineer in Cairo is not expected to answer at 9 PM, and the client in Riyadh knows when to find someone who answers.
3. The engineer faces the client
No wall of account managers. One group, in which whoever writes the code participates. Technical questions are answered in minutes, not days, and the engineer hears “why” from the source.
The distributed team that works is the one where any member can explain to the client what was built today — in one sentence, in Arabic.
4. AI as a colleague, not a secret
Everyone uses Claude Code and Cursor, and the usage rules are written in the repository (CLAUDE.md and review rules). Whoever hides that they used an agent is wrong; whoever merges code they did not read is more wrong.
5. Review within 24 hours or reassign
A PR that waits two days kills remote momentum more than anything. The rule: review within one working day, or it is automatically reassigned to another reviewer.
6. A quarterly in-person meetup
Not to solve a problem but to prevent one. A team that met once tolerates a terse message more than a team that never met. And for Gulf projects, visiting the branch in the Kingdom at launch is not a luxury.
7. Measure output, not presence
No monitoring software, no screenshots. What is measured: delivered tasks, review quality, client satisfaction at the end of each stage. Whoever finishes in four hours is not asked to sit for eight.
What we failed at first
- A daily stand-up at a time that suited Riyadh and exhausted Cairo — replaced with a written update.
- Assuming everyone writes well — they did not, so we trained for it.
- An account manager “protecting” engineers from the client — who actually protected problems from being discovered.
For the engineer considering a distributed team
Be ready to be visible through writing rather than presence, to talk to the client directly, and to be measured by what you deliver. These are not constraints; they are the freedom most engineers wish for — with one condition: discipline.
