Electric vehicle system-of-systems showing interconnected global supply chain elements including mining, manufacturing, and charging infrastructure. Custom AI-generated illustration created by SE-Scholar.

How the electric vehicle supply chain became a lesson in stakeholder identification

When I teach the Stakeholder Needs and Requirements Definition process, I like to ask my students a question that sounds almost silly until you think about it for a moment.

“If you develop a system that sits out in the field and the system’s runoff goes into a nearby stream and a cow in the next county drinks from that stream and dies, is the cow, or the owner of that cow, a stakeholder?”

The room usually goes quiet. Then someone ventures a tentative yes, and then someone else pushes back, and before long the class is having exactly the conversation I was hoping for. Because the question is not really about cows. It is about how far the system boundary actually extends, and how easy it is to draw that boundary in a way that conveniently excludes the stakeholders who are hardest to see.

The INCOSE SE Handbook is unambiguous on this point. Stakeholders include any individual, group, or organization that can affect or be affected by the system across its entire life cycle [1]. That definition does not come with a proximity clause. It does not say “stakeholders who interact directly with the finished product” or “stakeholders the design team is likely to meet.” It says affected. And affected can mean a farmer in the next county whose cow drinks from a stream your system contaminated, just as easily as it means the end user reading the owner’s manual.

Most Systems Engineering teams start their stakeholder identification with the obvious candidates: operators, customers, maintainers, regulators. These are visible, accessible, and easy to prioritize. The problem is not that those stakeholders get identified. The problem is that the list tends to stop there, because the stakeholders beyond the immediate system boundary are separated by geography, by layers of abstraction, and sometimes by the simple fact that no one on the design team has ever thought to look for them. They may never use the system. The design team may never meet them. But the system still affects them, and their interests still represent real requirements that the system will either address or ignore.

Which brings me to Rubaya.

*Miners work at the D4 Gakombe coltan mining quarry in Rubaya, Congo, May 9, 2025. (AP PhotoMoses Sawasawa, File)*

The hillside did not fail all at once. First came the rain, then the slow softening of the soil, and finally the collapse. At the Rubaya mining site in eastern Congo, hundreds of miners were working underground when the earth above them gave way, burying tunnels carved by hand in search of coltan and cobalt [2]. Tumaini Munguiko was among those who made it out. Many others did not. In the days that followed, he helped bury his friends and joined families searching for loved ones, all while coming to terms with the fact that he had survived when others had not. “Seeing our peers die is very painful,” he said. “But despite the pain, we are forced to return to the mines to survive.” [3]

The minerals extracted from sites like Rubaya flow into a global supply chain that enables electric vehicles, widely described as a cornerstone of clean energy transition [4]. The engineers who design those vehicles are, in a very real sense, participants in a system that extends all the way back to those tunnels in eastern Congo. The driver, the manufacturer, the charging infrastructure operator are the stakeholders that appear on most requirements documents. The miners who extract the lithium, cobalt, and nickel that make the batteries possible are separated from the finished product by so many layers of suppliers, processors, and logistics networks that it becomes genuinely easy to treat them as someone else’s problem [5]. But the INCOSE definition does not offer that exemption. If the system affects them, they are stakeholders. And if they are stakeholders, their situation represents a category of requirements — ethical, societal, supply chain, and risk-related — that a complete Systems Engineering process should at least surface and examine.

This is not an argument that Systems Engineers are responsible for fixing everything upstream of their system boundary. It is an argument that Systems Engineers are responsible for knowing where that boundary actually is, and for making a deliberate and honest effort to identify who falls outside the convenient version of it. My classroom question about the cow is lighthearted by design, because humor lowers defenses and gets people thinking before they have decided what answer they are supposed to give. But the underlying discipline it points toward is serious. Instead of asking only who uses the system, good stakeholder analysis also asks who is affected indirectly, who supplies inputs to the system, who depends on its outputs, who is impacted during maintenance or disposal or failure, and what environmental or societal systems interact with this one. These questions shift the analysis from a narrow product view to the broader system-of-systems perspective that complex, globally distributed systems actually require.

The goal is not to achieve a perfect and complete stakeholder list, because no such thing exists for a system as interconnected as an electric vehicle supply chain. The goal is awareness, and the discipline that comes from treating the question seriously rather than stopping when the obvious names have been written down. Missing a stakeholder early does not make that stakeholder go away. It makes them a late-stage surprise, the kind that shows up as unanticipated requirements, regulatory challenges, supply chain disruptions, or the kind of ethical consequences that no amount of clever engineering can easily repair.

The farmer in the next county is a stakeholder. So is Tumaini Munguiko. The question is whether anyone thought to ask. So here is a harder version of that same question, the one worth carrying out of the classroom and into your next program:

When you drew your stakeholder boundary, did you draw it where the system’s effects actually stop, or where they became inconvenient to follow?

Optional Reader Resource

This worksheet is designed as a companion to a Systems Engineering article and aligns with the INCOSE Systems Engineering Handbook. It supports the Stakeholder Needs and Requirements Definition process by guiding practitioners to systematically identify, categorize, and analyze stakeholders associated with a man-made system within a defined scope.

Download: Stakeholder Identification & Analysis Worksheet