The case for a combined system program manager (SPM)

Staffing leadership roles in hardware development programs is an exercise in balancing budget constraints, client perceptions of need, and the shifting mix of available talent. The need to budget for “overhead” roles is often a hard sell with clients, particularly those with small programs where budgets are tight. 

The product development world also lacks broad agreement on leadership role definitions. In this article, I propose my own definitions, while making a case for merging the roles of system engineer (SE) and program (or project) manager (PM) into a single resource: the system program manager (SPM). It’s a two-for-one deal (or three-for-one if we pull in the role of product manager) that should help sweeten the budgeting medicine. This combined role can prove advantageous for supercharging innovation, even for large programs that could otherwise afford to fund two distinct individuals.

I expect pushback from those who may see the role of PM as strictly administrative. I contend that the role of SE should be given a bigger seat at the table, and that we need to rethink leadership roles to accommodate. I absolutely welcome your thoughts!

This is a big topic, and there’s lots to cover. First we delve into the definitions and importance of the roles: SE, PM, and product manager. Then we get into how and why it makes sense to roll them into one.

Note: In this article I use PM for program manager, not product manager.

SEs and PMs as heroes 

First, let’s understand why system engineering and program management are indispensable functions within hardware development programs. In my experience, it’s inevitable that a given program will encounter incidents where their talents are acutely needed. Absent these folks, programs will assuredly hit crises in need of SE or PM leadership, forcing other members of the team to overload themselves to compensate for the missing talent, with generally poor consequences and haphazard communication with the client.  

I’m not saying that SEs and PMs are only useful at times of crisis, but their absence is most apparent during these times. It’s always best to have them around from the beginning, so they don’t need to show up later as superheroes.

The required duties are inevitable whether they’re covered by dedicated resources or via random cycle-stealing across the team on a per-crisis basis. Guess which scenario is more likely to set up the client for success?

Explicitly budgeting and staffing for the roles always leads to better outcomes, happier clients and customers, more deterministic products, shorter time-to-market, and generally lower overall development costs.

System engineering  

SEs gather design intent and other high-level product requirements and translate them into digestible specifications and top-level engineering requirements. They start with whatever initial descriptions are available, including those that exist only verbally or scattered through emails, and then dive deep to uncover the myriad yet-to-be-clarified behaviors across the whole product.

Consider a situation where the requirements call out a light that must come on when someone approaches the product. A client may believe that such a simple statement fully defines the requirement. A sharp SE runs through a series of clarifying questions, such as:

How close should a person be before the light turns on? How far should a person be before the light turns back off? Should the light stay on for a minimum period of time? What color (temperature) is the light? How bright is the light? Can the brightness be adjusted? 

Many more unanticipated questions will arise solely around this light. The SE discusses these questions with the design team, the functional leads, and all other stakeholders, including the client. In addition to the implications to the customer experience, there are complexity, cost, and power consumption factors to consider. Requirements influence electrical, mechanical, firmware, software, design, and test team goals, and ultimately impact development and material costs. These teams need to know up-front what functionality their systems need to support, so they can pick the right components from the start and allocate resources properly.

The SE’s product requirements document 

The SE runs through the entire requirements set in this way, to arrive at a unified system design that all groups can work off, often across multiple organizations and geographies. The result is the product requirements document (PRD).

While SEs are highly technical, they aren’t expected to be deep experts across all fields. They inhabit the thinner air of system interdependencies and design/experience intent, and rely on strong communication skills to coordinate across design, engineering, leadership, and client principals. Although the PRD may be assembled by the SE, much of the submitted material comes from the individual functional leaders, who possess the deepest subject knowledge. Also, it’s critical to establish shared ownership of the specifications to ensure buy-in and compliance.

In practical terms, the PRD is rarely complete at project kickoff and is continuously a work in progress. It’s the SE’s job to stay on top of the project, to follow the progress of the engineering teams and their adherence to the PRD and system intent, and to surface new system-level questions as they arise. The SE can help with tough pivots by collecting trade-offs around experience, cost, complexity, time, and other risk factors, and bringing them to the collective table.

