Faisal Saleem
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 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.

A

Technology

Does it work — and can it actually be operated?

CloudInfrastructureArchitectureSecurityResilienceAutomation
B

Business

Does it serve what the company is actually trying to do?

Customer needBusiness priorityTimingGrowthInternal ownership
C

Commercial reality

Is it priced, committed and contracted correctly?

PricingProposalsContractsMarginsCommitmentsPayment structures
D

Operations

Can the organisation carry it, day after day?

TeamsDeliveryGovernanceProcessesSupportAccountability
E

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, not instead of.

LENS THIS SEAT ADDEDCARRIED FORWARD
SEATTECHMONEYCUSTOMERDELIVERYPEOPLECOMMERCIALCONTRACTOPSRISKWHAT IT TAUGHT ME
S1EngineerAdded: TECHSystems fail at 3am, not in meetings.
S2ArchitectAdded: MONEYEvery design is a bet about cost and failure.
S3ConsultantAdded: CUSTOMERCorrect and needed are often different answers.
S4DeliveryAdded: DELIVERYEvery promise lands on someone’s calendar.
S5Team leadAdded: PEOPLEPeople need clarity more than instructions.
S6CommercialAdded: COMMERCIAL, CONTRACTPricing is an architecture decision made elsewhere.
S7OperatorAdded: OPSEnough structure to make execution work.
S8ExecutiveAdded: RISKAccountable when none of it lines up.
SCROLL TO EXPLORE →SWIPE TO EXPLORE →

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 actually 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?
06 — Trace a situation

Pick a situation. See where I’d look.

The symptom usually shows up in one place. The cause is often two lenses away. This is roughly how I walk the map before recommending anything.

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 genuinely the bottleneck, or is the dependency map incomplete?

DELIVERY

Which milestone became unrealistic first?

PEOPLE

Who on the customer and delivery side actually 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 actually match the signed agreement?

LIKELY FIRST MOVE →

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

A DELIVERY PROBLEM: Re-baseline scope, ownership and delivery/payment milestones in one conversation — not three separate ones.

07 — Technology in business context

A cloud migration is not just architecture.

WHAT GETS DRAWN
Landing zoneNetworkWorkloadsSecurity controlsArchitectureConnectivity
The part everyone reviews.
WHAT ALSO DECIDES THE OUTCOMEBLUE — COMMON PRESSURE POINTS
CostRun-rate, not just 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.

08 — Selected work

Situations, not logos.

ILLUSTRATIVE — REAL CASES TO FOLLOW
i.

A migration contracted on a timeline the architecture couldn’t support

My role: executive sponsorship, delivery alignment, architecture and customer decision-making
SITUATIONA fixed go-live date and milestone structure had been agreed before the full dependency picture existed.
WHAT MADE IT HARDArchitecture, delivery, customer expectations and commercial commitments had stopped matching.
WHAT I FOCUSED ONScope, dependencies, ownership, customer alignment and milestones.
OUTCOMEScope and milestones were re-baselined with the customer. Go-live moved once — by agreement — and then held.
ii.

Managed services priced below what delivery actually cost

My role: commercial and operational leadership
SITUATIONA growing customer environment was consuming materially more effort than the commercial model funded.
WHAT MADE IT HARDThe SLA and support expectations exceeded the assumptions behind the original pricing.
WHAT I FOCUSED ONActual effort, operational ownership, service structure and the renewal model.
OUTCOMEEffort was measured against what the contract actually funded. Service tiers were restructured and repriced at renewal, and the customer stayed.
iii.

A DR programme scoped as infrastructure but blocked by ownership

My role: architecture and governance
SITUATIONThe infrastructure could be built, but application ownership, recovery priorities and business dependencies were unclear.
WHAT MADE IT HARDThe technology problem was solvable. The ownership problem was not.
WHAT I FOCUSED ONRecovery tiers, application ownership, service dependency, governance and accountability.
OUTCOMERecovery tiers were agreed with named application owners, and DR was tested against business priorities rather than server lists.
IN PREPARATIONRegional expansion into Saudi Arabia · Operating across UAE, KSA and Pakistan · Proposal versus contract alignment · Cloud billing structures · Customer escalation
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 genuinely improve the business?

WORK

Which repetitive work does it actually 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 · COMMERCIAL · 11 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 way to price the next three years honestly.

COMING SOON
The contract is the architecture document nobody readsESSAY · 9 MIN
Cloud credits are not a strategyNOTE · 4 MIN
When the AI is wrong, who signs for it?ESSAY · 8 MIN
Busy isn’t the same as movingNOTE · 3 MIN
Doing business across the GCC: what changes at the borderOBSERVATION · 7 MIN
Most DR plans are tested against the wrong failureESSAY · 6 MIN
Meetings happen. Decisions stay open.NOTE · 3 MIN
All writing — coming soon
11 — Engage

Sized to the question.

From one focused conversation to embedded operating leadership.

Indicative USD pricing. Scope and commercial terms are confirmed in writing before work begins.

60 MIN · VIDEO

Focused session

One question, one hour. Context beforehand and a short follow-up afterwards.

USD 300Request a session →
REVIEW + 90 MIN

Decision session

I review the proposal, architecture, commercial model or options beforehand. You receive a short written decision summary afterwards.

From USD 900Send material →
1–2 WEEKS

Operations & technology diagnostic

A focused review, ending in a prioritised action plan.

Delivery · cloud cost · resilience · ownership · operating model · governance · customer commitments · execution risk

From USD 4,500Scope it →
2 SESSIONS / MONTH

Mentoring

For technologists and emerging leaders moving from technical responsibility into leadership, commercial responsibility and broader decisions.

USD 600 / monthStart →
MONTHLY

Advisory retainer

Ongoing outside perspective, without adding headcount.

Technology · operations · commercial decisions · customer situations · delivery · leadership · management cadence

By conversationTalk →
3+ MONTHS

Embedded leadership

Fractional or embedded operating leadership, when the organisation needs execution alongside leadership.

Operating-model design · management cadence · customer escalation · commercial decisions · governance · execution discipline · accountability

Scoped individuallyDiscuss fit →

Where contracts are discussed, my perspective is commercial and operational — not legal advice.