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

Sometimes a Meeting Beats an Email

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. 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 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. 

The Value of Meetings (effectiveness)

To make it worse, asynchronous updates (messages and emails) were helpful for many but many others needed meetings to engage the challenges and nuances. 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 have 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
• Get introductions to people I didn’t know
• Build relationships before solutions
• Accept that you just can't win 'em all

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 project management communication lacked.

So this second story serves mostly as a note to myself and to others: communication isn’t only about clarity and frequency. It’s mainly 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. Because to go forward requires relationship.

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

Proof of Concepts and Small Steps in 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 fairly tough questions. There was a sense of, “How are we going to manage this workload?” Pre-Op in particular was working long days, often from 8 in the morning to 7 or 8 at night. Doing their best, but exhausted. There was much work, a lot of admin, and many spreadsheets that were harder than they needed to be.

Our thought was: if there’s anything we can do to make their load lighter, we’d like to try. Even if that’s something fairly small.

What we did was not fancy. It was cleaning up spreadsheets, making workflows consistent and simple, and making it easier to see and manage the information. We weren’t replacing everything. We tried 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 (cut 1.5 hours per day for one person)
• Fewer errors and stumbling blocks (found over 150 errors on day one)
• Better visibility into what was coming next
• Going from 78 tabs in Excel to 10 (!!)

To be fair, some of the improvements also came as the team got into a rhythm. Not everything is about tools or process; part of it is people learning to collaborate. 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

This reinforced for me that people can only listen to general promises for so long. A leader (CEO, president, manager, or prime minister) 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 and support it. A small, working proof of concept goes further than a million words or a thousand promises.

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. It was also quick.

Iteration Is Just The Start

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

People tend to join tribes and projects that are going well. We 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.