Making Quality Systems Accessible for Engineers

The Secret to China and Tesla Speed? - ASPICE. (It’s their gold standard) Not The truth - software engineers don’t care for ASPICE. They see it as a burden. ASPICE is vague, outdated, and written in a language software engineers don’t use. Ask software engineers what the gold standard is, and they’ll say: ➜ DevOps, CI/CD, Shift-Left (TDD/BDD) ➜ Automate everything, exploratory testing ➜ Microservices, contract-first design Yet ASPICE, the so-called “automotive software engineering gold standard,” doesn’t even mention these terms. Instead, it defines required work products like: ➜ Review record, change history, configuration item As if we’re still in the 90s, storing printed change logs in physical ledgers. But today? ➜ We work cloud-based, collaboratively. ➜ Changes take minutes, everything is versioned. ASPICE Isn’t Fundamentally Wrong—It’s Just Stuck in the Past. The real issue? Software engineers hate it. Quality managers love it. It was designed by OEMs to control big-budget waterfall projects at suppliers— Not to empower high-speed, iterative software engineering. The goal back then? Minimize risk. Control. Assign blame. The goal today? Speed. Relentless testing. Transparency. Trust. Lightning-fast iterations. “The Engineers Are Right.” The methods and tools must suit them. If you want great software, you need happy engineers. That should be Quality’s priority. But in my experience? ➜ Quality managers say, “Engineers must understand ASPICE.” ➜ They should be saying, “How do we make ASPICE work for engineers?” Quality Should Enable Engineers—Not Slow Them Down. Instead of forcing rigid, outdated processes, quality should focus on: ➜ Automated compliance → Integrated into CI/CD, not manual bureaucracy. ➜ GenAI-enabled tooling → Seamless, intuitive, guiding engineers without friction. ➜ Process guardrails that feel invisible → Supporting, not obstructing. It’s no mystery. Look at Tesla’s DSM (Digital Self-Management). Quality at Tesla isn’t about checking boxes—it’s about removing friction so engineers can move fast. But what I see most of the time? ➜ Quality creates processes that make quality managers happy. ➜ Engineers just work around them. That’s the real problem. What’s the fix? ⤷ Quality needs to evolve—or get out of the way. What’s your thoughts? What’s your gold standard in automotive software development?

When I joined my previous company, the quality landscape was barren—no QA team, no processes, just chaos: • Deployments resembled Russian roulette • Production defects were our unintended “features” • Engineering credibility was at an all-time low I implemented a systematic approach to transform our quality practices: 1. Architected a comprehensive QA framework 2. Established dual testing methodology: exploratory testing + automated regression suites 3. Integrated QA engineers into sprint planning and design reviews as first-class citizens. The metrics spoke volumes: • 85% reduction in critical production incidents • Release velocity increased by 40% • Mean time to resolution cut in half But the most profound revelation wasn’t technical—it was cultural. When engineers began owning quality as part of their definition of done, we witnessed a paradigm shift. Our mantra evolved from “ship fast, fix later” to “we don’t deploy until we’re proud of what we’ve built.” Quality isn’t just a checkbox or a dedicated team—it’s a mindset that permeates every git commit, every review, and every deployment. #SoftwareQuality #DevOps #EngineeringExcellence #TestAutomation #QualityCulture

If QA Has to Be the Gatekeeper, the System Is Already Broken One of the most common anti-patterns I’ve seen in 30 years of QA leadership is this simple phrase: “QA will catch it.” When QA becomes the final gate before release, quality has already failed upstream. Gatekeeping feels comforting. It creates the illusion of control. But in reality, it’s a signal that quality has been outsourced instead of embedded. In immature systems, QA is expected to: Validate incomplete or shifting requirements Compensate for rushed development Absorb schedule risk at the very end Make release decisions with limited context That’s not quality assurance. That’s damage control. In high-performing organizations, QA doesn’t block releases. They shape them. Quality lives in: How work is defined and decomposed How risk is surfaced early and continuously How pipelines provide fast, actionable feedback How teams decide when “done” is actually done My role as a QA Director was never to enforce quality through authority. It was to design systems where the right decision is the easy decision. That means: CI pipelines that expose instability immediately Clear ownership of quality signals across teams Shared accountability for risk—not finger-pointing at QA QA engineers embedded early, not waiting at the end When QA has veto power, engineering maturity is low—even if delivery appears fast. The goal isn’t fewer bugs at the end. It’s fewer surprises throughout the process. And if your releases still depend on QA heroics, don’t celebrate it. Fix the system that made heroics necessary. #QualityAssurance #QALeadership #QualityEngineering #SDET #EngineeringLeadership #DevOps #CI_CD #SoftwareQuality #TechLeadership #ContinuousImprovement

