In each phase of my career when I took on a program management role, I reached out to the experts on the team to learn more in-depth about their fields. When leading a multi-national effort on multi-chip modules, I had hours-long sessions with a senior engineer to refresh my memory about signal integrity and packaging issues. When pushing new standards for high-speed interconnect chips, I had many, many lessons from analog engineering about PLL design, and with digital engineering about encoding techniques, encryption, pipelining, etc. Most recently, leading a project to produce test equipment, I dug into the software design with the help of the programming team to discuss partitioning the code, overlays, call-backs, compiled versus open source issues, etc.
In all of these cases, my involvement as an engineer with each team went above being the program manager, and generated a lot of trust and confidence both for them and for myself.
A common situation I’ve seen in program management is the style to simply report status up the line. I don’t really know if this is because they expect upper management to resolve any program issues or not. I see many program managers also trying to fulfill their responsibilities as lead designers or lead programmers, and many without the skills or temperament to drive a program.
I have approached program management with the idea that issues should be reported up the line, but solved within the team whenever possible. I try to get inside the head of the team members, to understand why their part may be in trouble. But in addition to empathy, I try to emphasize that a schedule is a schedule, and their “Yes” means “Yes”.
Sometimes the best solution is to partition the situation into a near-term fix and a long-term fix. This is usually not part of the initial plan, which is oftentimes overly optimistic. But it does provide a way of escape for the sub-group in trouble, with the commitment to finish the work at that second phase. Designing an interim PCB, or interim firmware, adds costs and extra work, but may create a deliverable which lets another part of the project move forward. Delaying for days or weeks debating which micro-controller to use, or which programming API calls to implement, is just a delay: move forward and learn! The trick as program manager is to use this approach only as a last resort, and not as an excuse for delaying schedules. Ideally, the groups learn from this experience, and build in interim deliverables to the schedule of the next project!
Another part of my approach is to give the credit for fulfilling the schedule to those who do the work. Thankfully, I usually have had my own individual responsibilities, on which I rely for my own satisfaction. So I give the team members the satisfaction of finishing a complex project.
It’s very gratifying to look back on many, many products which have come to market through good program management in which I’ve had a hand.