The Shelf

Author’s note: This was posted to LinkedIn a few years ago. 


We have shelves in our bathrooms at the office above the sinks. Crazy it sounds, those shelves are a great analogy for what is wrong at the company I work for.

Our office bathrooms didn’t always have shelves, mind you. Some manager or facilities person a few years ago decided: ‘It would be nice if we had shelves in the bathroom so people can place things there while they take care of their business.’ It’s a good idea, so a shelf was installed. Huzzah!

Things went well for a few months, then one day I noticed the shelf was starting to lean forward slightly, as if it were coming off from the wall. Uh-oh. I stopped using it because I didn’t want my coffee mug to fall into the sink when the shelf finally gave way.

It eventually did break, and for about a week we were once again shelf-less. It was re-installed and life was good again, but after a few more months, it started to lean forward and fell off the wall again.

While I have managed some minor home repairs myself, I’m not going to claim to be Tim the Tool-Man. If I shelf I installed gave way, then okay, fine, maybe I did something wrong or overlooked something that a professional would know to do from experience. How was it that our professional facilities people couldn’t install a simple shelf? A few months later, after we remodeled our building, I got my answer…

There are three brackets holding the shelf in place. Each bracket should have two screws, but for whatever bone-headed reason, only one gets put in. Why? Was the facilities guy in a hurry? Are screws that expensive? My best guess is that the guy figured one screw is ‘good enough.’

Whatever the reason, the job wasn’t done right the first time, and the shelf inevitably has to be repaired. Surely the guy learns that ‘gee, maybe I should do the job right this time and use two screws so this doesn’t happen again.’

Nope! He makes the same mistake again, and as you can see by the picture above (different shelf but you get the idea) he’ll be eventually repairing it again. Even then, the damage has been done and he’ll likely continue ad infinitum.

This is a perfect analogy for how my company does things:

  1. Get a good idea and implement it.
  2. Don’t make the product the right way the first time, but make it ‘good enough.’
  3. Attempt to fix problems after customers complain of issues.
  4. The fixes are also ‘good enough.’
  5. Everything is fine for a while, but the problems inevitably return and the damage has been done in loss of customer confidence and goodwill.
  6. Go back to step 3 and repeat.

So yeah, that’s the way things work (or rather, don’t work) at my office.

I’m just wondering what the facilities guy is going to do when he runs out of wall space. He should have plenty of screws, at least.

Contract-to-Fire

workI recently started a new position; my first-ever contract job.  At the beginning, I was enthusiastic about coming in and doing a good job.  I noticed a few deficiencies off the bat and made some recommendations for improvements in a group e-mail to everyone in the department.  My intention was to avoid some of the large issues that had plagued previous workplaces and improve our processes, because to be frank, there were none.

My recommendations were shrugged off with a big fat ‘MEH’ by everyone.  I don’t know if it was due to my relative inexperience at the workplace, or the arrogance of leadership, but for whatever the reason, the end result was that nothing happened, and the glaring issues remained.

I was miffed (but not completely surprised) by the lack of response.  I imagined that the thought process went something along the lines of:  “Why should we listen to this new guy?  He doesn’t know how we do things here.

My first thought was that I needed to change my approach and need address my manager directly instead of broadcasting to the group in the hope that we could come to a consensus.  My second thought became a lot more compelling the more it bounced around in my head:

“Why should I care?”

I should begin by mentioning that the position I was hired into has a nearly zero chance of becoming permanent.  Folks come here, they work for a year or two, and then they’re gone.  Because of that, I have nearly zero investment in this company.  Indeed, one of the issues that I wanted to address was knowledge management; if you’re going to have a revolving door of people coming in and out of a department, you might want to have a good documentation process in place so that not all of a person’s expertise walks out the door when their time inevitably comes.

Ultimately, I let it go.  I had said my peace, and if the Powers That Be decided to ignore it, then why should I make a fuss?  Obviously they know what they’re doing.  There’s also no sense in wasting my time with people that have no intention of listening to me.

The unfortunate truth is that a contract worker will never be completely engaged in the future of the company they work at, especially if they have no visible road to bigger and better things.

I’ve since kept my mouth shut about any new issues that I’ve noticed and given up any hope of things improving.  It doesn’t make any sense to fight the current, instead I’ll just keep surfing the wave of incompetence until my contract is up.

