I have previously written about key metrics for support departments – and I stand by everything I said then. I have, however, come to the conclusion that another metric should be placed under consideration. A quick recap, however, of the metrics I proposed then, as well as what they are intended to measure:
One of many things I care about is improving the world around me. That is why I’m a union representative, it’s one of the reasons why I like my job, and it’s why I raise questions to find out if there are good reasons for things being done the way they are – and to change them if there aren’t. Every so often, I’m met with arguments that aren’t really arguments at all, and which really should prompt a re-examination of the subject matter.
With the launch of the Unicorn project, I revisited the Phoenix project. Seeing as my previous review was a mite lackluster, I decided to revisit that, too.
An important principle of ITIL is that all requests should go through a single point of contact (abbreviated to SPOC). What this means, is that a single channel should be defined for the reception, classification, and distribution of a request or incident. Crucially, it does not mean that all contact with the customer should be done by tier one.
The title of this post might seem a bit on the conceited side. After all, who am I to claim to be a DevOps practitioner, much less thinker? I will simply say that I am working to implement DevOps principles in my day to day life, am spending more than a little time reading, thinking, and writing about DevOps, and though I may not be considered a DevOps thinker today, I certainly aspire to join their ranks. The title, then, is a statement of aspiration, more than a statement of achievement.
My first IT job was a one day per week internship with a pharmaceutical company while I attended my last year of high school. It was the first time I was exposed to the constant stream of support and service calls that makes up a large part of the day to day life of a support technician. I remember having a distinct impression that the IT department was constantly over-worked, always having too many things to deal with.
This was originally written before I read chapter 18 of the DevOps handbook. I feel strongly that peer review has greater legitimacy and chances of success than a system where a change manager is solely responsible for changes that may or may not fall within their area of expertise. It further grants employees more agency and autonomy in performing their jobs. While not directly addressed below, peer review is compatible with my views on change management.
I have, for some time now, been reading up on DevOps. One thing that, for some reason, keeps coming up, is that people seem to think that there is a fundamental incompatibility between DevOps and ITIL. The more I read, however, the more it becomes clear that there is no disparity at all between them. If you have been following my blog for a while, it should be fairly obvious that I have drunk the ITIL Kool-aid. Simply put, I think any operations shop that is not implementing ITIL is doing it wrong.
When performing a task, one will often be in the position to choose either doing something quickly, or doing something right. In many cases, either example is fine, as the job gets done satisfactorily. Still, I believe that you are better off with doing it right each and every time. Now, before you think I am preaching about my own level of perfection, know that this is not the case, and that I fail to do this more often than I would like to admit. This is not an admonishment; it is a level to which I aspire.
The first time I worked IT support in a professional setting, I was seventeen years old. I had gotten an internship (one day per week) with my uncle’s firm as part of my third year of vocational training, and spent a day per week with them. In the beginning, I was mostly hanging out with the IT staff, not really providing much of any use to anyone.