F. SaleemCOO, SUDO Consultants · Dubai

01 · Technology & business operator

I’ve built it, sold it, signed it and run it.

I started in infrastructure and engineering. Today I work across technology, customers, commercial decisions, contracts, teams and operations, usually where several of those collide.

Usually, the difficult part isn’t the technology. It’s understanding the real problem, making the decision and getting it executed.

How I think →Work with me →

NOWCOO, SUDO Consultants

BASEDDubai, UAE

OPERATING ACROSSUAE · Saudi Arabia · Pakistan

STARTED WITHLinux · VMware · Infrastructure

02 · The intersection

The work sits where five things meet, and they usually disagree.

I have been the engineer expected to make it work, the architect designing it, the consultant explaining it, the team delivering what was promised, and the executive accountable when those things don’t line up.

Technology

Does it work, and can it be operated day to day?

CloudInfrastructureArchitectureSecurityResilienceAutomation

Business

Does it serve what the company is trying to do?

Customer needBusiness priorityTimingGrowthInternal ownership

Commercial reality

Is it priced, committed and contracted correctly?

PricingProposalsContractsMarginsCommitmentsPayment structures

Operations

Can the organisation carry it, day after day?

TeamsDeliveryGovernanceProcessesSupportAccountability

Execution

Will it get done, and still work a year from now?

MilestonesDependenciesEscalationDecision-makingOwnershipFollow-through

03 · Seats at the table

The same problems, from eight different seats.

This is not a timeline. Each seat changed what I notice. Together they’re why I read a situation the way I do. Explore a seat.

Now the outcome is mine: the customer, the margin, the people, and the architecture underneath.

SEAT VIII · EXECUTIVEAccountable when none of it lines up, and expected to know why.

04 · Where I’ve sat

Each seat added a lens. None of them went away.

Hands-on infrastructure to business leadership, layer by layer. Each one added, none replaced.

LENS THIS SEAT ADDEDCARRIED FORWARD

TECHMONEYCUSTOMERDELIVERYPEOPLECOMMERCIALCONTRACTOPSRISKWHAT IT TAUGHT ME

S1EngineerSystems fail at 3am, not in meetings.

S2ArchitectEvery design is a bet about cost and failure.

S3ConsultantCorrect and needed are often different answers.

S4DeliveryEvery promise lands on someone’s calendar.

S5Team leadPeople need clarity more than instructions.

S6CommercialPricing is an architecture decision made elsewhere.

S7OperatorEnough structure to make execution work.

S8ExecutiveAccountable when none of it lines up.

SCROLL TO EXPLORE →

S1Engineer
ADDED · TECHSystems fail at 3am, not in meetings.
S2Architect
ADDED · MONEYEvery design is a bet about cost and failure.
S3Consultant
ADDED · CUSTOMERCorrect and needed are often different answers.
S4Delivery
ADDED · DELIVERYEvery promise lands on someone’s calendar.
S5Team lead
ADDED · PEOPLEPeople need clarity more than instructions.
S6Commercial
ADDED · COMMERCIAL + CONTRACTPricing is an architecture decision made elsewhere.
S7Operator
ADDED · OPSEnough structure to make execution work.
S8Executive
ADDED · RISKAccountable when none of it lines up.

Formed in enterprise environments including Cisco, du and UAE government technology projects · Operating across UAE · Saudi Arabia · Pakistan · Customers and partners across the Middle East, US, Europe and Asia

05 · How I think

How I think about a problem

A technical problem is usually also a cost, ownership, customer or contract problem.

A business decision still has to survive being implemented.

So I usually begin with questions.

I prefer practical answers to impressive ones.

01What is actually happening?

02What is the real problem?

03What are we assuming?

04Who owns the decision, and the outcome?

05What happens to the customer and the team?

06What does it cost, and what’s already committed?

07What does the contract require?

08Where is the operational risk?

09What happens if we do nothing?

10What are we missing?

11What is the simplest workable solution?

12Will it still work a year from now?

LOOKS LIKE: A DELIVERY PROBLEM

Usually it’s more than that: a scope, ownership and commercial alignment question.

Illustrative situations. Not client specifics.

TECHNOLOGY

Is the platform the real bottleneck, or an incomplete dependency map?

DELIVERY

Which milestone became unrealistic first?

PEOPLE

Who on the customer and delivery side owns each dependency?

CUSTOMER

What was originally communicated compared with what is happening now?

COMMERCIAL

Was the scope sold before the architecture was sufficiently understood?

CONTRACT

Do the milestones and commitments match the signed agreement?

