I Screened 18 Technical Program Manager Candidates in Dubai and 14 Failed the Same Question: Here Is the 7-Step Process I Use Now

The question was this: tell me about a time you told an engineering director that their sequencing was wrong, and what happened next. Fourteen of eighteen candidates answered with a status meeting. They described how they surfaced a risk, escalated it, built a RAID log, got alignment. All of which is work, and none of which is the job. The four who passed described a specific technical disagreement, named the thing they were wrong about, and explained what they changed in the plan. That gap is the whole reason technical program manager searches in Dubai take twice as long as they should, and it is fixable at the briefing stage rather than in the interview.

First, the reason this role fails more often than the ones around it

A technical program manager has no team to hide behind. An engineering manager with a weak quarter still has a functioning team producing output. A TPM with a weak quarter has a programme that slipped and no direct reports to point at. The role is almost entirely leverage and influence, which means the hire either works quickly or visibly does not.

The second reason is that three genuinely different jobs share the same title. In Dubai specifically, where a lot of teams are scaling from one product line to several and where multi-vendor delivery is the norm rather than the exception, these three show up in different proportions than they would in a single-product company.

Step 1: Decide which of the three jobs you are funding

Write one sentence naming the outcome this person owns, and make it something that can fail. “Owns the delivery of the payments migration across the four teams that touch it, including the vendor integration, to a date the business has already communicated.” That sentence tells a candidate what they are accountable for. “Drive alignment and coordinate cross-functional delivery” tells them nothing, and it attracts the exact profile that answered my question with a status meeting.

Then settle the authority question in the same sentence, because this is where Dubai teams most often get caught. If the TPM can be overruled by any of the four engineering leads without escalation, you are hiring job 1 and should price and brief it that way. If they can hold a release, you are hiring job 2. Candidates read this accurately in the first conversation even when the job description does not say it, and the strong ones self-select out of ambiguous authority.

Step 2: Build the scorecard from your own delivery failures, not a template

Take the last three programmes that slipped and write down the actual mechanism of each slip. Not “poor communication”. Something closer to: two teams built against different versions of an API contract and nobody noticed until integration; or the migration had no rollback and the go-live was deferred twice because nobody would sign; or the vendor delivered to spec and the spec was wrong.

Those mechanisms become your scorecard. Four to six competencies, each with a specific behaviour you can interview for and grade. The useful property of a scorecard built this way is that it is yours: no two companies have the same three failures, so you stop competing on generic criteria and start selecting for the person who would have caught your specific problem. This is the same logic we apply when planning engineering headcount, and it is the step most often skipped under time pressure.

One discipline worth enforcing: decide the weighting before you meet anyone. If integration risk is the thing that keeps breaking, it carries more weight than stakeholder communication, and you should be willing to hire someone who is merely adequate at the second. Teams that leave weighting until after the interviews reliably talk themselves into the most articulate candidate.

Step 3: Source where programme evidence is already public

TPM CVs are the hardest documents in hiring to read, because the honest version and the inflated version use identical vocabulary. Both say “led a cross-functional programme of 40 engineers”. So source where the evidence exists independently of the CV:

• Conference and meetup talks about delivery, not technology. Someone who has presented a post-incident review, a migration retrospective or a dependency management approach has left a public artefact with their reasoning in it.
• Public engineering writing. Regional engineering blogs, internal-platform write-ups and migration post-mortems. You are looking for someone who describes trade-offs rather than wins.
• The engineers who worked under the programme. The most reliable TPM reference is a senior engineer who was two levels away from the programme and still knew what the plan was. Ask candidates for that reference specifically.
• Adjacent titles. In this market the right person is often currently titled delivery lead, staff engineer, or head of platform. If you filter on the exact title you will miss most of the pool, which is why we also recommend reading the delivery manager brief alongside this one and deciding deliberately which you are running.

Step 4: Replace the case interview with a 90-minute artefact screen

Case interviews reward fluency. The artefact screen rewards having actually done the work. Ask the candidate to bring a real plan from a real programme they ran, redacted however they need, and to walk you through it for 45 minutes while you ask questions for the remaining 45.

What you are reading is not plan quality, it is whether the plan has the fingerprints of someone who owned it. Specifically:

