Chief engineer decision-making power: OEM vs supplier approval depends on the project’s documented responsibilities. An OEM engineer may control the finished product’s requirements, while a supplier engineer controls the design or process assigned to that supplier. A job title alone does not settle who can approve a substitution, accept a deviation or release a revised component.
The useful distinction is between proposing a change, evaluating it, approving it and releasing it. One person may handle several tasks, but a technical recommendation should not silently become permission to ship. The approval boundary needs to be clear before a shortage, drawing conflict or production problem forces a decision.
Chief engineer decision-making power: OEM vs supplier responsibilities
A chief engineer’s influence and formal approval authority are different things. The Lean Enterprise Institute’s description of Toyota’s chief engineer illustrates the distinction: the role coordinates a product’s development, yet many contributors report through their own functional departments. That example explains why technical leadership does not automatically confer control over every purchasing or production decision.
For an OEM–supplier project, a practical starting point is to ask who owns the requirement and who has been assigned approval of the affected design. The answer may change between a supplier-designed module and a component manufactured to an OEM drawing. It can also change when a proposal affects another assembly’s interface.
The matrix below is an example to adapt to the project’s agreed responsibilities. It is a planning aid, not a universal organizational hierarchy.
| Decision | OEM engineering role | Supplier engineering role | Record to agree |
|---|---|---|---|
| System requirement or external interface | Define the required outcome and affected system constraints. | Explain feasibility, limitations and proposed interfaces. | Requirement baseline and designated approver. |
| Supplier-owned detailed design | Review effects on agreed requirements and interfaces. | Develop and control the assigned design. | Design responsibility and customer review boundaries. |
| Change to an OEM-controlled drawing | Evaluate and approve through the assigned design authority. | Propose the change and provide supporting evidence. | Change request, disposition and released revision. |
| Manufacturing-process adjustment | Review when the agreed notification or approval boundary is affected. | Assess process capability and identify product consequences. | Process-change criteria and any required approval. |
| Nonconforming item or temporary deviation | Route acceptance to the authority assigned for that requirement. | Identify affected items, deviation and containment. | Written disposition, limits and affected quantities. |
| Commercial order or delivery commitment | Coordinate with the responsible purchasing and project functions. | Coordinate feasibility with the supplier’s commercial team. | Commercial agreement separate from technical release. |
Design ownership defines the approval boundary
In a build-to-print arrangement, the supplier needs a route for resolving questions about the customer’s controlled drawing. In a supplier-designed arrangement, the customer still needs visibility of changes that affect agreed performance or interfaces. These are useful distinctions to write into the project plan rather than infer from the label “OEM supplier.”
NASA’s configuration-management guidance offers a relevant method: identify a baseline, designate the change authority, evaluate proposed changes and maintain the configuration record. Its program procedures belong to NASA’s context. The transferable idea is to keep the approved definition of the product connected to what production actually builds.
A team can make that idea concrete by identifying the controlled document, its revision and the function responsible for each decision. An email expressing interest in a proposal is not a substitute for a clear release record. Equally, a purchase order should not be used as an unexplained technical approval.
A substitution needs more than a matching description
Consider a hypothetical equipment project: the supplier proposes a replacement connector because the specified item is unavailable. Its catalog description appears similar, and the proposed delivery date is earlier. That is enough to start a review; it does not establish that the replacement satisfies the project’s requirements.
The supplier can prepare a comparison against the actual specification: mating interface, operating conditions, relevant ratings and any affected qualification evidence. The OEM’s assigned design authority can assess effects on the complete assembly. Quality can determine what acceptance evidence the agreed process needs, while purchasing addresses availability and commercial terms.
If the change is accepted, the release record should identify the replacement, approved revision and applicable production scope. A temporary acceptance for a limited batch needs a different record from a permanent drawing change. Without that distinction, a one-time exception can become an unintended standard component.
The same review discipline is useful when comparing an electrical component against a category such as AC surge protection devices: a shared product description is only a starting point. The project still needs its own requirements and documented selection decision.
Make the approval record usable by the next team
A useful change record lets someone outside the original conversation understand what happened. The following fields form an example handoff checklist:
- Baseline: affected part, drawing, specification and current revision.
- Proposal: requested change, reason and intended application.
- Assessment: affected requirements, interfaces, evidence and unresolved questions.
- Decision: designated approver, disposition and conditions.
- Release scope: revision, effective production point and any quantity or time limits.
- Closure: confirmation that the approved change reached the relevant drawings, purchasing and production records.
When teams disagree, the first question is which requirement or authority assignment remains unresolved. A technical meeting can compare evidence and record the remaining decision. It should not replace an explicit approval boundary with whoever speaks most confidently or offers the shortest lead time.
The chief engineer’s most useful contribution is to make the technical consequences understandable and connect the right decision makers. A clear specification, a named organizational responsibility and a traceable release make that influence usable across both companies.
References
- Lean Enterprise Institute: Chief Engineer — an organizational example of cross-functional technical leadership.
- NASA Systems Engineering Handbook: Configuration Management — baselines, change authority and configuration records.