Flying blind without an SE

Going without a system engineer is a costly option. Remember that there’s always a system design, even if it’s just implicitly built upon undiscussed assumptions. The system is simply the thing you’re building. The trick is ensuring that everyone follows the exact same plan.

Think of the infamous tree swing pictures that you’ve doubtlessly seen. The cartoon is funny because it speaks directly to your own lived experiences.

In lieu of a staffed SE, managing uncertainties in the system design becomes dependent on senior members of the development team picking up the SE mantle whenever they happen to notice issues that need clarifying. Because it’s not their primary responsibility to be alert to system issues, the vigilance will be somewhat unreliable and inconsistent. 

Also, system engineering requires a blend of cross-disciplinary technical intuition and strengths in interpersonal coordination, skills that aren’t universally available, particularly among heads-down engineers. The result can be a system engineering practice that is highly nondeterministic and lacking in a single client-facing voice, which can cause confusion and damage business relationships. The consequences can lead to a compromised product that fails to meet experience and other product goals, or additional costly (money and time) design spins.

Program management

PMs coordinate multiple workstreams, positioning them against critical program milestones, while revealing and aligning cross-functional dependencies. They’re particularly critical in coordinating deliverables across multiple organizations. These organizations are frequently spread over multiple geographies. A common combination is the triad composed of you (the consultancy), your client, and a contract manufacturer (CM). Partnerships may bring in even more external teams.

Let’s pause to recognize that there’s no broadly agreed upon standard in defining leadership roles within hardware consultancy programs. The sort of PM that I’m discussing here is more aligned with what many call a technical program manager (TPM) role, which concerns itself more with engineering deliverables and less with tracking the financials and other administrivia. 

TPMs manage the overall schedule, maintaining a regular cadence of communication across all functional teams. Clarity in milestones is their primary mission. I personally prefer a simple Visio timeline versus a deeply detailed Gantt chart, since fine details are better left to the individual functions. The big picture items are the most critical, keeping all the functional teams aware of impending deadlines, and highlighting cross-functional dependencies.

To lessen the meeting load, ahead of the broad communication meetings, a good PM structures targeted pre-meetings to work out specific codependencies, for example, between the EE and ME workstreams around PCB mechanical specifications. These meetings have fewer participants.

Note that each functional team (EE, ME, FW, QA/test, design) should have a functional lead (sometimes called a discipline lead), operating as a mini-PM for their discipline. This person could be the team’s functional manager, or they could be a principal engineer within the team. The functional leads are responsible for scheduling and driving the deliverables within their particular functions, aligning the work to the schedule maintained by the TPM. There’s a close partnership between the functional leads and the TPM.

No project manager, no strings

Many clients push back on paying for a PM.

Absent a staffed PM, others on the team must provide the needed coordination of workstreams. These “armchair PMs,” experienced people with good intentions but with full day jobs, will overload themselves with PM responsibilities. As the program rolls on, exceptions will inevitably arise, and with no formal PM there will be nobody with the bandwidth available to work the seams and drive issues to solid resolution. Programs without dedicated PMs are at high risk of falling off the rails. After such failures it is very difficult to claw back credibility with a client.

Then there’s product management

Product managers are essentially front-line system engineers, blended with market savvy. They fly high, calling-out the highest levels of product requirements, to define a product aligned with intended markets. They care about features, cost, price, market adoption, and, often, product roll-out plans. In larger organizations, product managers also manage product roadmaps.

Product managers can help guide the initial scoping conversations, at times redirecting the clients from premature solutioning (“I need a wearable with Bluetooth”) to focused requirements discovery (“I need a wearable that can perform contact tracing”). This type of exercise opens the door to broader solutioning and a more optimized program. Further, it helps the client construct a product definition sheet at the customer feature level, not the component level, which enables a more targeted and thorough competitive market analysis.

