Engineers...
Note: this ain't exactly a "tale", is more some phylosophical over-thinking about some events and stuff that happened. Take it like you want.
So, long time ago there were "developers" (or "programmers" wathever) that were "developing" the software, then there were "project managers" that were supposed to manage all that was required for the software to do what it was supposed to do, then "architect" that designed things at high level and so on and so forth.
Then there were System Administrators (also known as "do-everything") that were supposed to keep everything working, assist the users, fix problems, manage the hardware, the software and everything in between and around.
Then, one day, we don't know why or how, somebody decided that "system administrator" was a bad word. It was old-school, made you think about some grey dude sitting in a shitty office in the basement and shuffling old dusty papers. That, besides the papers, is exactly as many IT offices were (and still are) in the real world. It was time to stir things up and bring IT in the new shiny world of the future! And what better way than change a few special words here and there? As anybody that just finished the Marketing & Management Class from WallMart knows, you change the font and the logo and the whole world change with you. Who cares if everything else stays the same?
So the "system administrator" became a "system engineer". That is the same guy as before, maybe gets less money while doing more work, because now he has to "engineer" himself and even get some certification that are completely useless but the company can charge more money because of them.
And even the term "engineer" is getting a bit too much used lately. In the beginning, if you wanted to call yourself an "engineer" you needed to get a degree from some school or institution (normally a university), and that degree was used to demonstrate that you had, at least, spent some money and time on it.
Today, everybody is an "engineer". Software engineer that have never used a debugger and don't even know what it is, hardware engineer that don't distinguish between an hard disk and an SSD, network engineer that don't know what UDP is and to finish it up, System engineer that don't know what a 'system' is.
I keep insisting that my title should be just "system ADMINISTRATOR", if we want to get on with the exotic "penguin wrangler", and I've already talked about the problems of describing what I do to the not-in-the-loop.
All this came back because sometimes ago there were "problems" related to the mangement of some "support ticket". To explain all this I have to explain how the thing work(ed).
$ShittyHostingProvider was initially a small and fast company where there was no real distintion between the various "techies". Some was more experienced on some stuff than others, but all of them were partaking into answering the phone and doing the "first line responder" to solve customer's problems. And things were going kinda ok.
Then, with the starting of the Diabolical Plan To Conquer The World, they acquired a huge amount of small-ish companies with crappy customers, and they (the management) had no clue how to manage all that. Moreover, to "improve the integration" the management decided to use the ticketing system that belonged to one of those "partner" companies. That ticketing system had been developed (at least, that was my impression) to work in a more "classic" structure, where you have a "first line support", a "second line" and so on.
And that didn't worked very well in our structure. If you add to that the tendency of some people at doing the least amount of work possible, and sometimes not even that, the result was that a lot of the tickets remained untouched for weeks, until the customer started to make noises and phoning every possible number until, by chance, they got the one of a manager. And then somebody started to yell.
After spending many, many, many meeting talking with the various SL/UL to "improve the group efficiency" and since DB had zero ideas about how to achieve that, he ended up reporting about it in our weekly meeting (that was supposed to be only about technical things). During that meeting we made clear that 1. our group was by now the de-facto "first line support", since our phone was the "default phone" and basically all the discussion were about "managing tickets" and nobody had any more time to do anything else, and that wasn't nice, 2. tickets that refer to stuff we had no idea about (because they refer to stuff that belonged to other "teams") remained untouched because... we had no idea about them and no info about who was supposed to handle them either and 3. the idea of "escalation" had no sense since we had no actual "manager" that we could "escalate" things to.
During the very same meeting I also made clear that if somebody take a ticket from the queue, do almost nothing with it and then toss it back without adding any note about the work done (or not done), it is basically impossible to figure out what the status of that ticket is. So my proposal was the following: have a division between the "first liner" and a "responsible" person that decided which ticket had to be managed by the first level and which one have to be delegated to a "second" (or eventually a third) line, distribute the tickets to the competent "team" and so forth.
My idea was immediately rejected because "wasn't in line with the spirit of the company".
ME - Which spirit? the one you're drinking?
DB - No, but the idea that somebody should always pick up the phone.
Me - And where is the news? Shouldn't we always pick up the phone? The fact that when some idiot calls the phone that rings is always ours, automatically imply that we are the "first level support". What I am saying is that there should be a RECOGNIZED first line support and possibly not being us.
DB - But then we have to hire more people.
Me - Considering that we're buying whole companies it shouldn't be a big problem. Or everybody now is a superspecialized genius?
DB - No but...
Me - ...but?
DB - It's that the management doesn't want to have a "first line"...
Me - And what are we then?
After having run circle around the issue for about half an hour, the 'discussion' moved onto what this immaginary "first line support" should've done.
Me - To me it looks obvious: answer the phone first and foremost and try to figure out who's talking, who is the correct team for their problem and then make a ticket with the best description of the problem possible. Then look at the tickets, all of them, and if there is a standard solution to apply it. Otherwise pass the ticket to the correct team.
DB - And can they identify if a solution apply or not?
Me - We have systems that, semi-regularly, manifest "problems", problems that are due to the crappy applications that runs on those systems and in many circumstances the best solution is to simply restart the application. Is not a solution but is the best we can do. To really solve the problems we should throw out the customer and their systems but that has other problems.
DB - Yes but how do they decide if the problem is one of those?
Me - By reading the documentation. That incidentally, only exists for the systems WE are managing. And this bring us back to the real problem: WE DON'T HAVE DOCUMENTATION ABOUT THE STUFF OF THOSE MORONS!
DB - But, even if there is the documentation, how can those "first liner" understand the things?
Me - ...applying normal debugging principle? Like, look in the log? Try a telnet? A ping? Lit a candle to the Gods? What the fuck are you expecting?
DB - But then they are "engineers".
Me - ... what do you mean?
DB - If they can do that then they are engineers and should be paid like so.
Me - If this means we should get more money then I'm for it. If you're assuming that the ability to do a telnet or read a log make you an engineer... you have a very low esteem of what we do or you don't know what the fuck you're talking about.
DB - Well, debugging, logging, networking...
Me - Make a ping and look at a log ain't enough to qualify as "engineer". You could get an idea of what kind of problem is it or if it is a problem in one specific machine or is a larger, more complicated thing and route the ticket to the correct second line support group.
DB - Team!
Me - ... Team, wathever. But is still not enough to be an 'engineer'.
DB - Yes but..
Me - You play guitar, right?
DB - Yes, why?
Me - So you're a rockstar. When are you going in tournee?
DB - What?
Me - You play guitar, hence you're a rockstar. That's it.
DB - That's not how it works..
Me - No, the same goes for your idea.
The discussion went on for a way too long time and, in the end, as usual, nothing was done or decided. What was clear was that DB had no idea about what an 'engineer' does or is and especially what they SHOULDN'T do. Like waste an inane amount of time in trivial problems that any "first line tech" should be able to fix by following standard procedures.
And that is also a reason why I left.
Davide
06/06/2019 15:04
