"Hope is not a strategy", but it is for them

"Hope is not a strategy", but it is for them

Besides "buckets of money", I learned some other terms while living as a pager monkey. One of them was "hope is not a strategy". While this could be used in its proper sense to remind people to design better systems, it was more frequently used as a way to shut down projects other people didn't like. Here's what I mean.

Let's say there's some system which is completely out of your control which still has a fairly big influence on how your service runs. You can't make changes to it without going through some other team which isn't exactly the most responsive about customer support. Customer support at this company is like a fractal: it looks the same no matter whether you're looking at it from the inside or the outside, from far away or from up close. It's almost always bad service.

This means you have to make the most of what you have. One day, you notice that a certain type of failure can at least be noticed before it has the ability to evolve far enough to where it will bother real users. While it can't solve the problem due to the wall between you and that other team, it can at least give a heads-up to whoever's on call for your service and let them know to avoid making things worse.

You bring this up with your team and they ask what it's supposed to do. You say something like "hopefully it will reduce the chances of someone switching us onto platform X when that other team is having a bad day at that location". That's an honest assessment, but there's a problem. You lost your audience at the first word: hopefully.

They heard that and their ears shut down. As soon as you stop talking, or maybe even before, they jump in and say it: hope is not a strategy. That's it. They're done talking about it, and they're done listening. They move on to something else. Nothing productive happens.

Time passes. Someone else proposes a significant change in the configuration schema for your service. They want to rewrite all of your config files to use a macro language which is the "shiny new thing". It has significant differences from what is already in use, and indeed, what most services at the company are currently using.

You ask the question: "what is this supposed to do?" and they answer: "this will make things better". You follow up with another question: "how will it make them better?", and they only say "it just will". They have no data and no examples to back them up. They don't even have anecdotes to at least convince you that there's something to all of this.

That's when you say "that sounds like hope to me", in an attempt to reference the sort of responses you got for your own idea. They ignore you, and carry on anyway, ultimately blowing a couple of months on a wobbly, bumpy, error-prone conversion process.

It's convenient, right? You have a program which will demonstrably print a warning when something could go wrong, and they dismiss it. They have nothing more than a grand idea and nothing to show for it and they go right ahead and poop all over things just because they can.

I call that a seriously messed up power dynamic.