What does the future of engineering look like from the perspective of someone just entering the field? In this episode, Chad Jackson sits down with Ryan Botzbach — a final-year mechanical engineering student at UC Riverside with a computer science minor, a passion for aerospace and defense, and the kind of hands-on instincts that most companies spend years trying to cultivate.

Ryan brings a perspective that engineering leaders can't afford to ignore. He's the engineer rebuilding a Volvo five-cylinder engine in his garage, converting 1970s aerospace drawings into 3D models for a machine shop, and running a thousand-person car club — all while finishing his degree. He's not waiting to "get experience." He's already in it.

In this conversation, Ryan and Chad explore:

• Why today's young engineers will tolerate outdated tools — for now — and what happens when they gain enough experience to push back
• The change agent mindset — how to stay alert to improvement opportunities instead of just clocking in and clocking out
• Model-Based Definition in practice — what it looks like when a small machine shop bridges the gap from 2D legacy drawings to CNC-ready 3D models
• Fusion 360 vs. SolidWorks — an unpopular opinion from someone who uses both daily
• AI as an engineering accelerator — from troubleshooting obscure part numbers to standing up a Kubernetes cluster on a Raspberry Pi
• The affordability problem in defense — and why companies like Andúril represent a fundamentally different approach to how the industry operates

Whether you're trying to recruit the next generation of engineers, modernize your workflows, or simply understand how the field is evolving from the ground up — this episode offers a candid, unfiltered view from someone standing right at the threshold.

Ryan Botzbach is a graduating mechanical engineering student at UC Riverside and part-time team member at DNL Components, a supplier to aerospace, defense, and racing industries.

What does it look like to build a software engineering function from scratch inside an aerospace and defense organization that has never had one? Marilyn Arceo has done it—more than once, across industries—and her answer might surprise you: the hardest part isn't the technology. It's the translation.

In this episode of Change by Design, Marilyn, an enterprise architect in aerospace and defense, talks about what it takes to stand up software engineering competencies in complex, regulated industries where those capabilities don't exist yet. She draws on a career that spans consumer packaged goods, fashion, healthcare, commercial real estate, e-commerce, and logistics to explain why the most valuable skill a change agent can develop isn't technical at all—it's the ability to sit between the deeply technical and the deeply human sides of an organization and make each one intelligible to the other.

The conversation covers the practical mechanics of building teams: when to hire fresh graduates versus experienced engineers, how to convert mechanical and electrical engineers who already have software foundations, and why a hybrid agile-waterfall approach works better than imposing any single methodology on a team that's never used one. But the real value is in the strategic thinking underneath those decisions—how to evaluate whether an initiative is worth pursuing, when to push for innovation versus when to accept that the math doesn't work, and why iterative rollouts beat wholesale transformation every time.

Marilyn also takes a grounded, cautious stance on AI-assisted development. She's seen the productivity gains, but she's equally clear about the risks: hallucinations, security exposure, and the "garbage in, garbage out" problem that surfaces when organizations skip the discipline of code review and governance. Her position is that AI should free engineers to focus on architecture and design, not replace the judgment that keeps systems safe.

For engineering executives building new capabilities and change agents navigating cross-functional integration in regulated environments, this conversation delivers field-tested guidance without the hype.

Topics covered:

• Standing up software engineering functions where none existed before
• The "business translator" gap: why organizations cluster at technical and people extremes
• Staffing strategies that blend fresh talent with experienced engineers and cross-trained domain experts
• Hybrid agile-waterfall adoption: making structural processes feel less overwhelming
• Risk vs. value: how to evaluate whether an initiative is worth pursuing before committing
• AI code assistance done right: governance, code review, and data security
• Breaking silos in hardware-software integration through cross-functional working sessions
• Cybersecurity as a collaborative partner, not a gate
• Green flags and red flags for change agents evaluating organizational readiness
• A mentor-forward philosophy: leaving every team and every engineer better than you found them

What does it take to transform the way a major automaker designs and validates its products — and who really drives that change?

In this episode, Chad Jackson sits down with Vijay Sanikal, a seasoned automotive engineer and proud self-described change agent who has worked across OEMs including GM and Stellantis, tier one and two suppliers, and Computer Aided Engineering (CAE) software providers. Vijay brings a rare 360-degree view of the product development ecosystem, and he doesn't hold back on what it actually takes to move organizations forward.