Shift Left Quality is following the same evolutionary path that SysAdmin → DevOps → Platform Engineering did. Software engineering evolves in spirals — revisiting old problems but solving them with new levels of maturity. Years ago, development teams built code and handed it to SysAdmins for deployment. As systems grew more complex, this silo broke down. DevOps emerged to close the gap, and eventually Platform Engineering arose to provide scalable, self-service tooling for developers. This transformed Ops work into platform products. Today, Quality is undergoing the same transformation. Traditional QA acted like SysAdmins — validating software only at the end, creating slow feedback loops and bottlenecks. Shift Left changed the mindset, but collaboration alone isn’t enough for modern scale. Quality Engineering (QE) is the natural next step. QEs are no longer the final gate. They build testing platforms, automation frameworks, integrated quality insights, and performance tools that development teams can use directly. Developers own their quality. QEs provide the scalable systems that make that ownership frictionless. The pattern is clear: Siloed Specialists → Collaboration Model → Platformized Self-Service (SysAdmin) (DevOps) (Platform Engineering) (QA) (Shift Left) (Quality Engineering) As complexity grows, the only sustainable way forward is to empower teams with platforms — not handoffs. Quality Engineering is the Platform Engineering of the testing world. And it’s becoming the new standard. THE SPIRAL EVOLUTION OF ENGINEERING Old Model Collaboration Platform Era ------------------------------------------------------------------------ SysAdmin DevOps Platform Engineering | | | v v v QA Team Shift Left Quality Engineering SAME PATTERN, NEW DOMAIN ------------------------------------------------------------------------ Siloed roles → Shared ownership → Self-service platforms Late feedback → Faster loops → Scalable quality systems Manual handoffs → Automation → Productized tooling

1. 𝗪𝗵𝗲𝗻 𝗜 𝗯𝗲𝗴𝗮𝗻 𝗺𝘆 𝗰𝗮𝗿𝗲𝗲𝗿 𝗶𝗻 𝗤𝘂𝗮𝗹𝗶𝘁𝘆, 𝗜 𝘁𝗵𝗼𝘂𝗴𝗵𝘁 𝗜 𝘄𝗮𝘀 𝗴𝗼𝗶𝗻𝗴 𝘁𝗼 𝗳𝗶𝘅 𝘀𝘆𝘀𝘁𝗲𝗺𝘀. I imagined myself rewriting procedures, redesigning forms, and showing everyone how much better things could be. I was young, full of energy — and honestly, a little naive. Then came my first real challenge. It was in my automotive years, where production lines moved fast, and everyone was under pressure to deliver on time. I had spotted a recurring defect in a particular sub-assembly and was convinced it was due to a gap in process documentation. So, naturally, I created a new SOP, presented it proudly, and waited for things to improve. 𝗧𝗵𝗲𝘆 𝗱𝗶𝗱𝗻’𝘁. When I went to the line to investigate, a technician quietly said : “𝘚𝘪𝘳, 𝘸𝘦’𝘷𝘦 𝘣𝘦𝘦𝘯 𝘥𝘰𝘪𝘯𝘨 𝘪𝘵 𝘵𝘩𝘪𝘴 𝘸𝘢𝘺 𝘧𝘰𝘳 𝘺𝘦𝘢𝘳𝘴. 𝘛𝘩𝘦 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 𝘥𝘰𝘦𝘴𝘯’𝘵 𝘸𝘰𝘳𝘬 𝘪𝘯 𝘳𝘦𝘢𝘭 𝘭𝘪𝘧𝘦.” 𝗧𝗵𝗮𝘁 𝘀𝗲𝗻𝘁𝗲𝗻𝗰𝗲 𝗰𝗵𝗮𝗻𝗴𝗲𝗱 𝗵𝗼𝘄 𝗜 𝘀𝗮𝘄 𝗤𝘂𝗮𝗹𝗶𝘁𝘆 𝗳𝗼𝗿𝗲𝘃𝗲𝗿. I realized that no matter how strong your systems are, they live or die through the people who run them. And those people carry habits, fears, pressures, and practical knowledge that no flowchart can capture. In later years — especially in the medical device world — this truth became even sharper. I remember a project where we were remediating part of our QMS to align with ISO 13485. We had planned to roll out a major procedural update across sites. The system looked perfect on paper. But during a pilot phase, a manufacturing supervisor pointed out a subtle workflow conflict that could have delayed product release by 48 hours every week. 𝗜𝗳 𝗜 𝗵𝗮𝗱𝗻’𝘁 𝘁𝗮𝗸𝗲𝗻 𝘁𝗵𝗲 𝘁𝗶𝗺𝗲 𝘁𝗼 𝗹𝗶𝘀𝘁𝗲𝗻, 𝘄𝗲 𝘄𝗼𝘂𝗹𝗱 𝗵𝗮𝘃𝗲 𝗲𝗻𝗱𝗲𝗱 𝘂𝗽 𝘄𝗶𝘁𝗵 𝗮 𝗰𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝘁 𝘀𝘆𝘀𝘁𝗲𝗺 𝘁𝗵𝗮𝘁 𝗱𝗶𝗱𝗻’𝘁 𝘄𝗼𝗿𝗸. That’s when I began to practice what I now call “𝗾𝘂𝗶𝗲𝘁 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗹𝗲𝗮𝗱𝗲𝗿𝘀𝗵𝗶𝗽.” Before changing anything, I listen. I walk the floor. I talk to operators, engineers, and even the most skeptical managers. I try to understand what truly drives their actions — not just their compliance behavior, but their human logic. • Quality starts not with process maps, but with empathy maps. • Because when people feel understood, they become allies. • And once they’re allies, systems start to change themselves. You’ll learn that every “resistant” person is actually protecting something — sometimes pride, sometimes workload, sometimes just survival. And when you understand that, you’ll stop pushing systems onto people — and start co-creating systems with them. That’s when real Quality begins. 👉 𝗪𝗵𝗮𝘁’𝘀 𝗼𝗻𝗲 𝗹𝗲𝘀𝘀𝗼𝗻 𝘆𝗼𝘂 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝗲𝗮𝗿𝗹𝘆 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗰𝗮𝗿𝗲𝗲𝗿 𝗮𝗯𝗼𝘂𝘁 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗽𝗲𝗼𝗽𝗹𝗲 𝗯𝗲𝗳𝗼𝗿𝗲 𝗰𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝘀𝘆𝘀𝘁𝗲𝗺𝘀? #QualityCulture #Leadership #ContinuousImprovement #QualityManagement #ChangeLeadership #PeopleFirst

