Aircraft Systems Engineering Beyond the Review: Human Chemistry, and the Quiet Craft of Good Engineering

I always appreciate listening to leaders discuss moments where they learned by cutting their teeth.

Not because of the dramatics, although one satellite program nearly came undone from late-discovered test failures in Carol Erikson's case. I listened because of how plainly she put it: “We hadn’t done a thorough design review.” That simple. That avoidable. That real.

Carol spent nearly four decades at Northrop Grumman. Long enough to remember the days when reviews meant hand-delivered documents and design sign-offs traveled with couriers. Long enough to see aerospace evolve from analog boards and thermal vac chambers into full-spectrum digital environments. When she talks about system integrity, she isn’t offering theory. She’s remembering the tension in a clean room as a sensor cracks under test, because someone didn’t spot a margin issue six months earlier.

You carry those moments with you. They shape the instincts you don’t always articulate but that guide every engineering decision afterward.

Simulate Early, Talk Often

When Carol talked about simulation, it was with an urgency I’ve heard echoed across hardware spaces lately. The tools are better now. You can model thermal performance before the prototype, simulate antenna behavior before a PCB is even laid out. But she was quick to point out that tools don’t create speed. Culture does.

Her teams used simulation to bring iteration forward. If you could run a test in software and understand the impact of a design tweak the same day you had the idea, you could skip weeks of trial-and-error. But that only works if people are in the habit of sharing ideas, reviewing progress often, and asking hard questions early.

She mentioned Ansys as a toolset that helped make that possible. But it wasn’t the software itself she was praising. It was the rhythm it supported. Tight feedback loops. Clarity of cause and effect. A place where thinking and making were allowed to mix.

Assumptions Make EMI Your Biggest Problem 

For aerospace electronics, simulation is not just a step in the flow. It is the structure of responsible design.

What simulation reveals—especially when paired with electromagnetic solvers—is the deep dependency of signal fidelity on physical path. A signal that changes layers must bring its return current with it. If the adjacent reference plane changes from ground to power, and the layout fails to offer a continuous path for the return, the current is forced to find an alternate route—usually through a decoupling capacitor or displacement path. High-frequency return currents behave in a way to be adjacent to the signal conductor. Any discontinuity in the reference plane or abrupt layer change disturbs this current, resulting in high-frequency noise, resonance, or radiated emissions. These aren’t academic phenomena—they’re mission-ending faults in orbit.

This detour creates a larger loop area. Larger loops emit more energy. What might seem like a neat layout can become a radiating structure, introducing emissions that are difficult to predict without modeling. These emissions can cause sensitive analog circuits to misbehave or interfere with critical sensor readings.

The consequences of these oversights grow in aerospace environments, where multiple systems share tight enclosures and radiated emissions don’t just affect compliance—they affect mission performance. Engineers must treat the layer stack not as an afterthought but as a primary tool for managing current flow and field containment.

Simulation-driven design helps uncover issues before hardware exists. EMI issues are often areas where engineers can make those critical misassumptions - that ‘good enough’ is often not the case. Even subtle layer stack variations introduce impedance mismatches and slot-antenna effects. Especially in high-density boards, electromagnetic simulation becomes a tool for leadership-level risk mitigation.

Aerospace hardware lives on the margin of failure. The more simulation reflects physics and system integration, the more it becomes a primary design deliverable—not just a sign-off step.

The Chemistry of a Good Team

In our conversation, Carol and I kept circling a word that doesn’t get enough credit in engineering spaces: chemistry.

Not the periodic table kind. The human kind. The quiet signals exchanged between disciplines. The moments when a thermal engineer and a systems integrator finally sit down, spot a mismatch, and fix it before it hits the floor. Carol spoke often of these kinds of moments. She described reviews not as gatekeeping exercises, but as places where unexpected conversations happened and the right eyes caught the right problems at the right time.

That kind of interpersonal rhythm doesn’t come from process charts. It comes from a culture built on clarity, regular contact, and a shared understanding of what good looks like. When she described daily and weekly standups, or the practice of inviting anyone to speak up at any time, it wasn’t because she believed in a flat org chart. It was because she had seen what happens when people feel safe enough to share a doubt before it becomes a defect.

Leadership in a Technical Tongue

Carol’s leadership style wasn’t about managing from a spreadsheet. She had a deep hand in the details, and more importantly, she translated between them. She understood enough about systems, software, and procurement to speak with credibility across functions. That interpretive ability is often the dividing line between projects that inch forward and programs that accelerate.

