On Favours

I had intended for my next post to be about the infrastructure of my one-man IT department, but when I came into the office this morning, an unfamiliar computer was sitting on my desk with a Post-It attached. It explained that this was my boss’s home computer, and could I please figure out why it wasn’t booting?

It may be something that we all have to deal with from time to time: fixing computers for co-workers. Like it or not, we’re often the only ‘computer guy’ known to them, and their first port of call. ‘It’s no problem, is it? Surely you can have a look at lunchtime? It’s not urgent, it’s just that my son can’t do his homework…’

I tend to accept this as a part of the job, and try to be accommodating, but I’ll prioritise these tasks like any others. I’ve never had any specific instruction about how to handle these situations, but I find it best to deal with them as an actual part of my job, in all respects, implied if not specifically listed in my job description. So I don’t expect any compensation for doing these tasks, and I’ll work on them in company time, but not in my own time. If I’m busy, they may sit around for a while before I get to them, and I’ll make sure the person knows that. And if a fix is going to be complicated or cost money, I’ll hand the machine back and explain what’s wrong with it and why I couldn’t fix it.

Essentially, I treat any employee machine that’s brought to me in the same way as a machine that originated inside the company (though I’ll order new parts or a replacement for a company machine if it’s necessary). I know that with this comes a risk of people taking advantage, but I don’t think it’s happened yet, and by dealing with these tasks as any other part of the job, on company time, I can at least ensure that they are taking advantage of the company’s resources, and not me personally.

What other approaches could someone take to this scenario?

Link of the Day

The Top 5 Reasons to Be a Jack of All Trades
Author Tim Ferriss makes a strong case for being a generalist. “Be too complex to categorize.”

Let’s get the introductions out of the way

Welcome to the blog. I tried and failed to come up with a good pseudonym (I don’t want to reveal my identity right away, as that would expose my employer, which is a perfectly fine company but I see no benefit in outing them, especially since I’ll be blogging on company time), so I guess I’ll just call myself C, which may or may not be one or more of my initials.

In this blog I’m going to write about my job, and my job is that of a one-man IT department. Within the small company I work for, I have sole responsibility for every computer-related task: speccing, ordering, building, installing, and supporting new hardware; brainstorming, designing, writing and maintaining software both for internal use and for our customers; mocking up, designing and updating any websites we need; and a long list of other tasks predictable and diverse.

I came to this job a couple of years ago after a long stint at university. On some parts of the job description I was already strong; but on most of it I was not, and the job has entailed, and continues to entail, a large amount of learning while doing. I’ve made mistakes, and gained insights, and through trial and error, worked out some methods that mostly work for me; but I’m no authority, and still have a lot to learn. I’ve done nothing to document this formative process until now, partly because I don’t know of anyone else who is in a similar situation, but I know there must be plenty more of us out there.

I hope that this blog might become a place to congregate, swap stories, and learn; we task-jugglers, jacks-of-all-trades, sysadmin-coder-designers, one-man-IT-bands, go-to guys; writing AJAX web apps one day, rewiring the building the next. We who stand alone, tucked away in our little offices, with no teams, no regular meetings, no coffee-break discussions about work, and not much contact with others of our kind; figuring out solutions alone with the aid of books and the internet, not through conversations as part of a team. A different kind of work that requires a few modifications to the usual approach.

So this is for all the generalists out there. We may not be great at everything we do (at least, I’m not), but we can do a lot more than just what we’re great at, and do it acceptably well, and after the specialist has seen all his accumulated knowledge become obsolete within a few years after being snubbed by technology’s fickle trends, we’ll still be needed.