The PhDs in Iowa

A marine scientist's guide to disagreeing with smart people without burning bridges

For a very short period of my career, I was a Kelp Field Manager. A marine scientist responsible for everything that happened on the water — deploying gear, collecting samples, running operations safely, getting the data the projects required.

Some of the people designing those projects were PhDs based in Iowa.

Now, I love Iowa. But there's no ocean in Iowa. These researchers were brilliant in their domains — statistics, ecological modeling, project design — but they had zero firsthand experience working on the water. Some of them had never even seen the ocean, never mind work on it.

They'd design projects that, on paper, looked great. The methodology was sound. The sampling plan was rigorous. The statistical approach was elegant. And then I'd look at the plan and realize that some of what they were proposing was simply not feasible. They didn't know what a six-foot swell does to a small boat. They didn't know how currents would carry deployed gear. They didn't understand how low visibility, cold water temps, weather windows, or tide cycles would constrain what we could actually do.

My job was to tell them.

And telling smart, accomplished, credentialed people that parts of their work don't make sense is one of the hardest conversations in science.

The Trap That Most People Fall Into

When you're the one with practical expertise and you're working with people who have credentials but no field experience, there are several easy ways to get this wrong:

Option 1: Execute the plan anyway.

Just do what they ask. Watch parts of it fail. Let them figure out the problem from the results. The trouble: you're wasting resources, the project suffers, and somehow the field team ends up blamed for failures that were baked into the design.

Option 2: Be snarky or condescending.

"How do you think a boat works exactly?" That feels satisfying for about thirty seconds. Then you've permanently damaged a working relationship, made the researcher defensive about every future suggestion, and reduced your credibility from "field expert" to "difficult colleague."

Option 3: Be so deferential you never raise the problems.

Defer to their credentials. Tell yourself they must know what they're doing. Watch the project fail and feel quietly vindicated. The trouble: you actually had the knowledge that would have prevented the failure and you chose not to share it. That's not respectful of hierarchy. That's abandoning your responsibility.

Option 4: Refuse to engage with their plan at all.

Become known as the field manager who's difficult to work with. Get fewer interesting projects. Develop a reputation that follows you. None of this serves the work.

None of those were good options. What worked was something different — and it required emotional intelligence I didn't even know I was practicing at the time.

The Approach That Actually Worked

Over the years, I developed a pattern for these conversations, even before this position. It became automatic eventually, but it took practice. Here's what it looked like:

First, manage myself.

Before each conversation, I'd notice what was happening in me. I was usually frustrated. I sometimes felt patronized by people designing projects without consulting field expertise. There was resentment building. If I went into those conversations carrying all that, it would leak out and damage the work.

So I'd prepare myself: "These are smart people doing their best with what they know. My job is to share what they don't know, not to make them feel stupid." I'd channel my expertise into helpfulness, not superiority. That mental work was the precondition for everything else.

Acknowledge their thinking.

"I see what you're trying to accomplish with this sampling approach." Not flattery — actual acknowledgment that their reasoning had logic to it. Most pushback fails because the person on the receiving end feels dismissed before the conversation has even started. Acknowledgment opens the door.

Share the field reality.

"Here's what happens with these conditions when we're actually out there." Not abstract objections — specific descriptions of what reality would look like. Six-foot swells. Currents drifting the gear off-station. Tide cycles that meant our window was three hours, not eight. Specifics turn an objection into information.

Offer alternatives.

"What if we modified it like this — it gets us the data you need while accounting for X." This is the part most people skip. They identify a problem and stop there. But pushing back without offering a path forward leaves the researcher with nowhere to go. Offering alternatives keeps the conversation generative instead of stuck.

Make it joint.

"Let's see if we can find an approach that meets your research goals and works on the water." That last point was the key. The conversation wasn't about me proving them wrong. It was about us finding a solution. Their research goals stayed central. My job was to make those goals achievable and safe to accomplish in the real world.

Why This Worked

Most of the time, this approach worked. We found compromises. The projects got done. Relationships stayed strong. And over time, those PhDs trusted me more because they learned I wasn't trying to undermine them — I was trying to help them succeed.

The deeper insight: most people who outrank you don't actually want yes-people. They want help getting good outcomes. If you can show them you're working in service of their goals while bringing knowledge they don't have, you become valuable, not threatening.

But that only works if your own ego isn't in the conversation. The moment your pushback becomes about being right rather than about getting the project to succeed, everything falls apart.

This Dynamic Is Everywhere

I learned this on the water with Iowa PhDs, but the dynamic shows up across every scientific field:

• A mechanical engineer designing field instrumentation for a wildlife biologist who knows the deployment conditions

• A biochemistry PI planning experiments that a senior lab tech knows won't work the way described

• A bioinformatics specialist designing pipelines that the field team knows won't fit the data they actually collect

• A grant writer promising deliverables that the implementation team knows aren't realistic

• A new PI from one subfield running a project in another subfield they don't fully understand

In every one of these cases, someone has hands-on expertise and someone has designed work without that expertise. The relationship can go badly in any direction.

What makes it go well isn't the technical knowledge. Both sides have technical knowledge — different kinds, but real. What makes it go well is the emotional intelligence to navigate the conversation without either side's ego becoming the obstacle.

If You're the One Who Has to Push Back

A few things I'd tell my younger self about these conversations:

• Your expertise is real. You're not being arrogant by sharing it. You're doing your job.

• Their expertise is also real. Honor it even when the gap in their knowledge is obvious.

• Prepare yourself emotionally before the conversation. The frustration you carry into the room will leak out somewhere.

• Lead with their goals, not your objections.

• Bring options. Never just problems.

• Stay curious. Sometimes their plan accounts for something you didn't see. Be willing to be wrong.

• Build the relationship over time. One good conversation builds the foundation for the next harder conversation.

The PhDs in Iowa weren't the obstacle. The dynamic was. And the dynamic shows up in every scientific field where designers and implementers have to work together. The skill of navigating that dynamic well — without burning bridges, without abandoning your expertise — is one of the most undervalued capabilities in scientific work.

It's also one of the most learnable. I wasn't born knowing how to have those conversations. I learned. So can you.