Beyond Coordination: Rethinking the Design Program Manager Role

This week, I am digging into the Design Program Manager (DPM) role.

When I have had headcount to grow an operations team, I haven't spent it on DPM.

I staff based on capability gaps. I ask: what can this organization not currently do, and what is the smallest addition that changes that? Most companies already have Technical Program Managers (TPMs) supporting engineering, so program management is rarely the biggest gap—not even on the design teams I have supported. Usually, the urgent needs are research operations, content operations, or data operations. With the current push for AI transformation, the most significant gap is engineering ops.

As a result, I rarely hire a dedicated Design Program Manager, since TPMs already drive most program work.

I have been fortunate to work with exceptional TPMs who already handle intake, program management, blocker removal, dependency identification, and progress tracking. They are already managing the coordination.

When headcount is limited, I collaborate with the program managers already embedded in engineering and product, or whoever owns intake for the adjacent organization. Coordination still occurs; it just doesn’t require a dedicated person whose sole responsibility is coordination.

Previously, a full-time design coordinator might have made sense, particularly for large teams with complex deliverables. However, I am increasingly inclined to evolve this role. While this is a provocative stance, my goal is to help those in traditional DPM roles transition into broader, more strategic functions.

That is my assessment of my own teams. Yours will likely differ, and I encourage you to evaluate your own organization rather than simply taking my word for it.

To that end, I have built a worksheet to help you identify how your team can better structure its work.