There's No Such Thing as "Soft Skills" in Engineering

Engineering outcomes don’t happen in isolation—and understanding how engineering systems and organizational systems shape those outcomes is critical for effective engineering leadership.

In this episode of ENGINEERING CH∆NGE®, I challenge one of the most persistent, misleading and, quite frankly, aggravating phrases in engineering: “soft skills.”

There is nothing soft about teamwork, communication, and other people-centered professional competencies that determine whether engineering work succeeds.

Using a systems lens, this episode examines how engineering outcomes are produced through interactions among people, across roles, and between organizations and the communities they serve. It also explores how narrow definitions of merit obscure the very contributions that hold teams, projects, and systems together. (More to come on this in Episode 32).

Through real-world examples and personal reflection, I make the case for eliminating the term “soft skills” altogether and replacing it with a more accurate understanding of what engineering work actually requires, and thus, what our organizations should recognize and value.

In this episode:

•  Why the term “soft skills” fails to describe critical engineering capabilities 
•  How people, relationships, and context shape engineering outcomes 
•  What traditional definitions of merit overlook 
•  Why expanding what we value strengthens engineering systems 

If this conversation resonates with you, follow ENGINEERING CH∆NGE® and leave a five-star review to help more engineers and leaders join the conversation.

Visit the ENGINEERING CH∆NGE® podcast website to learn more and to request a free copy of my new brief, Engineering for Society.

Transcript

0:01

