Technical Project Manager

Where the delivery lead owns the commercial relationship, you own the mechanics: the plan, the dependencies, the environments, the release dates, and whether what we said on Monday is still true on Thursday.

One or two engagements at a time, sitting close to the engineers. This suits someone who reads the pull requests, knows what a migration is, and can extract an API key from a client's IT department without sending four reminders.

We keep process light, so this is judgment rather than ceremony. Nobody here wants a burndown chart for its own sake.

The mechanics of this job are automatable: status, notes, summaries, follow-ups. We'd rather you automated them and spent the time on the dependencies no one else is chasing.

• Turn the plan into a week. Priorities, dependencies, and the small decisions that unblock people before standup.
• Track from the work itself. Repositories, boards and environments, not a status meeting where everyone says fine.
• Chase the client side. Access, data, vendors, approvals, and the person who's on leave until the 14th.
• Coordinate releases. With the team and the client, including the dull pre-flight checks that prevent exciting evenings.
• Keep the record. Risks and decisions written where everyone can see them, so nobody relitigates last month.

• Three Years Running Software Projects: ideally with an external client and a real deadline.
• Agile Without Dogma: standups, planning and retros run because they help, dropped the week they stop.
• Reads Pull Requests: enough Git and code fluency to see a slip forming before the burndown admits it.
• Estimation Support: breaking work down with engineers, then holding the range instead of the wish.
• Release Coordination: environments, cutover plans, rollback, and the client sign-off that has to come first.
• Tracking Tools: Jira, Linear or Asana kept accurate without turning the team into data entry clerks.
• QA Coordination: knowing what has been tested, by whom, and what's still exposed.
• Technically Literate: repositories, environments, APIs and releases are familiar ground.
• Dependency Wrangler: you have delivered projects that depended on people who didn't report to you.
• Trusted Reporter: your status updates include the bad news, which is why people believe the good news.
• Organized For Others: your system doesn't require everyone else to adopt one.
• Fluent English, Written and Spoken: most of our work happens in a written thread or on a call, and both have to be clear. Arabic is a genuine advantage across the region.
• Automates the Admin: you use AI for status, notes and reporting, and keep your attention for the parts that need a human.

• Persistent: the fourth follow-up is as polite as the first.
• Anticipatory: you see the collision two weeks out, not on the day.
• Low drama: you solve it and tell people what changed.

• A background in QA, support or engineering.
• Coordinating mobile releases and app store timelines.
• You introduced a process that outlived your time there.

• Remote across MENA. Work from wherever you are in the region, with hours built around your team's overlap rather than someone's attendance spreadsheet.
• Work that ships. Products go live in weeks, not quarters. When someone asks what you have been building, you can open it on your phone and show them.
• Small teams, no ticket queue. Four to eight people carry a product from the first client call to handover. Nobody hands you a spec and disappears.
• Kit and tools you choose. A budget for your setup, and for the editor, licenses and services that make you fast. No three-week procurement saga.
• A learning budget with time attached. Money for the course or the conference, plus room in the week to use it. The second half is the part most places skip.
• Client contact from day one. You sit in the room where the decisions get made. Plenty of engineers wait a decade for that seat.
• Time off people take, and no timesheets. We measure engagements, not humans in fifteen-minute increments. Book the holiday, go, come back.