Being Right Isn't Enough

A lesson in job site politics nobody puts in a training manual.

Ninety VAV boxes. All programmed identically. All piped and wired the same way, or at least they were supposed to be.

I was deep into commissioning when a handful of hot water valves started behaving backwards. Calling for heat, valve closing. Not calling, valve opening. All my programming was identical, all my wiring checked out, and the rest of the boxes were fine.

I dug in. Pulled the installation spec, looked at the actuator orientation. The heads were mounted wrong. Rotated the wrong direction at install. The fix was almost embarrassingly simple: remount the head, five minutes a box.

I walked into that meeting with the data, the diagrams, and the spec page showing exactly which way the actuator needed to face.

It didn't go the way I expected.

The mechanical contractor pushed back. Schedule pressure. The usual friction of a room full of people with somewhere else to be. I made my case. I had the documentation. I was right.

My PM listened to the whole thing and then looked at me.

"Can't you just reverse the output in the program?"

I started to explain why that wasn't the right answer. Inconsistency in the system, the underlying install issue still not corrected...

He nodded like he'd heard this before.

"Do it anyway. Being right isn't always as important as it seems."

So I did. Reversed the outputs, documented which boxes were affected and why, and we moved on.

On the drive back I kept turning it over. And here's the thing I had to sit with: the fix I'd argued for wasn't actually wrong. But it also wasn't fully right.

On a union job, I'm not touching mechanical work. Remounting the heads wasn't my call to make, and pushing for it would have created a different kind of problem. The program change was functional, documentable, and didn't blow up a relationship we'd need on the next job. My PM saw that before I did.

I'd walked in holding the correct answer to the wrong question. The right technical diagnosis doesn't automatically point to the right move. That was hard to feel good about at first. I wanted the problem to be simple: I was right, they were wrong, fix it correctly. But the situation had more dimensions than that.

Technical correctness is the floor, not the ceiling. Knowing the heads were on wrong was the easy part. Knowing what to actually do about it, given the people, the contract, the politics, the schedule: that's the harder skill, and nobody teaches it.

Field-Ready will try. But I'll be honest with you about how complicated it actually is.