Post 6 – Juggling Programs: Prioritization Under Pressure

After scaling your team and building trust, a new challenge emerges: multiple programs, multiple OEMs, each with their own priorities, expectations, and timelines. Suddenly, your team isn’t just managing ten projects, it is managing ten projects for three different OEMs, spanning legacy programs, new launches, and proof-of-concept initiatives, all competing for attention. Everything feels urgent, and pressure comes from all directions.

This is the stage where many PMs and even experienced managers get stuck. When every customer thinks their program is the most important, it’s easy to default to reactive mode, answering the loudest voice, firefighting whichever crisis surfaces first. The result is chaos, misaligned priorities, and exhausted teams.

The first step to handling this is objective prioritization. Not “I feel like this matters more,” but systematic evaluation of impact, risk, and dependencies. Questions that help:

• Which program has the most critical deadlines for certification or launch?

• Which program carries the highest reputational or financial risk?

• Which issues block other programs or require shared resources?

• Where can trade-offs be made without violating contractual or safety requirements?

Once this triage is clear, communication becomes critical. Everyone, OEMs, internal stakeholders, and PMs, must understand the rationale behind prioritization. Transparency creates alignment and reduces friction. Conflicts are inevitable, but if the logic behind decisions is visible, most stakeholders accept constraints rather than assuming neglect.

A second layer of complexity is resource allocation across programs. The same engineers, testers, and system architects are often shared between programs. A delay or unexpected challenge in one program can cascade into another. Planning must be dynamic, balancing bandwidth against priority. You cannot over-commit, and you must constantly reassess as new information arrives.

At this point, another challenge emerges: team segmentation. With ten or more PMs, you cannot manage everyone directly. You need to divide the team into smaller, focused sub-teams, each with a designated lead or manager. These managers become your proxies, responsible for day-to-day alignment, issue resolution, and execution within their sub-teams. Managing managers requires a different skill set: you are no longer tracking tasks yourself, you are ensuring that your leads have clarity, authority, and the tools to act decisively.

This segmentation introduces its own complexity. Each sub-team must understand its scope, priorities, and interfaces with other sub-teams. Coordination becomes a layer of its own, requiring weekly touchpoints, consistent reporting formats, and clearly defined escalation paths. If segmentation is poorly handled, silos form, dependencies get missed, and trust erodes, undoing all the progress you made when building a cohesive team of ten.

This is where your muscle memory and example-driven mentoring pay off. Your PMs cannot be in every meeting or solve every conflict. What they can do is draw on patterns they have seen you handle in the past: negotiating scope with OEMs, escalating issues judiciously, balancing risk versus delivery, and deciding when to push back. Over time, each PM develops an internalized “sense” of priorities, allowing sub-teams to operate with autonomy and confidence.

Another important practice is segmentation of urgency and importance. Not every problem deserves immediate escalation. Some OEMs push for features or fixes that feel urgent, but the system-level impact is minimal. Part of your role as a team is to filter signals from noise, ensure that attention is focused on the things that matter most, and coach the sub-team leads to do the same.

Conflicting OEM needs often require creative compromise. Some features or schedules are mutually exclusive. Some demands clash with safety or regulatory requirements. In these cases, your managers and sub-teams must negotiate trade-offs transparently, document decisions, and communicate clearly so there is no ambiguity later. Ambiguity in multi-program environments is a hidden risk multiplier.

Finally, pressure from multiple directions is inevitable, and no process can eliminate stress. The goal is structured adaptability: frameworks, escalation paths, and shared principles that allow decisions to be made quickly without losing alignment or compromising quality. The team must learn to act decisively while keeping the bigger picture in mind.

The reward for mastering this stage is profound. Sub-teams start thinking beyond a single program, understanding system-level dependencies, and weighing decisions not just for one OEM, but for the health of all programs simultaneously. They begin to internalize what truly matters, rather than reacting to the loudest voice. And this is where multi-program organizations transform from reactive to proactive, capable of delivering complex projects under intense pressure.