What can a NASA engineer teach the martech community? Quite a bit and the most valuable lessons go beyond technical expertise — emphasizing communication, leadership and problem-solving strategies that drive project success.
John Ruffa, a former NASA engineer and my good friend, shares these insights in his book “Nice Guys Finish Last And Other Workplace Lies,” available on Amazon. Drawing from his long and successful career, he offers lessons that resonate deeply with technical projects I’ve been involved with — insights that will benefit the martech community.
Ready, fire, aim
Some organizations like to foster an “inclination to action.” Challenge assumptions, they say. Break things. Be disruptive and see what happens.
That mindset works for certain projects where experimentation drives progress — but it clearly fails when launching a spaceship, which can’t be brought back for repairs mid-flight (with rare exceptions).
My first takeaway from the book was the importance of understanding the type of project you’re working on. Does it have to work every time in harsh and potentially unpredictable conditions? If so, you can’t be cavalier about functionality and technical requirements. For example, if you’re developing tools for doctors, don’t hire people whose experience comes from building apps like Facebook or TikTok.
This “ready, fire, aim” attitude highlights a core challenge in aligning marketing with technology teams. Systems people need to create a stable product that works, while marketing often wants to try something different. Those attitudes frequently collide.
In this and in so many other ways, it’s not technical expertise that wins the day.
Dig deeper: The only two things that matter in marketing
Soft skills
The biggest challenges technical teams face are non-technical people issues, such as poor communication, turf battles, conflicting agendas, differing cultures, lack of team cohesion, poor leadership and clashing personalities.
While it’s easy to get technical people on board with the need for documented procedures to diagnose and solve technical problems, they are often slower to address people-related issues, which are the root cause of most blunders.
For this reason, it’s essential to evaluate new tech staff on soft skills, including creativity, persuasion, collaboration, adaptability and emotional intelligence. This is easier when promoting from within, where you can observe how someone handles adversity or gather insights into how they work with others. When hiring externally, make soft skill questions a priority when checking references.
But that’s not enough. Incorporate soft skill training into employee onboarding, reviews and ongoing development. It’s tempting to focus continuing professional education on hard skills, but it’s the soft skills that are most likely to trip you up.
Build a network
You don’t need to know how to do everything, and if you think you do, you’re probably flattering yourself. It’s crucial for technical people to create a list of go-to resources for advice on key issues. You’ll demonstrate your expertise more effectively by surrounding yourself with experts than by trying to be the expert on everything.
Managers in technical fields shouldn’t work in isolation. They should build a network of trusted colleagues they can rely on.
I heard that to land a job in the first Bush administration, you had to prove you maintained at least one friendship from high school. While that may sound irrelevant to professional life, it’s not. The skills needed to sustain a friendship over time are valuable. Maybe that’s a better interview question than “What’s your biggest weakness?”
Also, remember the lesson of Socrates and the oracle at Delphi. Socrates was considered the wisest man because he understood the limits of his own wisdom.
Communication
Ruffa was shocked to hear NASA’s chief engineer say that “virtually every NASA failure could be attributed to a breakdown or failure in communication.” Not technology. Not materials. Communication.
Engineers and technical experts are often not the best communicators. Whether it’s a right- and left-hemisphere issue, personality or culture, that’s how it often plays out. A key communication failure occurs when people don’t share, question or challenge assumptions. For example, assuming “they’re using the metric system” led to the Mars Climate Observer crashing into the planet.
A remote work environment can worsen communication failures. John recalls wearing out the carpet between his office and key collaborators. It’s harder to replicate that interaction over Zoom. Communication becomes even more challenging across time zones, languages and cultures. In such settings, extra steps are needed to ensure clear communication.
Systems engineering is not only a technical task but also one of communication. Systems must work together.
“The number one thing an effective leader can do to set their team up for success is to create an environment characterized by clear, open, honest and effective communication.” But don’t assume your methods are working. Follow up with team members to ensure there are no hidden issues or concerns.
Dig deeper: The 4 secrets of effective communication
Don’t tell the boss
A major communication problem is built into an organization’s hierarchy. Some people are reluctant to escalate issues, while others are too eager to do so. As a result, problems can fester at lower levels, upper management remains unaware and resources are spent addressing the wrong issues.
I heard an interesting anecdote from a priest that seems relevant here. In the Catholic Church, if a bishop assigns a task to a priest, the priest must comply. However, a wise bishop will want to know if the priest genuinely wants to take on the task or is simply doing it out of obligation. He might send another priest to ask, “The bishop knows you’ve taken a vow of obedience, but before it comes to that, what do you think of the job?”
The key here is to create intermediary steps where issues can surface despite the hierarchy. Executives can facilitate this by building relationships at every level of the organization. Layers in org charts can create invisible barriers to communication that can undermine projects. Make a conscious effort to engage with people both up and down the chain of command.
Test, but test your tests
One anecdote from the book that stood out involved testing a system under conditions it was likely to face in space. The system failed, causing scheduling delays, long hours and budget issues.
But the system hadn’t failed. The tester had.
It’s crucial to test your systems before they go live. But don’t forget that when a system fails a test, it might not be the system’s fault. Testing procedures might not have been followed correctly.
This is also a lesson in testing your assumptions. The human brain can only process so much information at once, so it filters out details and takes shortcuts. Sometimes, these shortcuts make us blind to the important details we need. Learn to question your assumptions and listen when others do the same.
Put down the tech books for a minute
It’s essential to be an expert in your field, so spending time studying and staying updated is important. That said, Ruffa reminds us that technical expertise alone isn’t enough. Many of the issues that derail projects are people problems, not technical ones. The next time you request professional development or training, consider focusing on soft skills.
Dig deeper: The secrets of effective leadership
The post What martech practitioners can learn from a NASA engineer appeared first on MarTech.