Carol Erikson on Systems Thinking, Technical Leadership, and Building Teams That Actually Work

Carol Erikson spent nearly four decades inside one of the most complex engineering machines in the world: Northrop Grumman. She’s led engineering teams on restricted satellite systems, managed digital transformation initiatives across space systems, and helped steer programs as critical as our nation’s next-generation ICBM platform. But if you ask her what really makes or breaks a program, she won’t talk first about budgets, specs, or timelines.

She’ll talk about people. And systems. And the communication in between.

“I think the biggest thing that comes to mind,” she told me, “is systems thinking—and communication. That ability to bridge across disciplines and really understand how the pieces fit together. You can’t teach that easily. But it’s essential.”

Our conversation covered a lot of ground, from early failures and simulation tools to what it means to design a team like you’d design a payload. But at the core of it was a simple idea: building hardware is never just about the hardware.

From Flight Software to the Front Lines of Digital Transformation

Carol started at Northrop Grumman straight out of college, diving into flight software for satellite systems. Her technical grounding was sharp, and early on she learned just how closely software and hardware were intertwined in space environments.

“You had to understand attitude control, thermal control, communication systems—the whole thing. It forced me to think like a systems engineer, even when I was just writing code.”

That mindset carried her into mission operations, then into systems engineering, and eventually into program and executive leadership roles. At each step, her focus widened, but she kept circling the same set of challenges: how do you coordinate technical disciplines? How do you avoid late-stage surprises? And how do you keep teams aligned when the stakes are high and the systems are sprawling?

Her answer, increasingly, came down to structure and communication.

“As VP of Engineering, one of my biggest focuses was breaking down silos. And when I moved into digital transformation, it was about enabling communication not just across teams, but across functions—engineering, procurement, manufacturing, program management. All of it.”

When the Reviews Are Too Late

Carol has a calm presence, but her stories carry weight. One that stood out came from a major national weather satellite program, where she served as payload manager. The job required managing a handful of sensor builds—each from a different contractor, each under tight timelines.

And then the tests started failing.

“We had sensors from five different well established aerospace contractors. One by one, each sensor started to fail during electrical, thermal or vibration testing. We were doing ‘test like you fly,’ simulating launch and space conditions. And these things just weren’t holding up.”

The root cause wasn’t manufacturing. It was process.

“We had inherited the sensor designs from our customer, and they hadn’t done proper design reviews because they had assumed the sensors had flown in space before and were “flight proven”. And we never went back to verify that. So we were finding problems late in test that we should’ve caught in design.”

The fix? Reinforcing the review process—and making sure every function had a seat at the table.

“Each major review—preliminary design, critical design, test readiness—had to be interdisciplinary. You needed the electrical engineer hearing from the thermal specialist. You needed the payload integration lead talking to software and power teams. Those reviews are where the conversations happen. That’s when the real integration work begins.”

Agility with a Lowercase A

Carol is a fan of Agile—but with caveats.

“At Northrop, we used to talk about “Big A” and “little a”. “Big A” meant following every Agile rule by the book. But in hardware, that can come at the expense of requirements definition and rigorous testing. “Little a” meant taking the principles—iteration, fast feedback, responsiveness—and applying them smartly.”

She’s not dogmatic. She’s practical.

“You have to adapt Agile practices to your product, your team, and your industry. I’ve seen Agile work beautifully when there’s a strong leader who understands both Agile and traditional systems engineering. And I’ve seen it fail when it becomes checkbox-driven.”

One enabler she points to again and again is simulation.

“If you can simulate performance early, you can iterate early. That’s where you get speed. You don’t have to wait for a prototype to shake apart on a test bench. You model, test, and adjust while it’s still in software.”

Her teams leaned on tools like the Ansys suite of simulation tools, which offered robust libraries for RF, thermal, and system-level analysis. But even with the best tools, success depended on structure and culture.

“You can’t just throw a tool at the problem. You need trained engineers, a cadence for iteration, and communication that flows in every direction.”

What Systems Thinking Looks Like on the Ground

Carol doesn’t romanticize systems thinking. She’s clear that it’s hard to teach and harder to operationalize. But she believes it’s vital.

“I think a lot of engineers come out of school with a strong foundation in their discipline. But cross-discipline communication? Working through systems-level tradeoffs? That takes experience.”

For her, systems thinking means seeing past your own domain and understanding how design decisions ripple across the whole program.

“It’s one thing to optimize a board layout. It’s another to realize how that layout affects thermal dissipation, cabling, integration, and test access. That’s the level we need more engineers thinking at.”

She supports increasing cross-discipline opportunities in college, but sees a gap even today.

“It’s still too often the exception. Unless students get into a special robotics program or capstone design challenge, they may never encounter the full system view.”

She also believes in supporting engineers as they grow into this mindset.

“I’ve had incredibly capable engineers join my teams without systems experience. But give them the exposure, the mentorship, and the right structure—and they grow fast.”

The Role of Culture in Engineering Success

Some of the most thoughtful parts of our conversation were about team dynamics. How do you measure a successful team? How do you build one?

“There aren’t always great metrics,” Carol said. “We used engagement surveys to get some pulse on effectiveness. But honestly, most of it is observational. You need to be close enough to the team to sense when communication is flowing and when it’s not.”

She emphasized regular contact points. Not surveillance, but rhythm.

“We’d have daily or weekly standups depending on task complexity. But we also had an open-door culture. If something came up, we’d huddle—virtually or in person. Everyone knew they could ask for that at any time.”

She also pointed out how success often looks like subtle alignment. People finishing each other’s thoughts in meetings. Engineers solving problems across functions without being asked. Design and test teams working from a shared mental model.

“You can’t force that. But you can enable it.”

A Reflection on Change—and Continuity

Carol’s career has spanned generations of technology. She remembers watching her father work as an engineer on the Apollo program, drafting by hand, calculating by slide rule.

“It’s amazing what they achieved with so little tooling. And now, with simulation, AI, integrated toolchains—we’re capable of so much more. But I think the core hasn’t changed.”

That core, for her, is thoughtful engineering. Careful design. Teamwork that works. A sense of responsibility to the mission.

Today she’s stepping into a new role, launching her own engineering consultancy. Even in writing the brochure, she found herself relearning the lesson of translation.

“I sent it to a branding friend. He said it sounded exciting, but he didn’t understand any of it. It reminded me—technical communication always needs context. You have to meet people where they are, even when the work is complex.”

Takeaways from a Career in the Arena

In listening to Carol talk about her work, I kept coming back to one idea: this is someone who has engineered both hardware and culture. She’s built products, but also built the environments where great products can take shape.

A few takeaways:

• Design Reviews Matter: Not for compliance, but for conversation. Reviews are where cross-functional teams align and where small issues get caught before they grow.
• Simulation is a Force Multiplier: Investing early in modeling tools and expertise creates time, clarity, and confidence. It turns speculation into action.
• Agile is a Mindset, Not a Rulebook: Successful teams iterate, adapt, and communicate. Whether it’s Agile or not matters less than whether it’s working.
• Systems Thinking is a Skill and a Culture: Engineers grow into it with the right structure and exposure. Leaders can accelerate that growth.
• Communication is the Quiet Enabler: From payload design to digital transformation, the projects that succeed are the ones where people talk—and listen—across boundaries.

Carol Erikson has led teams through some of the most demanding engineering challenges of our era. But what stands out isn’t just her resume—it’s her clarity. Her patience. Her refusal to separate technical success from human success.

That’s the heart of Hardware Rich Development. And that’s the kind of leadership this field needs more of.