The Operating Model Job Nobody Actually Hired For
(12)
Overview
A real IT Project Manager posting at a major international NGO lists "define the operating model" as responsibility #9 of 9, after mobile app architecture, defect resolution, and release planning. That placement is the diagnosis, not a footnote.
Year
2026
Industry
Cross-sector (Humanitarian / International Organizations)
Challenge
A recent IT Project Manager posting at a major international humanitarian organization tells you everything about how operating model risk actually gets staffed. The role: lead a mobile app rollout, QR codes, OCR, integration with existing systems, across four operational centers. Required: a master's in computer science, five years building and shipping mobile software, fluency in two languages. Buried at responsibility nine of nine: "lead workshops and activities to define the operating model and ensure successful transition to business-as-usual after implementation." Read that placement carefully. The organization knows the operating model has to be defined, they wrote it into the job description. But they didn't give it its own hire, its own budget line, or its own timeline. They gave it to whoever's already staffed on the technical build, on top of a full technical scope, as the last bullet before the qualifications section.
Impact
Composite pattern, seen across sectors: a multi-site technology rollout gets a technical owner with a technical mandate. Somewhere in the scope document, someone adds a line about "operating model" or "change management" or "business-as-usual transition", because everyone involved knows, correctly, that the technology won't stick without it. Then the org staffs the technical role, screens for technical qualifications, and hopes the person they hire also happens to be good at decision-rights design and stakeholder governance across multiple semi-autonomous business units. Sometimes that person exists. Usually, the operating model work gets the leftover hours after sprint planning, defect triage, and go-live prep, which is to say, it gets almost none. The rollout succeeds technically and stalls organizationally, and six months later someone asks why adoption is stuck at one region out of four. The fix isn't hiring harder for a unicorn who can do both. It's separating the two mandates before the req goes out: staff the technical build as a technical build, and staff the operating model work, decision rights, cross-unit governance, business-as-usual transition, as its own named accountability, with its own time and its own owner. If a job description needs a bullet point to remind itself that the operating model matters, that's the signal the organization hasn't yet decided it matters enough.