LIKELY FIRST MOVE →

Re-baseline scope, ownership and delivery/payment milestones in one conversation, not three separate ones.

07 · Technology in business context

A cloud migration is more than architecture.

WHAT GETS DRAWN

Landing zoneNetworkWorkloadsSecurity controlsArchitectureConnectivity

The part everyone reviews.

WHAT ALSO DECIDES THE OUTCOMEBLUE · COMMON PRESSURE POINTS

CostRun-rate as well as build

LicensingWhat moves, what breaks

DowntimeWhose weekend, which window

ResilienceAgainst which failure

SecurityShared responsibility, in practice

CommitmentsSpend you’ve already promised

CreditsAnd what happens when they end

Operating modelWho runs it on day 2

SupportTiers, hours, escalation

CapabilityWhat the team can own

ExpectationsWhat the customer was told

ScopeIn writing, not in the room

ContractsSLAs, liability, exit

Payment structureMilestones vs. reality

OwnershipOf each application

After go-liveThe part nobody priced

Architecture matters. It also sits inside a commercial and operating system that decides whether the design survives contact with the customer.

Growing into new markets where every country worked differently

My role: regional operations, commercial structure and coordination across teams

SITUATIONServices were expanding into new countries, each with its own rules for contracts, tax and billing.

WHAT MADE IT HARDWhat worked in one market broke in the next, while customers still expected one consistent service.

WHAT I FOCUSED ONOperating model, contract and billing structure, local requirements, financial exposure and consistency.

OUTCOMEOne operating model with agreed local variations. Each market could contract and invoice correctly, and customers saw the same service everywhere.

ii.

A critical agreement stuck between two legal departments

My role: commercial lead, negotiation and coordination between both legal teams

SITUATIONA key agreement had stalled for weeks while each side’s lawyers kept rewriting the other’s changes.

WHAT MADE IT HARDBoth legal teams were protecting their own position, the business deadline was close, and neither side wanted to concede first.

WHAT I FOCUSED ONThe real commercial risks, which clauses mattered, a fair middle ground and the decision-makers on both sides.

OUTCOMEThe open points were narrowed to a handful of real risks and settled in one joint session. The agreement was signed before the deadline, with the relationship intact.

iii.

A customer’s service stopped when a licence expired

My role: customer escalation, distributor negotiation and recovery

SITUATIONA customer’s licence subscription lapsed without warning, and the services that depended on it stopped working.

WHAT MADE IT HARDIt lapsed over a weekend. The renewal sat with a distributor, the customer’s purchase order was still waiting for approval, and their operations were down.

WHAT I FOCUSED ONRestoring service first, the distributor and vendor, who pays for what, and making sure it could not happen again.

OUTCOMEThe distributor agreed an urgent renewal ahead of the paperwork, with costs settled afterwards. Service was back the same day, and renewal dates are now tracked well in advance.

iv.

Delivery delays caused by ownership, not technology

My role: operational oversight, escalation and delivery accountability

SITUATIONProjects kept stalling because critical work depended on a handful of people rather than clear ownership.

WHAT MADE IT HARDResponsibilities were spread thin, so every unresolved issue came back to the same few people.

WHAT I FOCUSED ONOwnership, delegation, resourcing, escalation paths and accountability.

OUTCOMEEach workstream got a named owner and an agreed escalation path. Fewer issues bounced back to the same people, and delivery dates became predictable.

09 · On AI, practically

The questions before anyone opens a model.

Many AI opportunities turn out to be workflow, data and accountability questions before they are model questions.

VALUE

Where does it improve the business?

WORK

Which repetitive work does it remove?

DATA

What does the model see, and where does it go?

CONTRACT

What do privacy, customer and vendor agreements allow?

FAILURE

What happens when it is wrong?

ACCOUNTABILITY

Who remains accountable for the outcome?

10 · Writing

Things I’m thinking about.

FEATURED ESSAY · 4 MIN

Why the cheaper proposal usually costs more in year two

Cost rarely disappears in a vendor comparison. It moves into your team, your support model and your renewal. A simple way to compare three years honestly.

READ

When the AI is wrong, who signs for it?ESSAY · 3 MIN Doing business across the GCC: what changes at the borderOBSERVATION · 3 MIN Busy isn’t the same as movingNOTE · 3 MIN Cloud credits are not a strategyNOTE · 3 MIN The contract is the architecture document nobody readsESSAY · 4 MIN Most DR plans are tested against the wrong failureESSAY · 3 MIN All writing

60 MIN · VIDEO