Why This Matters

There's a shift happening in how organizations are hiring for program and delivery leadership roles, and it's not primarily about scaling Agile or improving team velocity. What caught my attention across multiple roles this period—from McCarthy Holdings to State Street to JPMorgan Chase—is that employers are now asking program leaders to *design or redesign the operating model itself*, not just operate within one that already exists.

This is different from the traditional delivery-manager role. It's the difference between "execute the plan" and "design the system that decides which plans get executed." That's a meaningful shift in scope, accountability, and the type of leadership these organizations need. Understanding why this is happening, and what it means for how you position yourself, matters more than you might think.

What the Job Sample Is Showing

The McCarthy Holdings posting is the clearest signal: "Establish and operate a transparent, value-based portfolio and delivery model… creates the connective layer from envisioning through prioritization, execution, release, and maintenance." The role is explicitly building a "standardized portfolio-management operating model" and "one intake and triage funnel for organizational demand, with clear entry criteria, information requirements, decision rights, and ownership."

But it's not just McCarthy. State Street's program manager role describes the need to "work with the technology and business to define, document and implement appropriate program governance and execution." JPMorgan Chase's Lead Technical Program Manager is expected to "create, improve and maintain cadenced processes to ensure successful and consistent execution" and own "the Book of Work for engineering teams… aligned to OKRs." Princeton's Blueprint Transformation Program Manager needs to "establish governance routines including Steering Committees, program reviews, executive updates, RAID management."

Even more tactical roles show this. General Dynamics' Delivery Manager is expected to "understand the mission, business processes, and user needs" and "work with the program team, clients and customers to develop and maintain strategic product roadmaps." LMI's TPM for a VA Atlassian implementation is accountable for the "integrated program baseline" and must "translate stakeholder needs into actionable plans." Pearson's Advanced Specialist owns "dependency management, risk mitigation, stakeholder communication, release coordination, and execution transparency… as a single reliable view of what is in flight and at risk."

These roles share something: they're not hiring for someone to simply manage sprints or track tasks. They're hiring for someone who can see how work *should flow* through an organization, identify the gaps where it doesn't, and build the governance, decision rights, and communication structures to make it flow better.

What Problem These Requirements May Reflect

From a leadership perspective, this suggests something real about the organizations posting these roles: they likely have fragmented or outdated ways of deciding what gets built, funded, and prioritized. They have teams and initiatives, but no unified way to see them together. They have delivery happening, but no transparent view of interdependencies, resource constraints, or trade-offs across the whole portfolio. They have meetings, but maybe not the right meetings, with the right people, making the right decisions at the right time.

When an organization hires a Director or senior Program Manager with explicit responsibility for "designing the operating model," it often means one of several things: they've just gone through a reorganization and need someone to codify how work will flow in the new structure; they've merged or acquired new capability and need a single system of record for demand and delivery; they've grown to the point where informal coordination no longer works; or they've had too many misaligned initiatives and missed commitments, and they need someone to introduce discipline and visibility to the system itself.

None of these are shameful problems—they're actually normal growing pains. But they do explain why the job description now emphasizes *operating-model design* alongside delivery execution.

One practical observation: Pearson, McCarthy, State Street, and Princeton all mention the need for "transparency" or "executive-ready" reporting in multiple places. This isn't accidental. Organizations posting these roles are likely struggling with executive visibility into what's in flight, what's at risk, and why. The program leader is being asked to solve that partly through tooling (Jira, dashboards, integrated planning) and partly through governance structure (clear gates, decision cadences, RAID logs, dependency maps). It's both.

Potential Solutions — Leadership Framework

If you're being hired into one of these roles, or considering whether to take one, a few things matter:

*1. Clarify the scope of redesign you're actually accountable for.*

There's a world of difference between "here's the intake funnel, please run it" and "design the intake funnel from scratch, then run it." Both are real program-manager jobs, but they require different skills, differently paced success, and different stakeholder management. In the interview process, ask directly: Is there an existing governance model I'm expected to improve, or am I building one from zero? How much change appetite does the organization actually have? Who has to agree before I change a decision gate or add a review ceremony? Who funds the tooling? These aren't theoretical questions—they determine whether you succeed or flame out.

McCarthy's role explicitly says "the role is intended for a seasoned technical program leader who can build the operating model while also operating effectively within it." That phrase—*build while operating*—is crucial. You're not getting a runway to design in isolation. You're designing while managing live delivery. That requires a different approach: start with transparency and small visible wins, earn trust, then expand. Don't wait for perfection.

*2. Make the connection between operating-model design and business outcome visible from day one.*

Why do Pearson, State Street, and Cisco all emphasize "executive-ready" reporting? Because the real problem isn't data—it's that executives can't see what they need to see to make good decisions. When you redesign the operating model, you're not just adding meetings or processes. You're creating the visibility layer that lets leaders trade off priorities intelligently. Frame it that way from the beginning. Don't say, "I'm building a RAID log." Say, "I'm creating a single view of what's in flight, what's blocked, and what decisions we need to make this week—so we stop learning about surprises in status meetings."