1. Does the plan show the dependency that nearly killed it? Real plans have one. Narrated plans are tidy.
2. Can they name the decision they got wrong? Not a humility performance, an actual sequencing or scoping call that cost time. The four candidates who passed my question all volunteered this before being asked.
3. Do they know what the engineers thought of the plan? A TPM who cannot tell you which team hated the sequence and why was not close enough to the work.
4. Is there a rollback or a kill criterion anywhere? Programmes run by people who have been burned contain both. Programmes run by coordinators contain neither.

Grade this against the scorecard from step 2 immediately, before you discuss the candidate with anyone else. A documented independent score written within ten minutes of the conversation is worth more than an hour of debrief consensus a week later.

Step 5: Interview the two failure modes separately

There are exactly two ways this hire fails, and they look nothing alike. Mode one: the candidate is excellent with stakeholders and cannot hold a technical line, so the programme drifts toward whatever the loudest engineering lead wants. Mode two: the candidate has strong technical judgement and burns the relationships needed to apply it, so they are right and ignored.

Run these as two separate interviews, with different interviewers, scored independently. The technical judgement interview should be led by an engineer senior enough to disagree, and should put a real contested decision from your own history on the table. The stakeholder interview should probe for influence without authority: a time they changed an outcome they could not mandate.

Do not let one interviewer cover both. The failure mode of a combined interview is that charisma reads as judgement, which is how mode one gets hired. If you want the people-management version of this distinction, the engineering manager process splits the same way for different reasons.

Step 6: Price the role against both markets it straddles

This is where good processes produce declined offers. A strong TPM candidate in Dubai is usually choosing between a senior or staff engineering offer and a programme leadership offer, and those two reference points can sit a long way apart. If you benchmark against project management alone, your number will look unserious to exactly the candidates you want.

Build the band from both references, then decide which one you are actually competing against for this scope. Job 2 from the diagram above competes with staff engineering. Job 1 competes with delivery leadership. Job 3 competes with whoever else is hiring for multi-vendor programme work, which in this market is often a systems integrator. Our salary calculator and the salary benchmark method give you the current reference points for the engineering side of that comparison.

Two practical notes for the UAE specifically. First, decide the band before the first call, because the single most common reason a TPM search restarts is a late discovery that the approved number cannot reach the shortlist. Second, be explicit about where the role sits on your ladder: a TPM with no direct reports still needs a visible progression path, and if yours does not have one, say so and compensate for it rather than letting the candidate discover it in month four. We cover that structure in the engineering career ladder guide.

Step 7: Write the 90-day proof and the kill criteria before the offer goes out

A TPM hire is unusually easy to evaluate early, and almost nobody does it, because nobody writes down in advance what good looks like at day 90. Do it before the offer, share it with the candidate, and you get two benefits: the strong candidates treat it as a sign of seriousness, and you stop the slow drift where a mediocre hire is still being given the benefit of the doubt at month eight.

What belongs in it:

• A dependency map of the programme that the engineering leads agree with. If they cannot produce this in 90 days, they are not close enough to the work.
• One sequencing decision they changed. Not necessarily a big one. Evidence that the authority from step 1 is real and being used.
• A communication cadence that the business stopped asking for updates outside of. This is the cleanest available proxy for trust.
• One named risk they retired, and one they escalated with options rather than questions.
• The kill criteria. Written plainly: if at day 90 the engineering leads still route around them, the role is not working, regardless of how good the status reports are.

The kill criteria matter more than the rest combined. A TPM who is being routed around is not underperforming, they are structurally unsupported, and that is usually a problem with step 1 rather than with the person. Finding out at day 90 lets you fix the authority question. Finding out at month nine means you re-run the whole search.

The three mistakes that cost us the most

Interviewing before the brief was settled. We ran six first interviews against a brief that changed twice. Every one of those candidates was evaluated against a role that no longer existed, and two of them were probably good. Settle step 1 even if it delays sourcing by a week.

Treating the title as the filter. Our strongest finalist was titled staff engineer and had never held the TPM title. Filtering on title is how a small pool becomes an empty one. Browse the project and programme management profiles and read for evidence of ownership rather than for a label.

Letting the debrief run before the scores were in. Once a room has heard one confident opinion, independent scoring is gone. Collect written scores first, then talk. This single change removed most of our disagreement about candidates, and the disagreements that survived it were the informative ones.

Frequently Asked Questions