Besides, why should I be fully invested in the company’s problems when the company isn’t fully invested in me?

 

Bye-Polar

“I would like to withdraw from being considered for a developer position and instead want to be considered for a support position.  Thank you.”

I sighed as I clicked the “Send” button.  The email was going to an HR person at a local company that I had interviewed with earlier that day. We had been talking about a programming job, and I made the mistake of griping about having worked in under less-than ideal conditions at my last few jobs.  After hearing that diatribe, she asked me if I would instead be interested in a support job.  I said “no” out of reflex, but I think it was more likely because I wanted the higher salary that the programming job would command.

I was deluding myself, though.  I’m done with programming as a career.  From a mental standpoint, it probably was over months ago, but I just didn’t want to admit it.  Instead I chose to hang in there in the hope that things would somehow get better, but they didn’t, and so here I am.

I have always wanted to work with computers, and programming seemed to be a logical career choice. As time went on I gradually grew disenfranchised with it, though.  It did not help that I have never worked in a place where things were done “right.”  Instead, proper procedure and best practices were sacrificed to what I like to call The Altar of the Almighty Deadline.

I was chatting online with a friend about the whole situation shortly after the interview and during the conversation I had an interesting epiphany.  I started to wonder if my disinterest in programming as a job was related to my newfound interest in creative endeavors.  After all, I only really dove into creative things like writing, blogging and podcasting just over a year and a half ago.

I’m too lazy to look back through old blog entries and see if the two match up, but it raises an interesting question: am I starting to become more right-brained?  If so, does it have something to do with my desire to get away from programming?  The fact that I have also thrown my hat into the ring for technical writer jobs is also a telling sign.

Maybe I’m tired of being isolated all day at work and want to do something that involves contact with people, even if it is just over the phone or e-mail.  I worked with some great folks at my last tech support job, and heck, if the company had not hit a rough patch and started laying off, I might still be there today.  Or maybe its something more basic than that.  Maybe I just want to be as happy at work as I am outside of it.

Whatever the reason, I’m look forward to embracing a different side of the IT field, and some opportunities are starting to open up, so we shall see!

Randomizer’s 5 Rules of Tech Support

This is just a start, I’m sure that more will come to me as time goes on:

Rule #1 (People Suck rule): Customers are filthy liars. They change things, screw up their system, and then call you and insist that “it just stopped working out of the blue.” Okay, yeah, sometimes Windows or Visual Studio will randomly goof something up. The only thing that truly happens “just out of the blue” though is hardware failure. Everything else is either the result of something a customer screwed up or an new update that was automatically installed (or wasn’t installed in some cases). Customers will almost NEVER fess up and say what they did to goof up their system, though. Instead, they will make something up or just answer “Yes” because they think you’re working from a script.

Rule #2 (Sherlock Holmes rule) If all possibilities are eliminated, the impossible has to be the answer. When dealing with Windows and Visual Studio, sometimes weird stuff does just happen (see above). Hell, we’ve had Microsoft tell us: “Yeah, we know about that bug, but we aren’t going to fix it.” No matter how much a customer insists your suggestion will not work, insist that they do it. Even if it sounds obvious or weird to you, give it a shot, IT JUST MIGHT WORK.

Rule #3 (Mr. Rogers rule): Customers are like little kids; they want the newest stuff, they whine when it doesn’t work, they threaten to tell your parents (supervisor) if you don’t do something for them, you have to hold their hands and walk them across the street, and you also need to pat them on their head and tell them they’re special every once in a while. Always keep this in mind, especially the head-pat bit.

Rule #4 (Time Warner/Comcast/your cable company rule): If you are unable to help the customer (or cannot), always give them the illusion that you are trying. Every support team has certain customers that “cry wolf” and specialize in making mountains out of molehills, or that want help with somebody else’s product (usually Windows). Fark ’em. Give ’em what I call the “cable company” answer: “We’re working on it.” Wait, and then give ’em the bad news. If they think you tried, they will be less likely to get angry when they get the bad news.

Rule #5 (Lion King rule): EVERYTHING IS YOUR FAULT. Its your fault that the customer spilled tea on the keyboard. Its your fault that the power supply on their database server blew up and they have no backups. Its your fault the head programmer left and the source code for the app was on his machine that has already been re-imaged. Learn to live with this. Water off a duck’s back, baby.