Why MENA Engineers Ship Faster When You Remove the Approval Layer

There's a specific dynamic I've watched play out across Dubai and the broader Gulf — smart engineers sitting idle, waiting for a manager to approve a pull request, confirm a schema change, or greenlight a deployment that was already discussed in a standup three days ago. The code is ready. The tests pass. But nothing ships.

This isn't a talent problem. It's an approval layer problem.

What the Gulf Tech Context Actually Looks Like

MENA tech teams are often structured around hierarchy by default — partly cultural inheritance, partly the fact that many companies here grew from traditional industries (banking, real estate, logistics) where sign-off chains made sense for compliance reasons. When those same companies decide to build software, they carry the org chart with them.

I've worked across all of it: fintech, travel, fleet management, enterprise SaaS. The engineers are sharp. What slows them down is almost never competence — it's latency embedded into the structure itself.

At Etera AI, where we're building multi-agent LLM workflows for travel, the surface area of decisions is enormous: prompt versioning, agent handoff logic, context window strategies, retrieval pipeline tuning. If every one of those required a manager approval cycle, we'd be dead. The only way to move is to give engineers clear context, defined boundaries, and then get out of their way.

The Real Cost of Approval Layers

Every approval gate has a compounding cost that most engineering managers underestimate.

First, there's the context switch. The engineer stops, queues the request, picks up something else, then context-switches back — if the review comes back same-day, which it usually doesn't. Flow state is expensive to rebuild.

Second, there's the implicit message: you're not trusted to make this call. That message degrades initiative over time. Engineers start asking permission for things they should own. Ownership atrophies.

Third — and this is the one that kills velocity — approval layers train teams to make fewer decisions, not better ones. The goal should be more high-quality decisions made faster at the right level, not fewer decisions made slowly at a higher level.

What Flattening Actually Means (and Doesn't)

Removing approval layers doesn't mean removing accountability. It means moving accountability to the person closest to the problem.

In practice, this looks like:

• Clear decision tiers. Categorize decisions by reversibility and blast radius. A schema migration with no rollback path is a different category than changing a default timeout value. Define this explicitly, in writing, once.
• Context over instruction. Instead of telling engineers what to do, make sure they understand why — the product goal, the constraint, the tradeoff space. Engineers who understand context make better autonomous decisions than engineers who follow instructions.
• Async-first review culture. Reviews exist for knowledge transfer and safety, not gatekeeping. A PR review should take less than 24 hours. If it consistently doesn't, that's a structural problem, not a workload problem.
• Post-hoc accountability. Ship, observe, own the result. The retrospective is where learning happens, not the approval chain.

A MENA-Specific Tension Worth Naming

There's a real tension here that I won't pretend doesn't exist. In Gulf enterprises — especially those with regulatory exposure in banking, health, or government — certain decisions genuinely require sign-off. That's not bureaucracy; that's compliance. The Central Bank of UAE doesn't care about your deployment velocity.

The discipline is distinguishing those decisions from the hundreds of other daily engineering calls that don't carry that weight. I've seen teams where everything got funneled up to a VP because someone once got burned on a compliance issue and overcorrected. The result: compliance-grade friction applied uniformly to a React component refactor.

Map your actual risk surface. Protect what needs protecting. Leave everything else alone.

Building Engineers Who Don't Need You

The best thing I can do as an engineering leader is make myself unnecessary for day-to-day decisions. That's not abdication — it's leverage.

Here's how I think about it concretely:

text
High-trust, low-blast-radius → engineer decides, no review needed
High-trust, high-blast-radius → engineer decides, async peer review
Low-trust, any blast radius  → pair or shadow until trust is built
Regulatory or irreversible    → explicit sign-off, documented rationale

Trust is built by watching someone make good calls under pressure, not by putting them through approval loops. You build it deliberately — small autonomy first, then wider scope as the track record accumulates.

In the 15+ years I've spent building teams here, the engineers who grew fastest were the ones I handed real problems to early and stayed available for, without hovering. The ones who stagnated were usually in environments where they'd been trained to ask before acting.

The Talent Retention Angle

Dubai is competitive for senior engineering talent. The best engineers in the region have options — remote roles at global companies, well-funded Gulf startups, freelance work that pays well. If you're asking a senior engineer to wait two days for a ticket to move, you're not just losing velocity. You're giving them a reason to leave.

Autonomy is one of the highest-leverage retention mechanisms available to any engineering org, and it costs nothing to implement. The teams that keep their best people — in MENA and everywhere else — are the ones that treat engineers like the skilled professionals they are.

Remove the layer. Define the boundaries. Then let them build.