She’s passionate about digital transformation, but her view of it is grounded in people. It’s not about shiny tools or pushing everyone into a new platform. It’s about showing a team where their contributions fit into a wider frame. Procurement, test, design, manufacturing—all moving parts with different incentives, pressures, and language. She understood that these parts don’t naturally align. You need leaders who pull people back to center, again and again.

There’s a deep satisfaction in that kind of leadership. You aren’t building the product directly anymore. You’re building the environment in which good engineering can actually happen.

The Satisfaction of Deep Engineering Leadership

There’s a unique kind of joy in leading technical work well. You don’t just get the thrill of solving a problem. You get the quiet satisfaction of helping other people solve it better than you could have on your own. Carol radiates that kind of leadership. She isn’t pushing products from a distance. She’s shaping teams to work with confidence, care, and shared understanding.

It takes patience to lead like that. It also takes love. You have to love the tools, but also the tradeoffs. You have to love the product, but also the weird interpersonal dance of reviews, standups, emails, late-night bug scrubs. You have to love clarity. Because in the fog of deadlines and versioning and procurement debates, clarity is what protects the work.

Carol never said she was trying to be the smartest person in the room. She talked instead about building rooms where smart people could thrive.

Engineering Is Interpretation

What makes Carol’s career interesting isn’t just that she kept products working. It’s that she did so while making the organization work, too.

Because the reality is: no engineer works alone. Every discipline is slightly mistranslated from the next. Software operates in timelines. Mechanical in volumes. Thermal in gradients. Systems in structure. And unless someone does the work of translation—of interpretation—the system doesn’t hold.

Carol made that her job. Not through inspirational speeches, but through rigor. Through review. Through structure. Through making sure the comms engineer heard what the thermal lead was worried about. Through asking why no one from procurement had looked at the sourcing timeline before committing to a prototype date.

She didn’t abstract this into culture language. She treated it like engineering. You see where the failure modes are. You address them with process, tools, and feedback.

And maybe that’s what leadership in engineering is. Not storytelling. Not charisma. Just clarity under constraint.

What a System Really Means

A lot of people hear the word "system" and think about formal charts, dependency trees, maybe a SysML diagram if they're in the mood. But when Carol used the word, she meant something much more grounded.

A system is the chain of emails that turn into a BOM update. It’s the undocumented knowledge a test technician carries about a connector that’s prone to thermal drift. It’s the five-minute conversation that stops a six-week delay. A system is the sum of technical parts and human habits. It includes your test benches and your hallway chats, your Jira tickets and your unwritten rules about who reviews what.

For the everyday engineer, a system is everything that shapes how work gets done. It’s the context you navigate, the handoffs you manage, and the gaps you quietly fill in without being asked.

When Carol talked about improving systems, she meant improving all of that. Tightening the feedback loops. Clarifying the roles. Creating fewer surprises and more shared understanding. She was not simplifying the work. She was strengthening the connections that let complexity hold together.

To design well, you need to understand the system you're inside of. And to lead well, you need to widen that understanding for others.

The Engineer in the Story

Carol’s father worked on the Lunar Lander. She grew up hearing about slide rules and drafting tables. Now she builds across toolchains that span simulation suites, integrated test infrastructure, and real-time review platforms. Yet when she reflects on what matters most, it’s always about people. About conversations. About engineers from different disciplines talking early and clearly enough to avoid bad surprises later.

Her favorite memories come not from technical perfection but from tough moments that were solved together. Teams that recovered from failure by showing up, sharing knowledge, and keeping the mission in sight. That’s what good engineering leadership is. Not avoiding the hard parts. Leading through them.

She’s launched a consulting practice now, bringing her approach to companies that need better alignment between ambition and execution. When she shared a draft of her brochure with a branding friend, he said it sounded exciting but he didn’t understand a word of it. She laughed. “Then I guess I have some rewriting to do.”

Even now, she’s still working the craft of interpretation. That is how you know she’s still an engineer.

Closing Reflections

Carol taught me a lot in a short conversation. Not in the form of grand takeaways, but in the feel of how she described the work. Calm. Clear. Purposeful. The kind of engineering that runs deep enough to be quiet.

Here’s what stayed with me:

• Engineering lives in the connections, not just the components.
• Good reviews create more value than good tools.
• Communication is not a soft skill. It’s a structural element.
• Leadership, at its best, builds environments where excellence is the default.

And maybe most of all: systems don’t exist without people. If you want the machine to work, you better understand how the humans in the loop think, talk, and collaborate.

Carol does. And it shows in everything she builds.

If you’re shaping a program and want to strengthen your foundation, Carol is someone to call. And if you’re drawn to stories like this, to the culture and craft of great engineering, keep following Hardware Rich Development. There’s more coming.