No scaling story is clean. If you are managing 30 or 40 programs, you are statistically guaranteed to face a crisis. Programs fail. Customers escalate. Deadlines, even the "sacred" ones, are missed.
On the good days, leadership is about strategy and vision. But on the bad days, leadership is about thermodynamics. It’s about how you handle the heat. In the moments when a program is crashing, your leadership is visible in a way that no dashboard or success story can ever reveal.
The question isn't whether you’ll face a failure, but who you become when you do.
When a Tier-1 or an OEM customer is on the phone demanding answers for a missed milestone, the natural human instinct is to pass that pressure down. We want to find who is responsible. We want to demand immediate fixes. We want to "fix" the discomfort we feel by making the team feel it even more.
But panic is a contagion. If you react with blame or withdrawal, you aren't solving the problem, you are paralyzing the people who are supposed to fix it.
Real leadership under pressure is about slowing things down. While the organization is spinning, your job is to absorb the pressure, not amplify it.
You create a "buffer zone" between the external noise (the customer, the board, the angry stakeholders) and the technical execution. This isn't about hiding the truth, it's about creating the psychological space for recovery. If a PM is terrified of being blamed, they will spend 80% of their energy on self-preservation and only 20% on the solution. Your job is to flip that ratio.
Teams remember these moments long after the successes fade. They remember that when the ADAS system failed the final validation or the software release was pulled at the last minute, you didn't look for a scapegoat, you looked for the root cause.
Leadership in failure means:
Owning the "Who": You take the heat from above so the team can focus on the "How."
Focusing on the "Next": You pivot the conversation from "Why did this happen?" (Blame) to "What do we do now?" (Recovery).
Remaining Present: Withdrawal is the most subtle form of leadership failure. Don’t disappear when things get ugly.
I once lived through a textbook example of this. We were at the finish line of a massive, complex program. Everything was done, performance was great, and we’d cleared HLB, AEB, and Lane Centering certifications. We were two seconds from SOP, sailing safely into what looked like a miracle launch with time to spare.
Then, the safety audit hit.
In ADAS, everything relies on "Assumptions of Use" (AOU), the conditions the car must meet for the system to be ASIL safe. During the final audit, the OEM's car failed to meet those physical conditions. Technically, this wasn't "my" problem; the OEM had agreed to these terms three years prior. But in reality, if the project fails at the finish line, everyone loses.
When the OEM’s VP of EE realized the gravity of the failure, he called my lead PM. My lead, being honest and principled, told him the hard truth: "We cannot approve this deviation. The function is not safe."
Two seconds later, my phone rang. The VP was furious, shouting, screaming, and demanding that my lead PM be removed from the project immediately.
My first instinct was to fire back and defend my PM. But I chose to be silent. I let him vent. I let him scream until he had to stop for air. When the silence finally came, I didn't address his demands. I simply said: "I am here. How can I assist? What are our next steps? We will find a solution."
I ignored the noise and focused entirely on the path forward.
It took three days of "hell", flights to the OEM HQ, endless stress, and a team in a total spin of blame and defense. Eventually, one of the top engineers challenged the test itself. We discovered they had tested the car in a hall at under 10 KPH, while the AOU clearly applied only to speeds above that. When we hit the proving grounds, the car passed perfectly.
It was a storm in a teacup, but it nearly sank the ship. You might say we got lucky, but I don’t see it that way. The AOUs had been tested several times throughout the project. The real issue wasn't the physics, it was the fear. The stress of failure had set everyone into a spin. My job wasn't to be the smartest engineer in the room,
it was to be the person who refused to join the panic.
A failed program, a missed goal, or a missed target handled with integrity is often a better culture-builder than a project that ran on autopilot. It proves to the team that your talk about "trusted autonomy" and "failing forward" wasn't just corporate poetry, it was a promise.
When you show the team that you can handle the truth, they stop hiding the mess. And as we've discussed before, when you stop hiding the mess, you get more hands to help you clean it up.
#Leadership #CrisisManagement #EngineeringLeadership #OrganizationalCulture #PsychologicalSafety #Scaling #ProgramManagement #ADAS #GrowthMindset #Resilience
Comments
Post a Comment