Welcome to ENGINEERING CH∆NGE®, the podcast designed to help REDEFINE engineering by RE-imaging who we see as engineers and what we see as engineering, DE-siloing our approach to academic programs, research and problem solving, and FINE-tuning organizational conditions so people with different backgrounds and perspectives can contribute fully to outcomes that serve all of society. Each episode offers actionable takeaways you can use wherever you are in the process of ENGINEERING CH∆NGE®. I'm your host, Dr. Yvette E. Pearson. Hello, Agents of Change. Welcome to ENGINEERING CH∆NGE®. If you've listened to this podcast before, you may remember that I used to begin each episode by introducing a guest, someone doing important work at the intersection of engineering, leadership, and impact. This season looks a little different. And while the format has shifted primarily to solo episodes, the purpose hasn't changed. We're still examining how engineering outcomes are actually produced - by people through systems under real world conditions. Today's episode is about something that often gets talked around in engineering spaces, but rarely named clearly. Interested in learning more? Grab a latte and listen as we dive into Episode 31 of ENGINEERING CH∆NGE®. Let's start with a phrase I want to retire. Soft skills. Oh, it hurts me even to say it. In fact, I've been joking that I need to create something like a swear jar. Every time someone uses the phrase soft skills, they have to donate to the engineering student scholarship I established. Now, I say that partly in jest, but only partly. Because there is nothing soft about the skills that determine whether engineering work actually succeeds. We often talk about engineering outcomes as if they're the product of technical expertise alone. Individual brilliance, calculations, models, designs, and those things matter a lot. But that framing misses something fundamental. Engineering outcomes don't happen in isolation. They're produced through interactions among people across roles and between organizations and the communities affected by their work. People are not incidental to this process. They are integral to how engineering work actually gets done. Let me give you a concrete example from a September 2025 article published by the NERRA. And I'm going to try to pronounce this name. I'm not going to even edit it out if I screw it up, but let's go for it. It's the National Estuary Research Reserve Association. I think I did it. So the NERRA. In Eastern North Carolina, communities along the Scubernang River were dealing with chronic flooding issues; homes, farms, roads, repeatedly underwater. And they brought in engineers to do what we often do first. We run models, map risks, assess future storm impacts. Instead of stopping there, the project team took another step. They intentionally brought in local residents, farmers, and community leaders into the process. And here's the key move. They didn't show up to inform the community about were planning to do. They didn't show up saying,"We are the engineers who have come to solve your problems." No. They showed up to listen. People pointed out where flooding actually happens, how water actually moves across the landscape, and which problems mattered most on the ground. That local knowledge was used not only to refine the technical analyses the engineers had done, but also to define and scope the problems to be solved. The final recommendations ended up being much stronger and more practical because of the community's involvement. Culvert upgrades, debris removal, water-farming practices, real-time sensors, all of these solutions that made sense technically and locally. In this case, the stakeholders didn't just validate the engineering work. They were part of it and they made it better. That's what it looks like when engineers treat people not as an afterthought, but as essential contributors throughout the engineering design process. This is where the REDEFINE lens becomes useful. RE-image asks us to reconsider who we see as part of the engineering system and what kinds of knowledge we value. It also challenges us to examine what we see as the products of engineering work, recognizing their socio-technical rather than just technical nature. Building from there, DE-silo asks what happens when expertise is allowed to move across roles and disciplines and lived experience instead of being locked behind formal titles or credentials. In this case, the engineering didn't get weaker by expanding who was involved. It got better because the system could finally see itself more clearly. But let's be honest. This requires skills and capabilities that many engineers find challenging. Last year, I surveyed CEOs of small engineering firms across the United States and asked where they saw the greatest need for development in their organizations. Overwhelmingly, they pointed to people-centered areas -leadership, communication, and teamwork. One firm owner told me they had engineers with outstanding technical capabilities, but who struggled with the people side of the work. And what stood out to me was how project management came up in that conversation, not as a need for better tools or tighter schedules, but as a need for stronger people management capabilities. That distinction matters. And this is where I want to pause and talk briefly about merit, because what counts as merit in engineering has long been defined very narrowly and often by a relatively narrow group of people. Traditionally, merit has been tied to what's easiest to see and measure. Individual technical output, credentials, speed, precision, independence. And again, those things matter. I want to be clear about that, but they are not the full picture of what makes engineering work successful. What often gets left out of our definitions of merit are the very factors that allow projects and teams to function. Who helps align the team when priorities conflict? Who translates technical decisions for non-technical stakeholders? Who surfaces risk early? Who holds work together when conditions change? Who takes on the mantle of mentor for students and early career professionals in ways that are not self-serving? These contributions are real. They are consequential and they are often invisible in how we evaluate performance, assign credit, and make decisions about advancement. So when we say someone lacks merit, what we often mean, whether we realize it or not, is that their contributions don't fit the narrow categories we've decided to value. And when that happens, it's not just engineers who are affected, and it's not just individuals. It's the teams that suffer, projects suffer, and organizations quietly lose capacity they didn't even realize they depended on. This is why expanding how we understand merit isn't about lowering standards. It's about seeing the full system of work and recognizing the contributions that actually make engineering outcomes possible. I want to pause here and make this personal for just a moment because the question of merit and who gets seen has shaped my own path. The scholarship I mentioned earlier is called the Geraldine E. Jackson Scholarship, named after my mother. She's the person who convinced me to major in engineering at a time when I didn't see myself as an engineer, and the system around me didn't either. When I graduated from high school, I planned to major in music and foreign languages. I'd done poorly in math, so engineering felt completely out of reach. It wasn't even on my radar. My mom saw potential in me before I did and before the system did. So as a result, much of my work over the past 30 years has been about making sure other'Yvettes' don't fall through the cracks. And sometimes that means being Geraldine Jackson for someone who doesn't have that support, but more often it means challenging the systems that create those cracks in the first place. I share that here because it brings us back to the core point of this episode. Engineering outcomes are shaped by who is seen, who is supported, and whose potential is recognized early enough to matter. If you want language and structure to think more deeply about this, I've written a companion ebook called Engineering for Society. One of the core ideas in the book is exactly this. Engineering outcomes are produced through systems, not silos, by interaction, not isolation. If having something tangible to reflect with is helpful, you can find the ebook at engineeringchangepodcast.com free of charge. Now, it's time for the system check. As you move through your work over the next couple of weeks, listen for how expertise is defined, sorted, and rewarded. Who is treated as part of the technical system and who isn't? What kinds of knowledge move easily across roles and boundaries? And what gets siloed, dismissed, or labeled soft? Ughh - here it is again. What counts as merit in your organization? Who decided that? And under what conditions? Which contributions are visible early enough to shape decisions? And which ones only become apparent when something breaks? Then ask yourself, which of these dynamics, skills, and capabilities actually determine whether the work succeeds? And if you catch yourself about to use the term soft skills, just remember, there's a scholarship fund out there that appreciates your awareness. Thank you for listening. If this episode was useful, do me a favor, subscribe and leave a five-star rating and review. It helps this work reach others who are navigating change. To download resources or share ideas and questions for the show, visit engineeringchangepodcast.com. Until next time, remember, the most meaningful change comes from being as intentional about our systems as we are about our solutions. That, my friends, is ENGINEERING CH∆NGE®.