I recently spoke with a quality leader standing up a new QMS who asked a familiar question: 🤔 𝗦𝗵𝗼𝘂𝗹𝗱 𝘄𝗲 𝗳𝘂𝗹𝗹𝘆 𝗱𝗲𝗳𝗶𝗻𝗲 𝗼𝘂𝗿 𝗤𝗠𝗦 𝗯𝗲𝗳𝗼𝗿𝗲 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗻𝗴 𝗮 𝘃𝗲𝗻𝗱𝗼𝗿? Traditionally, teams are taught that process definition must come before tool selection. The perspective that quality means producing and storing documents after development limits what teams believe is possible and leads them to debate an end state before anyone touches real workflows. Here’s what I shared with her. Teams that enforce a QMS connected directly to the tools they already live in, like Jira and GitHub, can align, implement, and document in parallel. And they tend to align faster. Why? ⚙️ 𝗣𝗿𝗼𝗴𝗿𝗲𝘀𝘀 𝗶𝘀 𝗱𝗿𝗶𝘃𝗲𝗻 𝗯𝘆 𝘀𝘆𝘀𝘁𝗲𝗺𝘀, 𝗻𝗼𝘁 𝗺𝗲𝗲𝘁𝗶𝗻𝗴𝘀. Perfect alignment rarely exists on day one. A compliant starting point creates momentum by letting teams learn, adjust, and improve through real work rather than waiting for consensus. 🤝 𝗔𝗹𝗶𝗴𝗻𝗺𝗲𝗻𝘁 𝗰𝗹𝗮𝗿𝗶𝗳𝗶𝗲𝘀 𝗶𝗻 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗲, 𝗻𝗼𝘁 𝗽𝗹𝗮𝗻𝗻𝗶𝗻𝗴. “Future state” debates extend into workshops because trade-offs remain hypothetical. Working inside a real, compliant system exposes constraints immediately and forces alignment around what actually works. ✅ 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗺𝗮𝗱𝗲 𝗮𝘁 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝘁𝗶𝗺𝗲, 𝗻𝗼𝘁 𝗿𝗲𝘃𝗶𝗲𝘄 𝘁𝗶𝗺𝗲. When controls are embedded directly in Jira and GitHub, engineering and quality teams resolve issues as work happens instead of negotiating them after the fact in slides and approvals. Traditional QMS implementations ask teams to align first and adopt new systems later. We allow teams to develop processes and adopt tools together. By enforcing quality controls directly inside permanent tools like Jira and GitHub, teams can start compliant and improve continuously instead of getting stuck in alignment cycles. See what’s possible in a real system first, then shape your workflows on top of it. How are you handling this in your organization? Do you align first, build first, or learn by doing?