The project manager is responsible for achieving project goals—that much is undisputed. But does this responsibility also extend to ensuring that:

* A high-quality product is developed?

* All technical teams collaborate closely?

* Necessary technical compromises are balanced and decided in alignment with brand promises?

* Product quality remains high, and competitiveness is maintained?

* Product design is executed efficiently and strategically for the future?

* The right technologies—mature yet innovative—are applied and their benefits fully realized?

* Components and systems are arranged for cost-effectiveness and optimal manufacturing?

These questions come up repeatedly in my discussions with project managers, project stakeholders, and team members in automotive development projects.

The situation becomes particularly controversial in our setup, where we have not only the actual project manager but also a manager for the product development sub-project. All within a matrix organization where the actual development work is performed in line departments with their own area responsibilities.

There's rarely a consensus on how these responsibilities should be allocated. That's why I want to describe both the collaboration and division of labor among the three roles that, in my experience, must be present in every project.

The Project Manager (Development Project Manager)

There are tree main types of project managers I encounter:

The Professional Project Managers have completed project management training and excel at project management.

When it comes to product responsibility, they say:

“I simply can't do that—I don't have the necessary qualifications. For this aspect, I need professional developers on my project team.”

The Hardcore Developers (like I was and still am) who are assigned project management roles.

When it comes to product responsibility, they say:

“Of course, I'll take responsibility. Why should I let others do something I can do well myself? I can handle that bit of project management on the side.”

There's also a third category: the Wannabe Developers who pursue project management roles because they want to have a say in how the product should look.

These individuals tend to interfere in development matters but aren't taken seriously by development teams.

You can probably guess where my recommendation is heading.

Project managers, or development project managers when they exist separately, are responsible for ensuring that all development activities are planned and executed on schedule. They're also responsible for facilitating product decisions when these are relevant to achieving project goals and exceed the product architect's scope of competence.

The technical responsibility for product design lies with the other two institutions I'll discuss in detail.

Let me briefly explain why the second and third scenarios aren't advisable.

Even project managers with strong technical product competence must give project management top priority.

If they do this properly, they simply don't have time to take on technical product responsibility—someone else must handle that.

However, technically competent project managers do have a significant advantage: they can recognize decision requirements from a distance and assess product maturity in relation to the required project progress based on their own expertise, planning necessary interventions in time.

For them, the challenge is “merely” shedding their old developer role and focusing on their new role as project manager.

The situation is more difficult for wannabe developers. In my experience, these cases require very resilient Project Management Masters who can provide necessary guidance when the project manager inappropriately interferes in development work.

Chief Engineer

The Chief Engineer is the supreme technical authority in the company and is legally personally responsible for product safety.

The Chief Engineer bears responsibility for:

* Ensuring development work is conducted according to current technical standards with appropriate diligence

* Ensuring the development organization is professionally and capacity-wise equipped for the project challenges

* Ensuring all necessary professional and legal processes are defined, documented, and trained

* Ensuring these processes are applied in every project

The Chief Engineer isn't a project team member but rather a project sponsor, even though they must play an active role in the project.

To fulfill this weighty responsibility, the Chief Engineer (who often carries the CTO title today) must regularly receive reports on product maturity progress in ongoing projects. When necessary, they must make timely and competent product decisions and formally issue Chief Engineer approval at project completion.

This Chief Engineer's approval signals that product maturity is sufficient for customer delivery, confirming that it poses no danger to people and the environment and doesn't compromise the company's financial stability.

The Chief Engineer is, therefore, a high-ranking executive and typically a member of the company's management board.

This presents the greatest challenge I frequently observe in practice:

Chief Engineers have so much on their plates with all the projects and other management responsibilities that they don't invest the necessary time and care to truly fulfill their role and responsibility in each individual product development project.

Yes, things often work out anyway. But I advise every Chief Engineer to take the time to carefully prepare for project milestones and quality gates, focusing on necessary adjustments in the development organization.

It's better to tell the CEO you can't attend a management meeting because you need to focus on an important project than to leave the project management team alone when they urgently need the Chief Engineer's help and support.

You might sense where this is going.

Behaving this way isn't necessarily easy, which tempts some Chief Engineers to delegate their responsibility to the project managers, allowing them to focus more on their boss and be available to them.

People, grow up! You're top managers—don't forget that. You can't always take the path of least resistance.

Product Architect

The Product Architect is comparable to an orchestra conductor, whose task is to create a harmonious musical piece from many individual voices.

The Product Architect integrates all technical disciplines into a unified product.

They bear responsibility for:

* Ensuring the product has inherent logic and structure.

* Defining product requirements and breaking down the contributions of individual components and systems to their fulfillment.

* Developing and establishing the architecture of the overall system and subsystems, ensuring implementation during product development.

* Coordinating and validating technical interfaces at the boundaries of functionally organized development areas.

* Ensuring modularity and platform rules are considered in product design.

* Harmonizing specified product properties and customer requirements, considering them in technical solution definitions.

There can be differing opinions on whether Product Architects should be organized as dedicated project resources or as cross-project line functions.

In my opinion, this strongly depends on the product type.

When developing a singular product, the Product Architect should be a dedicated resource for that specific project.

However, multiple product projects often work on a modular product platform, developing specific platform segments. In these cases, it's better to organize Product Architects as line functions that maintain an overview across all projects and hold the platform together.

Typically, one person isn't sufficient—specialized teams are necessary to provide the required capacity for each project.

When discussing the Product Architect's role, I must necessarily address Systems Engineering. The Systems Engineering methodology provides the toolkit that enables Product Architects to fulfill their tasks.

I consider it extremely important to extract Systems Engineering from the mechatronics corner.

Regardless of the product type, the product that customers buy and use is the system relevant to them. Therefore, Product Architects must start there and perform product synthesis at this level.

The responsibilities of Development Project Managers and Product Architects overlap in that both manage the project’s development team—Development Project Managers regarding development workflow, and Product Architects regarding technical product synthesis.

This naturally leads to the assumption that one person could handle both roles, reducing stakeholder contact points (especially for Chief Engineers) and saving personnel costs.

Don't do it! This leads to a lack of focus, and at least one aspect—workflow or content, probably both—will suffer.

The Project Leadership Trinity

In previous articles, I discussed Project Managers and Project Management Masters. In this article, I've added Chief Engineers and Product Architects.

You might now wonder how large a project team should be, according to my opinion.

With the Project Manager, Project Management Master, and Product Architect, I've described the three essential roles that should exist in every major project.

When dealing with matrix organizations as described in the last article, another role comes into play, which I'll describe in the next article.

So, stay tuned and subscribe to my newsletter so you don't miss that article.

That’s it for today. In further articles, I will go into detail about the roles and organizational structures required to do product development successfully.

If you have questions or recommendations, please write in the comments, or let’s chat.

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe