A Reliability Engineer’s Perspective on a Horrible Physical Therapy Experience

My hip hurt after this play

I had a horrible physical therapy (PT) experience — and my background as a reliability engineer helped me understand why it failed.

The Problem Statement

Since last December, I’ve been dealing with persistent pain along the lateral side of my hip and leg. I’m a volleyball maniac, and this injury hit me both physically and mentally.

-It hurt every time I jumped. -My vertical dropped. -I subconsciously avoided using full power. -Some nights, the pain was bad enough to wake me up.

I tried resting for a couple of weeks, hoping it would resolve itself. It didn’t. So I did what most people would do: I searched for an in‑network physical therapist and booked an appointment.

Because of scheduling delays, I finally saw the PT one month later.

The Diagnosis (or So I Thought)

During the first visit, the PT asked a few questions and ran some range‑of‑motion and strength tests around my right hip joint. Based on that, the conclusion was:

• Limited hip joint space
• Pinching during movement
• Possible scar tissue
• Weak glutes

The prescription: High‑rep, low‑load exercises to “remove scar tissue” and strengthen the glutes. At the time, this sounded reasonable.

The Execution

Each session followed a similar pattern:

• The PT showed me a few exercises
• Unless it was a brand‑new movement, I was mostly left on my own
• There was very little 1:1 observation or adjustment

Week after week, I reported the same thing:

“Daily life is mostly fine, but it hurts a lot during and after volleyball — especially jumping.”

I kept going, hoping improvement would eventually show up.

It didn’t.

What did show up was the bill: Thanks to my insurance, each visit cost $80 out of pocket.

That’s when I quit.

And that’s when I got mad.

Then I Asked: Why Did It Fail?

Once the frustration settled, my reliability engineer brain kicked in.

Physical therapy, at its core, is failure investigation and mitigation. The “system” is the human body. Pain is a failure signal. Treatment is a corrective action.

And looking back, there were several red flags — very familiar ones. In this specific PT experience,

1. The User Profile Was Ignored

In reliability engineering, understanding operating conditions is fundamental.

My failure mode occurred during:

• Jumping
• High‑impact
• High‑cycle loading (volleyball)

Yet:

• My jump mechanics were never assessed
• Single‑leg landing or stabilization was never evaluated
• Fatigue and repetitive stress were not considered

This is equivalent to analyzing a component failure without ever testing it under its real load profile.

2. Module Testing Instead of System‑Level Testing

What was tested:

• Local hip strength
• Local range of motion

What was not tested:

• Kinetic chain behavior
• Ankle stability
• Alignment during dynamic movement
• Load transfer across joints

In engineering terms, this was module‑level validation without system‑level integration testing.

A system can pass every local test and still fail catastrophically in real operation.

3. No Failure Event Chain

In reliability analysis, we don’t stop at “what broke.” We ask:

• What initiated the failure?
• What propagated it?
• What secondary stresses were introduced?

There was no clear failure event chain built here.

For example:

• Could lateral hip pain be compensatory?
• Could ankle weakness or alignment issues overload the hip?
• Could asymmetrical landing mechanics be driving fatigue damage?

Without understanding the chain, corrective actions become guesswork.

Final Thoughts

This post isn’t about blaming one PT. It’s about recognizing that methodology matters, regardless of the domain.

As reliability engineers, we know:

• Context matters
• Load matters
• Systems matter
• And failures rarely exist in isolation

When those principles are ignored, even well‑intentioned solutions can fail.

Ironically, this experience didn’t just teach me about my body — it reinforced why structured failure analysis exists in the first place.

Sometimes, the problem isn’t lack of effort. It’s lack of system thinking.