Vijay and Chad dig into the evolution of simulation-driven design — from the days when CAE was treated as offshore "extra work," to today's world where AI-assisted tools can optimize a design in real time without a human ever pushing a button. Vijay explains how the value proposition for simulation has fundamentally shifted, and why today's engineering leaders are far more prepared to invest in digital twin technologies than they were even a decade ago.

But this episode is just as much about people as it is about technology. Vijay shares his framework for what makes a change agent effective — from winning stakeholders without authority, to building cross-functional innovation forums, to knowing when to call an initiative a silo and when to reframe it as a stepping stone.

In this episode, you'll hear:

• Why innovation needs to come from the ground up — and how leaders can create the conditions for it
• How the roles of designer, simulation engineer, and requirements team must work in concert for change to stick
• The two ways AI is currently being integrated into CAE workflows — and what's coming next
• Why compute cost is an underappreciated risk in the shift to simulation-heavy development
• What green flags (and red flags) tell a change agent whether an initiative is worth championing
• Vijay's career advice for the next generation of engineers in a world where specialization is everything

Whether you're leading a digital transformation initiative or trying to build a case for simulation investment, this conversation offers hard-won perspective from someone who has lived it across multiple organizations and continents.

Engineering transformation programs fail all the time—and Tracy Rupp has a clear diagnosis: we keep treating them as technology problems when they're really people problems.

In this episode, Chad Jackson sits down with Tracy Rupp, Program Chief Engineer and Systems Engineer at L3Harris Technologies, to talk about what it actually means to be a change agent in a complex engineering enterprise. Tracy brings a rare combination of technical depth and leadership instinct, and she's unambiguous about where most initiatives go wrong: the moment a team loses sight of the people they're asking to change.

Tracy offers a distinction that every engineering leader should hear—the difference between problem-solving and change agency. Solving a problem gets you to the finish line once. Change agency gets everyone else there too, and makes the path easier for everyone who comes after. She illustrates the difference with a story from early in her career and traces how that mindset shaped everything she's done since.

The conversation covers MBSE with unusual clarity and practicality. Tracy advocates for it—but not as a mandate. Her argument is that systems engineers have an obligation to translate, not dictate: converting model insights into language that mechanical engineers, quality engineers, and program managers can actually act on. It's a refreshing take in a field that often treats tool adoption as the goal rather than the means.

You'll also hear her perspective on building change coalitions—what she calls the "village" of visionaries, builders, and early adopters that every transformation needs—and her unconventional approach to design reviews that closes 80% of action items before anyone leaves the room.

For engineering executives navigating digital transformation and the change agents fighting for it from inside their organizations, this episode is dense with hard-won, practical wisdom.

Topics covered:

• What separates a change agent from a good problem-solver
• Why people resistance—not technology—is the defining challenge of engineering transformation
• MBSE done right: when to use it, when not to, and how to translate it across disciplines
• "Zero-day action items": how to close 80% of review actions during the meeting itself
• Building a talent development program from the ground up during COVID-19
• AI as a domain translator between engineering disciplines
• How to push back on leadership when an initiative is set up to fail
• The "village" model for change coalitions and why no single change agent can carry a transformation alone

What does a youth minister turned Boeing AI engineer have to teach engineering executives and change agents? As it turns out, quite a lot.

Dr. Ryder Dale Walton has spent the last decade driving two of the most consequential transformations in aerospace engineering: the shift from waterfall to Agile, and the integration of AI and large language models into engineering workflows. In this conversation with Chad Jackson, he offers a perspective on change leadership that you won't hear from most technical practitioners — one that's as grounded in human psychology as it is in engineering discipline.

Ryder makes a case that the soft skills change agents most need are the ones they're least likely to have been trained on. When subject matter experts resist change, data and dashboards won't move them. What moves them is understanding what they stand to gain — and being patient enough to show them. His background in ministry and the arts, he argues, gave him the "ambidextrous brain" that makes the difference between a change initiative that gets funded and one that actually gets adopted.

The conversation also gets into the real-world mechanics of change execution — why deploying fast beats deploying perfectly, how Agile adoption actually works through mentoring rather than training, and how to navigate the hardware-software integration challenge as product complexity explodes across aerospace, automotive, and defense. And on the topic of AI, Ryder offers a quietly unsettling observation: when machines automate the creative work, they may be taking away the very activities that help us recharge as human beings.

Perhaps most relevant to change leaders: Ryder sounds a clear warning about burnout. When people are already stretched thin, the emotional bandwidth required to genuinely engage with and bring people along through change simply isn't there — and that's when initiatives quietly die.