Some clients already have their product definition sewn up, and they’ve completed their studies of market alignment. Even so, cost and price are critical components to nail down, in part because they inform the system architecture that your team will eventually need to own. This is true even if your team is only responsible for delivering a piece of the whole design. A product manager can help broker the right conversations, to ensure your team is working towards the right ends.

SE and PM really do go well together 

OK so we finally land on the theme: In the right circumstances, a single person could fill both SE (including product manager) and PM roles, enhancing program outcomes while minimizing impact to the budget. I call this person an SPM, a system program manager.

SE and PM roles should already be considered adjacent. The SE is a program leader, and the PM is already following system-level views while managing multiple work streams. It’s a natural blend, contingent on finding an individual with the right blend of skills.

Unique SPM talents

A great SPM must possess a particular set of skills:

• The ability to coordinate, manage, and represent multiple work streams
• A confident voice that cuts through the noise to represent program execution to the client with the requisite diplomatic and political sensitivities
• The broad multi-disciplinary foundation to develop and cultivate the system, drawing upon significant inter-personal communication capabilities

These skills may not be available within your current team, and you may find yourself initially looking to a contractor to fill the role until you can make the right hire. I believe you can cultivate the skillset internally from principal engineers who have good cross-disciplinary system understanding and significant experience with the various phases of hardware development.

Pro tip: It’s vitally important to champion the duality of this role, to prevent one side or the other becoming overly dominant. Also, avoid the temptation to overload a functional lead to be the SPM. 

To empower the role, streamline and clarify both sides, with particular care not to overload the PM side, which should be primarily focused on driving and coordinating work streams (as a TPM). The narrowing of the PM side is likely the most controversial requirement for establishing a SPM role, particularly among old-school PMs. Also controversial is handing-over work stream management to an SE.

To make this idea work, the SPM must remain highly technical and focused on driving the program as a TPM. They’re not responsible for the business side. Even if they’re the ones to raise a flag regarding program risk or needed rescoping,  they’re not the ones to hammer out the financial consequences. They must surface their concerns to the correct people.

SPM as innovation accelerator

Pulling SE into PM pulls innovation closer to the engineering work streams. The SPM is uniquely placed to evaluate program tradeoffs that arise from new innovations or discoveries. The SPM can entertain new ideas, internally or from the client, and immediately assess the impact to program schedule or other risks.

This idea deserves reframing: an SPM follows the development of the system closely, and immediately becomes aware of technical challenges, and, importantly, areas that require invention, and thus targeted experimentation. This sort of feasibility risk reduction is critical to manage, and it’s highly valuable for the SE and PM functions to be closely aligned.

With larger programs, we might see fewer budgetary advantages in combining SE with PM, but I would argue that the benefits of the SPM role persist, naturally tying together innovation with the engineering work streams. With an outsized program, I’d scale not by splitting back to separate SE and PM resources but by adding additional SPMs, carving the program up into subsystems. With greater scale, you might consider adding a TPM to coordinate those SPMs.

About the Author: Carl Picciotto is a member of the informal network, and deeply experienced with all aspects of the end-to-end product development process, system engineering methodologies, and architecting engineering engagements with clients. Carl was a researcher at Hewlett Packard Labs commercializing new technology for HP’s printing and imaging businesses, a Senior System Engineer at Microsoft developing PC Hardware and Microsoft Surface products, and a Senior Manager at Accenture leading engineering teams and driving new client business. Want to work with Carl on an upcoming project? Click the link below to tell us more!

informal is a freelance collective for the most talented independent professionals in hardware and hardtech. We’re always looking for engineers, designers, brand strategists, and other professionals to join our team. If you’ve got a skill that you think we need, let us know! We’d love to chat. And of course, if you’ve got a hardware product or product idea you want to bring to market, we have just the experts to help! Fill out this quick form and we’ll be in touch!.