Communicating With Stakeholders and Learning Where Influence Really Happens - Part 2 of 3

Talking to the Right People (and Not Just Sending Emails)

Do you want to be effective, or efficient?

This second theme that has emerged from the hospital work is around communication and influence. Not communication in terms of “Did I send enough updates?” but more, “Did I talk with the right people, in the right way, early enough?”

Looking back, I can say I did a lot of communicating. I talked with people on the hospital side here on the ship. I talked with people back at headquarters. I kept our operations team in the loop. I kept the project manager up to date. I shared what we were doing, what we’d improved, and what the results looked like.

Even so, there were still key people who did not have the level of visibility or relationship they needed if this was going to move from a local proof of concept into something longer-term. That gap only really became clear to me later.

One More Level Up

One of my lessons is that there is usually “one more level up” I haven’t connected with yet. The people who get copied on emails are not always the same people who feel ownership, or who remember you and your project when broader planning happens.

Mistakes were made. Sending emails or messages is not the same thing as building a working relationship. In many cases, the content could have been shared asynchronously, but the connection and trust needed for buy-in would have required at least one or two real meetings. I didn’t push for those enough early on. 

You Can’t Talk People Into Caring

I tried to make the value clear. I showed examples of time saved and errors caught. I explained what this could unlock for the hospital if we kept going. But if someone is stretched thin, has other priorities, or doesn’t really know you, they may not have the capacity or the context to engage. Some of this is basic, some of this is cultural, and some of this is the English used.

If I rewind this, a few things I’d do differently:

• Involve more onshore teams earlier and more deliberately
• Ask others to make introductions to people I didn’t know
• Build more relationships before diving into solutions
• Accept that you just can't convince everyone

Even with all of that, I’m still grateful for what we were able to accomplish. The Pre Op team’s workload became  lighter. Their days became a bit more manageable. The changes mattered, even if the higher-level communication wasn’t perfect.

So this second story serves mostly as a note to myself: communication isn’t only about clarity and frequency. It’s about connection. It’s about whether the people who need to be involved actually feel connected to you and understand the work in context. That’s something I’ll pay more attention to going forward.

Proof of Concepts, Progress, and the Realities of Helping - Part 1 of 3

Proof of Concepts and Small Steps with the Hospital

When I think back on this field service (thus far), one of the themes that keeps coming to mind is the value of trying small things first. Not huge systems, not big redesigns, but proof of concepts and small changes that help people see progress.

Coming into this year, the hospital was asking some fair questions. There was a sense of, “How are we going to manage this?” Pre-Op in particular was working long days, often from 8 in the morning to 7 or 8 at night. They were doing their best, but they were exhausted. There was a lot of work, a lot of admin, and a lot of it ran through spreadsheets that were harder than they needed to be.

I and others did not arrive thinking, “I know how to fix this.” We just kept hearing that they were underwater and that this had been the case even in the last field service. So our thought was: if there’s anything we can do from the finance side to make their load lighter, we’d like to try. Even if that’s something fairly small.

A lot of what we ended up doing was not fancy. It was cleaning up spreadsheets, setting things up so they were more consistent, and making it easier to see and manage the information. We weren’t replacing everything. We were simply trying to make what already existed more usable and less heavy.

We could see the difference in a few ways:

• Less time spent on certain recurring tasks
• Fewer errors to sort out later
• Better visibility into what was coming next
• Going from 78 tabs in Excel to 10 (!!)

To be fair, some of the improvement in how the team felt probably also came as they got into a rhythm together. Not everything is about tools or process; part of people is people learning to work together over time. We can't nor want to take credit for things that weren’t ours. But we do know that the changes we made helped, and the hours saved and errors reduced were real, not theoretical.

Why Proofs of Concept Matter

One thing this reinforced for me is that people can only listen to general promises for so long. A corporate CEO can restate the vision only so many times before it means nothing. You can say, “We’re going to improve this,” or “We’re working on a better system,” over and over, but if nothing changes in their day-to-day work, it’s hard for anyone to believe. A small, working proof of concept goes further than a million words.

Waterfall-style projects—long planning cycles with little visible progress for months—drain morale. What helped here was taking one piece at a time, improving it, and then doing that again somewhere else. It brought attention, insight, and a collaborative environment.

Iteration Doesn’t Replace Alignment

As helpful as the proof of concept was, it wasn’t enough by itself. To grow into something sustainable, it still needed leadership alignment, ownership, and advocacy from the right people. Small improvements spark energy, but can't carry themselves.

I’ve also noticed that people tend to move toward work that is going well. They want to be associated with what is "moving up and toward the right". That isn’t negative—it’s human. Small working improvements help generate that interest and momentum.

So for me, this first story is about that: using small proofs of concept to show what’s possible, to lighten the load a bit, and to remind myself that progress here is usually incremental, not all-or-nothing.