MMcCarthy's role also mentions improving "how work is selected, planned, executed, released, and sustained." That's the full lifecycle. But the governance model you build should answer a specific question for leaders: *Is this investment actually going to deliver what we promised, or are we going to discover problems halfway through?* If you can make your governance structure answer that question clearly and early, you'll have executive buy-in to stick with it even when it's uncomfortable.

*3. Expect to work in two modes: architecture and operations.*

Several postings (McCarthy, State Street, Princeton, LMI) expect you to both *design* the model and *operate within it* immediately. This is harder than it sounds. When you're in architecture mode (designing decision gates, defining entry criteria, setting up Steering Committees), you're thinking at 30,000 feet. When you're in operations mode (tracking a release, managing a dependency, escalating a risk), you're in the weeds. The organizations hiring for these roles expect you to move between those modes fluidly and to use insights from one to improve the other.

One way to handle this: allocate your time explicitly. Spend the first 4–6 weeks observing and documenting how work *actually* flows (not how people say it flows). Then spend 2–3 weeks designing the target model. Then operate in it while continuously improving it. Don't try to do all three at once.

*4. Build decision rights and entry criteria first—processes and tools follow.*

McCarthy specifically mentions "decision rights and ownership" as part of the intake funnel. This is not a detail. When people don't know who decides what, or what information is needed before a decision can be made, you get slow, circular discussions and last-minute surprises. Before you implement a new review ceremony or tool, define: Who makes this decision? What information do they need? What alternatives should they consider? What happens if they say no? What happens if they say yes? When does this decision get made in the cycle? Document that, and the process and tools design themselves.

*5. Invest heavily in cross-functional stakeholder alignment, not just top-down enforcement.*

Pearson's role emphasizes "influence without formal authority." State Street talks about "partnership across technology teams." Princeton mentions "facilitate alignment between Business, Digital COE, and IT." None of these roles say, "issue directives." The operating model you design will only work if the people who have to follow it feel heard in how you designed it. That means genuine partnership with Product, Engineering, Finance, and business leaders—not consultation theater where you pretend to ask but have already decided.

This is the work that takes time but saves you months later. If you push through a new intake process without getting buy-in from the people who will use it, they will game it, work around it, or simply ignore it. If you design it *with* them, answering their concerns as you go, they'll defend it when it gets hard.

Practical Leadership Lessons

Here are a few things that experience suggests matter:

Operating models fail when they're too complex or too rigid. You'll be tempted to solve every edge case on day one. Don't. Start with the 80% case: How do we make decisions about the work that represents 80% of our demand? Once that's working, add nuance. Pearson's role mentions "process improvement"—that's continuous. Your first model is the draft.

The governance structure you build reflects (and shapes) the decision rights in your organization. If you create a gate where product and engineering vote together, you're embedding a partnership. If you create a gate where product decides unilaterally and then tells engineering, you're embedding hierarchy. Be intentional about what you're building, and be explicit with stakeholders about why. State Street's role mentions "drive the joint and internal governance." That word—*joint*—is doing real work. It signals partnership, not command.

Transparency is harder than it sounds, and it takes discipline. McCarthy, Pearson, State Street, and Princeton all mention "transparency" or "executive-ready reporting." Most organizations think they want transparency, but they don't actually want to see the hard truths. Your job is to make the hard truths visible, support teams in addressing them, and hold leaders accountable for acting on them. That's emotionally harder than it sounds, especially in the first few cycles. But it's the only way the model generates trust.

Your tooling should serve your governance, not replace it. LMI mentions "Jira migration, configuration, workflow and reporting standardization." These are real work, but they're not the point. The point is: do you have a clear, repeatable way to see what's in flight, what's blocked, what's at risk, and what decisions need to be made? If you do, the tool supports that. If you don't, the tool just gives you prettier spreadsheets of chaos.

My Professional Perspective

What interests me most about this sample is that it's not a trend toward a single "Agile operating model" or "SAFe at scale" template. McCarthy is building portfolio governance for a construction company's digital organization. State Street is coordinating Investment Management product delivery. JPMorgan Chase is building a Chief of Staff function. Cisco is managing security-platform roadmaps. Pearson is coordinating squads across onshore and offshore teams. They all need operating models, but there's no one model that fits all of them.

The real skill being hired for—across all these companies—is the ability to *see the system*, understand why it's not working the way it should, and redesign it in a way that's specific to that organization's constraints, culture, and business model. That's not a framework you can memorize or certify into. It's judgment. It's the ability to ask hard questions, listen to the answers, and design something that works *for this organization*, not something that works in theory.

If you're positioning yourself for one of these roles, that's what you should emphasize: your experience seeing how organizations actually make decisions, identifying where the system breaks down, and improving it. Show examples where you've redesigned a process or governance structure, measured its impact, and adjusted it when it wasn't working. That matters more than how many projects you've managed or how many ceremonies you've facilitated.

Discussion Question

When you've redesigned how a team or organization makes decisions—whether a meeting cadence, an intake process, a funding model, or a prioritization framework—what's been the biggest gap between how people *said* decisions got made and how they *actually* got made? And what surprised you most about what was really blocking better decisions? I'm curious whether that gap shows up consistently in certain types of decisions, or whether it varies by organization.

Evidence and methodology: https://ai.intelligence.strategichonesty.com/reports/the-operating-model-gap-why-program