Don’t tell me how to do my job!
IT is ever changing: one day it’s waterfall, next it’s agile, and soon it’ll be time for the “Waterfragile” method. Having worked under several of the frameworks-of-the-month club I can tell you that the only thing that really matters to me are the requirements. Far too often the How or the Why are what are requested rather than the What.
I learned about good requirements years ago from a prickly coworker. I crafted the perfect “New Server Request” email, where I told Joe which server I wanted racked, suggested an ideal rack within the datacenter, provided my guidance on which switch ports to use along with their desired configuration, and finally pointed him to the perfect disc image for the OS. Almost immediately, Joe responded with “Don’t F*****G tell me how to do my job!” [end of email].
I was shocked, flustered, and in anger started to write back a caustic message. As I typed, I considered the potential consequences and began to soften my tone with each rewrite. Eventually I was shocked as I realized that Joe was right. I didn’t care which rack the server went into or whether it used ports 17 and 18 on the 48-port network switch. What I cared about was simply, did the server meet my requirements?
My final response was something like, “Joe, please provide a server with compute of this size, connected to these networks, preloaded with a specific OS by Friday”. Changing my request from a How to a What gave Joe the freedom to provide a solution he considered best. If the server truly satisfied my requirements, and he could consistently deliver a solution that satisfied them, why should I care how he did it?
It was hard for me to bottle my anger that day, but I still think back and laugh at some of the angry responses I never sent. That moment of conflict has forever changed the way that I try to request work from others.