When I worked at Bell Labs, there was a door that slammed really loudly when it closed. This wouldn’t be a big deal except that it was right near me. Oh, and it was in the middle of my team’s offices so when it slammed, nearly everyone on the team would jump.
We raised the issue with facilities and they weren’t interested in fixing it.
They also told us that we weren’t allowed to prop the door open because it was a fire door. It was supposed to stay closed.
They saw this as a very simple issue: The door was working as designed. As a fire-door, it was supposed to say closed. It was closing.
We saw it differently: This was a door that was supposed to stay closed. It wasn’t supposed to slam so loudly that it disrupted work. It was in a high-traffic hallway and the slamming happened every few minutes.
Our meeting with facilities was pretty useless. Facilities kept saying that the door works; we kept saying that the door works in a way that disrupts work.
“So, are you unwilling to try making it more quiet, or are you unable to make it more quiet?”
That was probably the wrong thing to ask.
“Both.” facilities responded.
“So, the current door can’t be any more quiet. Are you saying that if someone took a crowbar to it, you’d replace the entire door and mechanism and the new system would be more quiet?”
“Yes, but if that happens we now know it was you and you’d be fired for damaging company property.”
The lesson here is: I should keep my big mouth shut and just crowbar shit.
In Gene Kim’s “Three Ways of DevOps” that would be “amplify feedback loops”. Suffering in silence just enables the problem to never be fixed. You have to do something to amplify the existence of a problem so that it gets the attention it needs. Usually that means opening a ticket. Hopefully you won’t need a crowbar.
