UK strategy, Egypt engineering: what has to be true for it to work

"UK strategy, global engineering" is a common enough pitch that it has stopped meaning anything. Every firm with an offshore office says a version of it. The interesting question is not whether the model works — plainly it can — but what specifically has to be true for it to work, and what it costs when those things are not true.

We run this model. Raversys is the UK parent; Raqmix is our group company in Egypt. This is an account of what we have found the model actually requires, including the parts that are inconvenient.

The timezone claim is usually overstated

The standard version is "follow the sun": work continues while you sleep, so you get more done per calendar day. In practice this is only true for work that can be handed over cleanly, which is a narrower category than it sounds.

Egypt runs two hours ahead of the UK in winter and one in summer. That is not a follow-the-sun relationship; it is a substantially overlapping working day. Which is better for most software work, not worse.

The reason is that handover has a cost. Work passed between people who have never spoken loses context at every boundary, and the loss is largest for exactly the work that benefits most from continuity — debugging, design, anything requiring judgement. A genuine twelve-hour offset buys you elapsed time and pays for it in context. A two-hour offset buys you a shared working day, which is when the valuable conversations happen.

So the honest claim is not "we work while you sleep". It is "we work when you work, at a cost base that differs". That is a smaller claim and a more durable one.

What actually has to be true

Domain knowledge cannot live only at the UK end. The failure mode of every distributed model is the same: strategy is held in one place and execution in another, so every non-trivial question becomes a round trip. The engineers build precisely what was specified, the specification was subtly wrong, and nobody downstream had enough context to notice.

The fix is not more documentation. It is putting engineers close enough to the problem that they can recognise a wrong requirement. That means direct contact with the client, which means giving up the neat account-management layer that makes distributed delivery look tidy on an org chart.

One team, one process. Two teams with a contract between them will optimise for the contract. The UK side writes specifications defensively; the delivery side implements them literally; both are behaving rationally and the product suffers. The alternative is a single backlog, a single definition of done, and shared responsibility for outcomes rather than for deliverables.

Seniority has to be distributed. If every senior engineer sits in one country, the other becomes a implementation shop regardless of intent, because the decisions accumulate where the experience is. This is the hardest of these to get right and the most visible when it is wrong.

Language precision, not language fluency. Fluency is common and rarely the issue. What matters is precision about uncertainty — whether someone will say "I don't think that requirement is right" rather than "yes". That is partly cultural, largely a function of whether disagreement has been safe in the past, and it is the single strongest predictor we have seen of whether a distributed team produces good work.

Data residency changed the calculation

Until recently the location of engineering work was mostly a commercial question. It is increasingly a regulatory one, and the two do not always point the same way.

Egypt's Personal Data Protection Law and its Executive Regulations define cross-border transfer to include storage, which means data held on infrastructure outside Egypt is treated as a continuous transfer requiring authorisation. We wrote about the architectural consequences in Storage abroad is a transfer.

The relevant point here is that this cuts against naive offshoring. If an Egyptian entity's personal data has to stay on Egyptian infrastructure, then an architecture that defaults to a US or European region is a problem regardless of how good the engineering is. Conversely, a UK client with UK data has UK GDPR obligations that constrain where their data sits, and having engineers in Egypt does not by itself move that data anywhere.

The distinction that matters is between where work is done and where data lives. These are separable, and conflating them produces both unnecessary anxiety and genuine breaches. An engineer in Cairo working on a system whose data never leaves London is a different proposition from a system whose database sits in a region chosen for convenience.

Getting this right requires the architecture to make residency explicit — which environments hold real data, which hold synthetic, who can reach what, and whether your non-production environments are quietly full of production records. That last one is where we find most problems.

Where the group structure earns its place

Our arrangement splits along a deliberate seam. Raversys holds the UK advisory relationship — discovery, architecture, the regulatory position, the decisions. Raqmix holds delivery capacity and, through its Delta platform, the ability to deploy on Egyptian infrastructure when residency requires it.

The value of this is not primarily cost, though cost is real. It is that we can give an honest answer to "where should this run?" without the answer being determined by which infrastructure we happen to have. A group that can deploy in the UK, in Egypt, or on a client's own infrastructure can afford to recommend whichever is correct.

The corresponding risk, which we would rather name than let a client discover, is that group structures can be used to obscure who is accountable. Our answer is that the UK entity is accountable for the engagement regardless of where the work happens. If that is not what a contract says, the contract is wrong.

What we would ask a supplier

If you are evaluating a distributed model — ours or anyone's — the questions that separate substance from marketing are fairly specific:

1. Will engineers talk to us directly, or through an account layer? If the answer is the latter, expect round trips on every ambiguity.
2. Where do senior people sit? Ask for the actual distribution, not the headline.
3. Is there one backlog or two? Two means a contract boundary inside your project.
4. Where does our data live, in every environment? Including staging, backups and analytics — the answer for production is the easy one.
5. What happens when the delivery team disagrees with the specification? The answer reveals whether you have bought thinking or typing.
6. What is the retention like on our account specifically? Distributed models fail slowly through turnover, because context is the asset being lost.

We would rather be asked these than not. A client who asks them tends to get a better engagement from us, which is a reasonable argument for publishing them.

What we have got wrong

It would be a poor article on this subject that only listed the conditions for success, so here are the ways we have seen the model fail in our own work.

We have under-invested in written context. A highly overlapping working day makes conversation easy, which makes it tempting to settle things verbally. That works until someone is on leave, or a new person joins, or a decision needs revisiting six months later and nobody can reconstruct why it was made. The remedy is unglamorous — decisions recorded where they can be found — and the cost of skipping it is paid slowly.

We have let the UK end become a bottleneck. When the client relationship sits in one place, there is a natural pull for every clarification to route through it. That preserves tidiness and destroys throughput. The fix is uncomfortable: put delivery engineers in front of the client, accept the loss of control, and trust that a well-briefed engineer asking directly beats a well-intentioned account manager relaying.

We have mistaken availability for alignment. A team that is responsive and pleasant to work with can still be building the wrong thing. Responsiveness is easy to observe and alignment is not, so the former gets used as a proxy for the latter. The check is to ask delivery engineers to explain, in their own words, why the client wants a feature. If the answer is a restatement of the requirement, alignment has not happened.

We have been slow to say when the model does not fit. Some engagements genuinely want everyone in one room — very early-stage discovery, or work with heavy in-person stakeholder contact. The commercial pull is to fit those into the model anyway. Resisting that is the right call and we have not always made it quickly enough.

We publish these because a supplier who describes only the upside is describing marketing rather than a delivery model, and because a client who knows the failure modes is better equipped to hold us to avoiding them.

In practice

The model works when it is a single team that happens to span two countries, and fails when it is two teams with a handover between them. Everything above is a restatement of that.

Our dedicated engineering teams are structured on that basis, and our delivery model sets out the specifics. If the honest answer for a given engagement is that the work should sit entirely in one country, that is the answer we would give.