This post is my fourth in a series providing some straightforward recommendations for managers responsible for the care and feeding of IT staff. I suggest reading Part One, Part Two and Part Three first if you haven’t done so already but it isn’t absolutely necessary. This part deals with the second key area of job satisfaction: the actual work performed by staff. This is one area where the Cabal Of Disaffected and Exploited Information Technology (CODE-IT) workers can be particularly demanding in ways that confuse managers and employers. To be honest, CODE-IT workers sometimes complain quite unfairly about their work being “boring” but this is an area where positive changes can be made to the great benefit of both staff and management.
So long as staff and management each understand where the other is coming from (aye, there’s the rub.)
Because I honestly believe this is one of the most subjective areas of job satisfaction in the CODE-IT world, I will be treading more carefully than usual. The two extremes of the spectrum are the CODE-IT high-flyer who thinks everything is below his mighty intellect (and this type is almost universally male) and the manager whose motivational speeches consist of variations on: “Getting paid should be all the motivation you need, now shut up and do what I say.” Neither of these attitudes is conducive to a happy workplace so I’ll be exploring the middle ground today.
I’ve never been fond of the CODE-IT warriors who spout condescending lines like “I don’t want to go to my grave saying ‘at least I made the company database more stable'” (these days you’re most likely to hear that sort of sanctimonious drivel from a Web2.0 entrepreneur or wannabe.) The truth is, somebody has to do the unglamorous jobs so it doesn’t serve anyone’s interests to degrade the day-to-day grunt work of the IT world. In fact, this is probably at least 75% of the work faced by IT workers so why is it looked down on so often? I think I hear the intake of breath as the CODE-IT equivalent of Opus Dei assassins prepare to kill me with poison darts from their blow guns (purchased on ThinkGeek of course) but here goes with some brutal honesty.
If you take on a job knowing full well the nature of the work involved, you should commit to doing that work no matter how boring you decide it is. There are two honourable courses of action: honour your commitment to do a job or leave for something you consider better. Don’t sit on your arse and complain. I have been accused of simply whining in these posts but I have to admit I have no time for someone who complains about a job and does nothing constructive to remedy the situation. Bad management isn’t the problem in these situations, the problem is a bad attitude.
Having said that, I would like to point out that management is in a very strong position to alleviate IT drudge-work. Too often, the complaints of CODE-IT workers are dismissed as whining (“They’re never satisfied,”) without looking at the root causes. Most CODE-IT workers complain about boring work not because they’re complainers by nature but because they’re trained, intelligent and driven individuals who want to be challenged and are constantly looking to expand their horizons. If your company can’t benefit by harnessing and channeling this sort of power, well, you have bigger problems than complaining CODE-IT workers.
Some self-help for the CODE-IT brigade: so you’re stuck doing boring work. Short of quitting and looking for a better job, what can you do? Step one: take pride in your work. If you can’t find the dignity in your work, nobody can. Whether you’re propping up the corporate database, refactoring code, tweaking the e-commerce engine or writing user manuals it actually feels better if you’re doing the work to the best of your ability or, better still, finding ways to stretch beyond your comfort zone. A friend of mine was a PhD doing some very fulfilling high flying research work at a well-known university when she was lured away to do contract/compliance analysis at a big legal firm by doubling her salary. People asked if she found this boring and she always said “No, because I apply the same intellectual rigour to this work as I did to my university research so I get similar stimulation.”
Plus she was a lot richer. I doubt she’ll be doing the contract work for the rest of her life but the point is, this is a very intelligent person choosing to do work that many people would find boring. Instead of focusing on the boring aspects she focuses on the positive and ends up feeling stimulated and well-rewarded. If you’re not applying a similar positive approach to your work then you’re falling into the old cliche: you’re not part of the solution, you’re part of the problem.
Step two to self fulfillment: identify the solutions yourself and then communicate, communicate, communicate. If you feel that your manager has no idea how to improve the quality of work assigned to you, this likely has one of two sources: (1) They don’t care about you and your quest for interesting work (2) They don’t understand enough about your work to realise how it could be made more interesting for you. So take charge: don’t go to your manager with problems, go to them with solutions. And do yourself a favour; don’t couch your solution in terms of how it will make your life better, say how it will benefit the company (increased security/stability/profits are all good).
But these posts were meant to be pointing managers to what they should do. So how can a manager decrease the angriness of CODE-IT staff by making their work more interesting? Listening is a good first step. Encourage your underlings to explain their issues to you, then find a way to turn these issues to your mutual benefit. Higher up the food chain, your focus should be on strategy rather than the nuts and bolts. Focus on your strengths (see how positive I’m being? Assuming managers have strengths!) and ask your CODE-IT legions how their nuts-and-bolts expertise can help deliver on the big-picture strategy. And just to repeat: LISTEN TO WHAT THEY SAY!
There are two absolutely poisonous things a manager can do in this scenario: (1) be two faced – ask for input with no intention of acting on it (2) come up with some totally inappropriate forced “fun” to make work more “enjoyable”.
On point one, you are far better off never engaging with CODE-IT workers on this topic than getting them to come forward with suggestion that you intend to ignore. You may gleefully assume you have come up with a cunning way to appease their whining by making them think you are their friend or are listening to them. They will see straight through this and know you are a lying sack of shit.
On point two, you can’t force something to be fun. Forcing staff to go off on some “team-building” exercise can have two disastrous effects; one, if they really don’t want to spend time outside the office with cow-orkers you’ll just make them more resentful and anti-social. Two, if they actually have fun doing something that’s totally unrelated to work you run the risk of simply highlighting how far away from fun work actually is.
Keep your motivational efforts focused on work. Encourage people to socialise by all means but don’t force it. If your CODE-IT workers want to spend more time together, they’ll do it without being forced. Also, social events have nothing to do with making the actual work more interesting. Enjoyable social events are part of the overall workplace environment as discussed in previous posts. This is linked to but distinct from interesting, challenging and enjoyable work.
The important thing is to make decisions based on your individual business and staff needs. Don’t make sweeping generalisations about what work your CODE-IT staff will enjoy, engage them in the process. The high-flying, fast paced world of dot-coms/Web2.0/whatever the hell is coming next is not for everybody. Some people are absolutely terrified by that sort of thing. Including some of the best CODE-IT staff you may ever be lucky enough to find. Not everybody who maintains mainframes is forced to – some people positively thrive on it. Do your best to match the strengths of your staff to your business needs and you’ll maximise both staff satisfaction and productivity.
Remember that; with CODE-IT workers (and almost everybody else), happiness and productivity almost always go hand in hand. I’ve worked for managers who clearly thrived on having angry underlings – if the staff were happy they must be getting away with something. Any sort of decent human should want their staff to be as satisfied as possible in their work while meeting business needs. That’s somewhat intangible, but increased productivity – that you can explain at board meetings.
Angry 365 Days a Year 
Good follow-up. Job satisfaction. In IT. Was I ever satisfied or fulfilled whilst working in IT. I probably was. In my post, there was a lot of research that I found quite stimulating. However, there was a lot of grunt work too.
‘Forcing staff to go off on some “team-building” exercise can have two disastrous effects; one, if they really don’t want to spend time outside the office with cow-orkers you’ll just make them more resentful and anti-social.’
If someone FORCED me to do this…..they would be fucked in the neck with a policy and procedures manual. If I’m spending time with co-workers away from the job it won’t be at someone elses dictates. They DO NOT want to get in a pissing contest with me on this!
Range: I’m in IT for the money, if and when I enjoy it (my current job is pretty good) that’s a bonus. I’m in blogging for the love of it.
Sandra: I got a really bad performance review once for not going on a lunch with people I didn’t like. I quit not long after that 🙂
I was in IT because the money was great, managed about 10 co-workers. Did not have to done the work on less my boss was breeding down my neck.
One of the things that has made my life in IT much more enjoyable is releasing products more often, and working closer with customers — or at least someone who can act on behalf of the customer.
Releasing products more often is more enjoyable because it’s easier to hit more frequent deadlines, and there’s nothing better than going home at 5:00 on a Friday knowing you don’t have to worry about things over the weekend. Completing things makes it personally satisfying for me, even if they’re smaller things!
Interacting with a customer is what makes it personally valuable — getting a genuine smile from the person sponsoring a project is a real pay off. Likewise, if it doesn’t go so well, it’s far more motivating to fix the situation. Of course, this depends entirely on establishing a good rapport … and sometimes that just isn’t possible.
Good article. Thanks!
mdtcs: it’s good when you have control over your own destiny
Peat: that’s a good approach – engaging with customers. Too many IT people isolate themselves completely
Your post spikes a nasty memorie from a few years ago…
I’ve been in IT my entire career so I know exactly where you’re coming from Mr Angry. I once joined a young startup company as employee number three. I had an interesting three years with those guys as we expanded from 3 to 20 employees. The atmosphere became increasingly nasty though and I started to dislike it.
Naturally, I was near the top of the pecking order as I’d overseen other developers coming into the company, interviewing employees etc.
Increasing I saw the real side of the management as I grew closer to them. The final straw for me was when the chief of the company came to me and said “I see the developers on your project are looking relaxed”. Uh huh, that’s my aim, the project is hitting it’s deadlines and my guys are happy too. “I’m not really comfortable with having relaxed employees, they should be working weekends”. I was speechless.
I left the country a few weeks later, that’s how shitty I felt finding out the truth. I worked my arse off in the first two years working crazy hours with unpaid overtime. And then to hear how the mangement really felt was too much.
Now I’m working in a completely different environment and I’m waking up every morning excited about what I’m going to do that day. I haven’t had that with many jobs in my life. But it is possible people, really, don’t stand for the bullshit – life is too short.
Paul: you did exactly the right thing. You were working for some deeply wrong people and it would have destroyed your soul if you stayed there. Wanting to stress staff out who are doing well simply because you don’t want to see them relaxed? How fucked up is that?
Very fucked up.
I’m still in contact with some of the guys that work there and they hate the place. The management swings a carrot ocasionally to keep them on board, but damn, I’m so glad I got out when I did.
I find that some types of work dehumanize you, change you and drain you in ways that you cannot fathom until you leave it again.
Paul: you gotta preserve your soul in those situations
Range: sometimes more than you realise until you get out. I still can’t believe how well I’m treated in my current job after being treated so badly in so many others.
Update: Some of the best guys at my previous employers have recently handed in their notice – I’m far from surprised.
Paul: yeah, I’ve had those experiences, counting down the list of former co-workers who eventually go some where better.
We recently had a team building exercise at Strategic Airsoft Command. It made the IT staff happy that they were able to shoot at each other to let off steam.
I think I saw that in an episode of some british sitcom (Drop the dead donkey?) – the end result was some extreme violence. From the quietest people.
“Interesting work” is an interesting issue, beautiful in its divisiveness, both generational and by mindset and biases.
A first point: I think that most managers who assign boring work know they are doing it and don’t really care. This is not because they are malevolent. Rather, it’s because they are shitty managers, and bad managers tend to find their work uninspiring and have become resigned to the idea of “work” consisting of a gauntlet of idiotic, mildly unpleasant rituals. It’s normal to them for work to be boring, and natural that it should be so for everyone else.
Then, in a separate but intersecting class, there are the dinosaurs who suffered when they were young (since “interesting work” wasn’t a legitimate employee demand before the ’80s) and have an axe to grind. I don’t think anything can be done about them, other than to leave them to sit on their hands and wonder why they can’t get smart people.
For the more moderate managers, who might be sympathetic to the issue if they understood it better, there are some points that should be laid out before discussion begins:
1. Detail-oriented != Grunt work. A lot of managers see themselves as “big picture” types and detail-oriented work, by necessity, as grunt work. Thus to them, programming, which is inescapably detail-oriented, must be grunt work, and therefore, all coding tasks are equivalent in terms of interestingness, hence there’s no need for any effort in this direction. This is analogous to the “all languages are the same” paradigm of what Paul Graham calls the “pointy-haired boss”.
In fact, most of the top analysts/programmers don’t find their work to be “grunt work” and find this approach extremely offensive; it becomes patronizing. (“You like computers, right? So do X. It involves computers.”) No one likes to have his work turned into a commodity. I believe that most of the IT/tech-disgruntlement comes from the empty suits’ tendency (out of intellectual insecurity) to commodify IT/programming/analysis.
2. Most people expect to do some grunt work, so it’s not a problem if 10 hours of an employee’s week are spent on grunt work. It’s a problem if 30, or 50, hours of his week are spent on it. When people begin to sense that they are being used as mules, they fight back.
With all this talk of “high-flying Web 2.0 entrepreneurs” who don’t want to do the grunt work, the point is being neglected that launching a startup itself involves a lot of grunt work– much much more than one would do at a first-rate established company like Google. The difference is that people in startups are managing sewers of cities they built, which most people find tolerable. But a person who is made to run three peoples’ sewers, never allowed above ground, will leave immediately.
3. The “suck it up” attitude really doesn’t help, especially in a world where it’s easier than ever before to automate or away the grunt work. Bartleby’s great-grandchildren aren’t scriveners.
Mr. Angry: You’re right-on on your point with: “Not everybody who maintains mainframes is forced to – some people positively thrive on it.” I know a few people in a company that had some severe grunt-work problems, leading to 8-month average analyst turnover. In my opinion, much of grunt work can be eliminated in, say, a client-oriented consulting firm with a three-prong approach.
1. Be more selective about work taken from clients. A lot of companies out there use consultancies as back offices, and a consultancy that adopts the “take all work unconditionally” strategy is going to find itself in trouble. This is a quick way to get buried in data-mangling. Saying “no” to a client would be disastrous; it’s better to raise prices, and use the money earned to finance the next item, which is hiring…
2. Hire appropriately. “Grunt work” = work no one wants to do. So the obvious solution is to hire people hire people who would enjoy that work, reducing the supply of work that cannot be assigned without hurting morale. The problem here is that many companies want to conceive of themselves as being elite, highly selective firms, which prevents them from hiring at an appropriate level. In fact, many firms want to “have their cake and eat it too”– they hire a smart person to do mostly grunt work because, when something challenging does emerge, that extra kick becomes useful. Of course, this leads to resentment and turnover. Root problem: some firms want to be strictly elite/selective in the people they hire, but they can’t do this if their work is not (mostly) elite.
3. Automate. This is particularly relevant to tech. Chances are, the people complaining about the repetitive grunt work are smart enough to automate it, given the right tools. There are two obstacles here. First, the company might not listen to the tech peoples’ demands for better tools, in which case automation is not possible. Second, automation is essentially a form of R&D, which requires creating a sort of Brahmin caste and protecting it from the day-to-day. This is often not politcially feasible, which is unfortunate, because it would save everyone lots of time if they could get over the perceived favoritism.