Many young engineer would have a question in their mind: “How do I become a Functional Safety Manager?”
It is a good question. Because many engineers enter Functional Safety believing that growth comes from learning HARA, FSC, TSC, Safety Goals, FMEDA, FMEA and Safety Case preparation.
These things are important. But they are not enough. I have seen engineers become very strong in documentation and still struggle to grow into larger safety roles because they never move beyond the work products.
A Functional Safety Manager is not just someone who tracks open actions, updates safety plans, schedules reviews and ensures templates are completed.
A Functional Safety Manager is someone who can understand the vehicle function, connect system, software, hardware, cybersecurity and SOTIF teams, challenge assumptions, drive difficult decisions and create confidence that safety is being built into the program. In the beginning, many engineers think Functional Safety is about documents.
Over time, they realise it is actually about leadership, influence, engineering judgement and the ability to ask the right questions before problems become hazards. That is why the first few years matter so much.
The habits, mindset and technical depth built early in a career can define whether someone remains a work product owner or grows into a true safety leader.
Learn the Vehicle Function Before the Standard
One of the biggest mistakes young engineers make in Functional Safety is that they start learning the standard before learning the vehicle function. They become familiar with ASILs, Safety Goals, HARA tables and confirmation reviews, but struggle when asked simple questions such as:
“What exactly is this feature supposed to do?”
“How does the driver interact with it?”
“What can go wrong in the real world?”
“What happens if another system behaves unexpectedly?”
A good Functional Safety Manager must first understand the item itself.
For example, if the system is AEBS, Lane Keep Assist, Battery Management System or Steering, you should understand:
- What the function is intended to do
- How the customer uses it
- Which sensors, ECUs, software and actuators are involved
- What dependencies exist with other systems
- What the safe state looks like
- What happens if the function becomes unavailable, unintended or insufficient
The standard gives you the framework. But the vehicle function gives you the context. Without understanding the context, it becomes very easy to create safety goals, FSRs and TSRs that look good in a document but do not fully protect the customer in the real world.
The best safety professionals usually spend time understanding the actual function, system behaviour and operational scenarios before opening the template.
Understand the System Architecture, Not Only the Work Products
Many engineers become very comfortable with creating HARA, FSC, TSC, DIA, Safety Plan and Safety Case documents. But when discussions move towards architecture, interfaces, failure propagation, redundancy or fault handling, they struggle to participate.
A Functional Safety Manager cannot depend only on document reviews. They should understand how the system is actually built.
This means understanding:
- Sensors, ECUs, actuators and communication networks
- Hardware and software interfaces
- Signal flow and decision logic
- Redundancy concepts and fallback paths
- Fault detection, fault reaction and safe state strategy
- Dependencies on power supply, communication and external systems
- Interactions with cybersecurity, diagnostics and SOTIF concepts
For example, in an AEBS system, it is not enough to know that a braking request exists. You should know:
- Which sensors detect the object
- How sensor fusion happens
- Which ECU makes the decision
- How the brake request reaches the braking system
- What happens if one sensor fails
- What happens if communication is lost
- Whether the driver still has enough time and control to react safely
The stronger your architecture understanding becomes, the easier it becomes to identify weak assumptions, hidden dependencies and unrealistic safety requirements. Strong Functional Safety Managers do not only review documents. They understand how the function behaves inside the vehicle.
Build Strong Communication Skills Across Teams
Many young engineers believe that technical knowledge alone is enough to succeed in Functional Safety. In reality, some of the biggest safety failures happen not because people lack technical capability, but because teams fail to communicate with each other. A Functional Safety Manager works with multiple groups including:
- Systems Engineering
- Software
- Hardware
- Mechanical
- Validation
- Cybersecurity
- SOTIF
- Supplier Quality
- Program Management
- Manufacturing and Service Teams
Each team has different priorities, different language and different pressures. Software teams may focus on deadlines. Hardware teams may focus on cost and packaging. Program teams may focus on timing. Suppliers may focus on scope and commercial boundaries.
A Functional Safety Manager must be able to bring all these teams together and ensure that safety risks do not get lost between functions.
This means learning how to:
- Ask the right questions
- Explain safety concerns in simple language
- Handle disagreement professionally
- Challenge risky assumptions
- Escalate issues when needed
- Build trust across teams
- Keep discussions focused on customer risk rather than internal politics
A good safety professional does not only write requirements. They create alignment. In many programs, the person who communicates clearly often has more influence than the person with the most technical knowledge.
Learn Cybersecurity and SOTIF Along With Functional Safety
Many engineers still treat Functional Safety, Cybersecurity and SOTIF as separate activities. In reality, modern vehicle programs rarely allow these areas to remain independent.
A Functional Safety Manager who only understands ISO 26262 may struggle when the real issue comes from a cybersecurity threat, a limitation in sensor performance or an unexpected operational scenario. For example:
- A camera may fail because of glare, fog or heavy rain
- An object may be detected too late because of a limitation in perception performance
- A communication signal may be manipulated through a cybersecurity weakness
- An OTA update may unintentionally affect a safety-related function
- A radar and camera may both work individually but still create an unsafe decision because of sensor fusion logic
These situations may not always begin with a random hardware failure. Sometimes they come from intended functionality limitations, software behaviour, human misuse, environmental conditions or cyber attacks.
That is why future Functional Safety Managers should build at least a working understanding of:
- ISO 21448 SOTIF
- ISO 21434 Cybersecurity
- Sensor limitations and operational design domain
- Software update risks
- Cross-domain dependencies between safety and security
- Human machine interface and driver behaviour
- Real-world scenarios beyond the normal use case
The strongest safety leaders are usually the ones who can connect these topics together rather than treat them as independent silos.
In future vehicle programs, safety leadership will increasingly depend on how well someone can integrate Functional Safety, Cybersecurity and SOTIF thinking into one discussion.
Understand Supplier Management and Shared Responsibilities
Many safety issues in vehicle programs do not happen because a requirement was missing. They happen because people assumed someone else was responsible. In modern vehicle development, multiple suppliers may be involved in sensors, ECUs, software, actuators, diagnostics, communication networks and cloud-connected services.
A Functional Safety Manager must understand where responsibilities start, where they end and where they overlap.
This becomes especially important when working with:
- Tier 1 suppliers
- Software suppliers
- Semiconductor suppliers
- Sensor suppliers
- Validation partners
- Platform teams
- Internal cross-functional teams
Young engineers should learn how to clearly define:
- Who owns each safety requirement
- Who creates and reviews work products
- Who is responsible for verification and validation
- Who manages assumptions and dependencies
- Who communicates safety changes
- Who approves deviations and open points
- Who is responsible for production, service and field monitoring activities
This is why documents like Development Interface Agreements become so important. A DIA is not just a contractual document. It is a tool to prevent confusion, gaps and duplicated assumptions across organizations.
Strong Functional Safety Managers do not assume everyone understands their role. They make responsibilities visible early before the project reaches a crisis.
Learn to Challenge Assumptions During HARA and Safety Concept Development
One of the biggest risks in Functional Safety is not missing a document. It is accepting weak assumptions too early. Many HARA workshops and safety concept reviews become very mechanical.
Teams quickly agree on Severity, Exposure and Controllability ratings without spending enough time questioning the scenario itself. People may assume:
- The driver will always react correctly
- The failure will always be detected in time
- A backup path will always be available
- The environmental condition is rare
- The misuse scenario is unrealistic
- The communication loss will only last for a short duration
- Another system will always behave correctly
These assumptions can become dangerous because they often remain unchallenged until late validation, field complaints or even incidents.
A strong Functional Safety Manager should develop the habit of asking questions such as:
- What if the driver does not react?
- What if the failure happens during overtaking or cornering?
- What if two faults happen together?
- What if the driver receives too many warnings and ignores them?
- What if the environment affects sensor performance?
- What if another dependent system is already degraded?
- What if the function behaves correctly but still creates an unsafe outcome?
The quality of the HARA and safety concept often depends more on the quality of the questions than the quality of the template.
The best safety professionals are usually the ones who are willing to slow the discussion down and challenge assumptions that others accept too quickly.
Move From Document Ownership to Safety Leadership
In the beginning of a career, many engineers are judged by how well they complete templates, track actions and maintain documents. That is normal.
But long-term growth in Functional Safety comes when you stop thinking like a coordinator and start thinking like a leader. A Functional Safety Manager is not only responsible for maintaining the Safety Plan, arranging reviews or collecting evidence for audits.
They are responsible for building confidence that the vehicle will behave safely in the real world.
That means learning how to:
- Influence difficult decisions
- Escalate concerns even when they are unpopular
- Balance timing, cost and safety pressures
- Defend safety requirements during management discussions
- Drive closure of open issues
- Support teams during conflict
- Build a culture where people speak up early
Many engineers wait for authority before they start acting like leaders. But in reality, leadership often begins much earlier. It starts when you take ownership of a risk, ask difficult questions, protect the customer and continue pushing for the right decision even when it creates discomfort.
The difference between a Functional Safety Manager and a true Safety Leader is usually not the title.
It is the mindset.
Many young engineers enter Functional Safety thinking that success comes from learning the standard, completing the work products and passing the audit. Those things are important. But they are only the starting point.
The engineers who grow the fastest are usually the ones who understand the vehicle function, question assumptions, communicate across teams, understand architecture, connect safety with cybersecurity and SOTIF, and take ownership beyond their formal role.
Functional Safety is not only about preventing failures. It is about protecting people. That is why technical knowledge alone is not enough.
The future belongs to engineers who can combine engineering depth, systems thinking, communication, leadership and the courage to make difficult decisions.
Because in the end, a Functional Safety Manager is not remembered for how many templates were completed.
They are remembered for how confidently they helped the organization build a safer product.