When engineering transformation initiatives stall, it's rarely the technology that's to blame. In this week's roundup, Chad and Josh dig into why people resistance, not process gaps or technology issues, consistently ranks as the top challenge in MBD and MBSE initiatives, and why that resistance runs deeper than most change leaders expect. We're talking about identity, competency, and the very real fear of being left behind.

Chad shares takeaways from a live roundtable with three MBSE practitioners who landed on a surprising point of agreement: MBSE isn't always the right answer, and knowing when to reach for it — versus document-based systems engineering — requires a level of organizational judgment most companies haven't developed yet. Add AI to that mix, and both approaches start to look very different.

Speaking of AI, new research from Lifecycle Insights reveals that 76% of engineers at hard goods manufacturers are using AI for software development daily, and 52% say half the code they generate comes from AI tools. But here's the number that should give every engineering executive pause: 42% are not thoroughly reviewing that AI-generated code before committing it. Chad and Josh unpack what's actually driving that behavior — and it's not laziness.

The episode closes with a preview of an upcoming Lifecycle Insights publication on the political realities of MBD and MBE initiatives — specifically, what happens when engineering wants the model-based enterprise but procurement, manufacturing, and other functional departments don't report to you.

If you're leading or supporting an engineering transformation, this one is required listening.

Marshall Hulbert has done what most engineers only talk about — he's actually replaced the drawing. A veteran change agent now leading Model-Based Definition (MBD) and Model-Based Enterprise (MBE) adoption at Oshkosh Defense, Marshall joins host Chad Jackson to share what it really takes to drive a transformation that reaches far beyond the engineering department. The first half of the conversation covers the change agent role itself: the skills that matter, how to read organizational signals that predict success or failure, and the soft-skills battles you'll fight with departments that aren't yours to manage.

The second half goes deep on MBD and MBE — what engineering, manufacturing, quality, and procurement actually gain when the drawing disappears, why supplier adoption is the hardest bridge to cross, and a forward-looking idea Marshall raises that's rarely discussed: feeding manufacturing programs, inspection results, and downstream data back into the model so it becomes a living, circular source of truth rather than just an output.

Key Takeaways:

• Two types of change agents: those who assess and push a new initiative up the chain, and those who deploy it once the decision is made — Marshall prefers the first.
• Broad cross-functional knowledge is essential: before you can sell the change, you have to understand what every department actually does with a drawing today.
• Upper management buy-in is the make-or-break factor: wavering at the top creates stalls at every level below.
• MBD is unique because it removes the drawing entirely — unlike every prior shift in engineering (hand drafting to CAD to 3D), downstream departments can no longer rely on a familiar deliverable.
• The circular model: manufacturing programs, feed speeds, and inspection data can eventually feed back into the MBD, making it a living source of truth — not just an output.
• Supplier adoption is the hardest bridge to cross: quoting departments lack the software and training to interpret a model file, and until they can, the full value of MBD stays locked up.
• ROI doesn't always get calculated — in the defense sector especially, companies are adopting MBD because the government is heading there, not because someone ran the numbers.
• Start small and start now: run R&D or non-time-sensitive parts through the system first and get people used to it before production orders are on the line.

Research says engineering leaders expect a lot from Model-Based Systems Engineering (MBSE) — improved reliability, better traceability, fewer integration failures. So why are those benefits so hard to actually realize? In a recent Lifecycle Insights study, fewer than 30% of teams reported achieving the outcomes they set out to get from MBSE. That's the gap this episode confronts head-on.

Host Chad Jackson brings together three veteran systems engineers for a live roundtable that goes beyond theory: Anand Rangaramu, Guy Zur, and Branden Ramsey. Together, they tackle the hard questions practitioners rarely say out loud in conference presentations.

In this episode:

• Why building a business case for MBSE is harder than it looks — and the organizational dynamics that make or break adoption
• How to scope your modeling effort without turning it into a bureaucratic burden
• The "all or nothing" trap that kills MBSE initiatives before they deliver value
• Why culture — especially psychological safety and tolerance for failure — may matter more than tooling
• What AI actually changes (and doesn't) for MBSE: from auto-populating requirements to "vibe coding" system models
• The one thing each panelist wishes engineering leaders truly understood about MBSE

Whether you're trying to justify your first MBSE initiative or troubleshoot a stalled one, this conversation delivers the honest, experience-driven perspective you need to hear.