Don’t Just Push Harder

I’ve mentioned in this column that I’m not a handy kind of guy. Putting things together, fixing or otherwise tinkering with them, you name it.

That goes for anything hands-on, hardware and wetware alike. I knew very early on in my healthcare-days that I had no business in specialties that required manual tasks, such as surgery. Unsurprising, then, that rotations in interventional radiology (IR) saw me at far from my best.

Still, I did learn a few things. One of my more enduring recollections from the angio suites was a fundamental rule taught by the section-head: When you are feeding in a catheter or guidewire and meet resistance, do not just push harder.

I’ll refrain from describing all the bad things that might result from ignoring that bit of guidance; suffice to say that a lot of damage can be done.

While my post-residency life has included not a single IR procedure in which I might have directly applied teachings from that attending, I’ve remembered that particular lesson well…and, a decent chunk of the time, abided by it.

For more coverage based on industry expert insights and research, subscribe to the Diagnostic Imaging e-Newsletter here.

Not purely in a physical sense—it’s actually served me well in a more philosophical way. That is, if I find myself in a situation where I’m trying to get something done, and my initial approach doesn’t work, I usually refrain from more forcefully trying the exact same thing again.

That’s easier said than done. I’ve mentioned in recent columns that our brains are efficient/lazy things, strongly biased towards whatever requires the least energy from them. If we’ve sized up a situation and decided on a course of action, we tend to cling to that decision, even if that action doesn’t yield desired results. More so when the situation is emotionally charged (for instance, we’re getting frustrated by our failed attempts, we’re pressured for time, or we’ve got other things demanding our attention).

Applying the “don’t just push harder” lesson came most readily to me with manual tasks, since they had the most in common with my fumbling efforts in the angio suites. As unhandy as I know myself to be, I’m pretty capable of breaking things when trying to force them to physically work: opening items that resist being opened, closing items that don’t want to be closed, etc. Learning to substitute “This isn’t working, I’d better try harder” with “This isn’t working, is there something else I can try” led to fewer broken items.

A good example of a less-physical application in my recent work: I stumbled across a glitch in the voice-recognition software used for dictating rad reports. On certain occasions, the software gets derailed by something I said. As a favorite aunt of mine likes to say, the program will “lose its mind,” freeze up, and close. Adding to the fun, when restarted, the software fails to accept any dictation; turning on the microphone and saying anything makes it crash again.

As mentioned earlier, my brain wants me to “just push harder.” The software should work. Even if it crashes, I should be able to restart it, hit the dictation-button, and resume work with nary a delay. Every time, the temptation is there to just fire it right back up and hit the button again, maybe getting righteously angry in the process. But that doesn’t work, and even if it occasionally did, it wouldn’t make the underlying problem go away.

So, after this had happened more than a few times, I reached out to Support so I could describe the issue to them, even demonstrate it with them remoted into my workstation. It made sense that they should gather all of the info they could so as to root out the problem, even though (thus far) I was the only rad having the issue. Ultimately they had no idea for a fix, but were presumably armed with data to present to the software-developers so they could figure things out.

At some point during all of this I found a workaround: After the first software crash, if I relaunched but didn’t turn on the microphone, instead manually typing the next line or two in my report, I could then resume dictating without a problem.

Since the glitch still happens a few times each week, I can now circumvent the issue with my little workaround, instead of “pushing harder” by insisting on trying to dictate the normal way. At this point, I would even consider ringing up Support (“It’s happening again, do you have any updates on a fix? Want to remote in and gather more data? This is impairing our efficiency, you know”) to be pushing harder on an already-failed strategy.

Because my main purpose is not to be a software-tester and troubleshooter. I’m there to productively read cases. My workaround, irksome as it is that I have to use it, gets me back on-mission most quickly and effectively…whereas getting ahold of Support means that I sit idle until they get back to me, watch me demo the issue, try fixes, get screenshots, etc.

An even higher-level application of the “don’t push harder” philosophy I’ve learned is in dealing with other people or organizations, when there’s a difference of opinion or some other interaction where everyone isn’t on the same page.

It frankly amazes me how some people seem to think that the best way to debate is to repeat the same argument over and over, as if saying it enough times will somehow “get through” to the other side. Sometimes punctuated by talking more loudly, aggressively, even insultingly or threateningly. Instead of A) offering other lines of reasoning, or B) gathering additional information to better understand the other side.

I will close by with an incident from one of my later IR rotations, where a catheter or wire met resistance, and we paused while the attending came to the suite to feel things out for himself. A bit of fiddling with his more-expert hands, and he regarded us for a moment before saying, “Good, you’ve learned not to just push harder. Now you’re ready for the advanced lesson: Sometimes, if you’ve had enough experience, you can tell when it’s time to push harder.” Then, he successfully advanced the device.

Follow Editorial Board member Eric Postal, M.D., on Twitter -- @EricPostal_MD.