Discussion on:

10 IT job roles that are hardest to fill

I can relate to that position, oh so well. Did it for almost twenty years for small proprietary software companies. What made the position so effective was that I was also the primary person to test the new software as it was being developed. This was the perfect position to get to fully understand the software and how it works. There is no substitute for being able to know and experience what you are describing for new people.

Specialized programmers are rare, but so are the jobs. Positions are hard to fill primarily because they require long term commitment from both, programmer and his employer. And that's a big no no nowadays.

You need to groom internal candidates to meet your needs--this will require you to view employees as long-term "investments" rather than pesky "costs" to be minimized. They're a resource that's hard to find, so if you want one you'll have to grow your own.

This used to be something that was standard. The corps forgot how to do this about 2 decades ago. I can't point to what it was that caused the change, I was only barely entering the 'corporate' workforce at the time. Maybe it was when 'Human Resources' became a distinct group, as opposed to 'Personnel', and the general employee stopped mattering.

I figure it came about when bean counters -- financial professionals -- started running companies. They have focused so narrowly on "the bottom line" that they neglect to provide for the future of their company.

Companies introducing innovative products (outside finance) are rarely run by people with a background in finance. Financial professionals are lauded for their attention to costs, but by and large they threw out long-term R&D programs, training programs, apprenticeships etc. etc. ad nauseum for not directly contributing to the bottom line.

In the great old days when things we use were actually MADE in USA, companies were generally run by engineers, designers, or occasionally marketers. Financial professionals were limited to accounting departments.

Do you blame management for not thinking long-term? The average life-span of a C-level or manager is less than five years. That kind of environment breeds low-risk hiring and a lot of decisions with a short-term outlook. This way the MBAs can bolster their resumes with how they saved "X amount" and then they move on to the next short-term position.

And, all the follow-up comments. You guys have just described the problem with the declining western economies as a whole. It's not even industry driven, it's systemic and applicable to infrastructure/personnel, private and public sector.

I have had trouble creating an effective management resume. Although I have been in management for 5 years, I was never in a position that included saving X dollars (in a big way that is). What stood out in your post was you pointing out that it is short-term positions that provide that resume boost. I need to start pointing out that I served a different management role that did not include the opportunity to "save money." (I am talking about an amount of money worthy of appearing on a resume.)

The only problem with your explanation is that it isn't true. I can remember back in the '80s being associated with companies that routinely rotated accountants, engineers and marketing people as the CEO. Each brought a style to the job that the company required.

In most of the companies I have worked with, the discipline of a CEO during an outsourcing fad (aka cost cutting) was irrelevant. If anything, the accountants tended to shoot the idea down as not really saving money.

Personal opinion is that it has more to do with pressure to perform today, pressure to please the analysts and the desire for a quick fix.

That's an interesting difference in experience. Every private firm where I've worked had one of the founders at the helm for and extended period. The ones who handed off the reins to bean counters tended to fall apart soon after.

The exception was government where there was lots of turn-over even amongst the locked-in civil service managers.

Is that there are a large number of IT-groups in companies, that are placed under the 'bean counters' control. And needless to say, the bean counters usually are NOT the most tech-savvy types, if they are at all. Not who I want in control of the group.

Some of it was changes in tax laws and regs beginning in the late 1970s, a lot of it has been a shift in what they've been teaching in the B-schools, the hatching of the H-1B visa in 1990, and then there was the shift from super-computers and mainframes to micro-computers (which took from 1975 to the late 1990s in many outfits) and the shift from structured to OO design and programming (which started in the 1960s but didn't pick up steam until the 1980s and wasn't generally in use on the job until nearly 2000). But those forces have created a feed-back loop pushing more and more abuse of production employees, less and less investment in employees in the forms of respect, compensation, training, relo and interview expenses... with dashes of hyper-credentialism, grade inflation, and age discrimination thrown in.

The general sense I have of this thread is you're describing the contributors to "corporate dysfunction." I'm not going to jump on you because I'm some OO zealot, but I'm curious, how did OO design and programming contribute to this, as opposed to structured programming?

Everyone wants the "perfect" candidate, but they don't realize that this person can't be hired, but rather developed. What companies need is a framework for the "perfect" employee--someone who has the potential to be this--and then make hiring decisions based on that framework. A capable IT employee can become half of what you need within 6 months to a year.

However, managers are so skittish and risk-averse that they want "safe" candidates. If you want safe, hire a robot and the extended warranty plan.

"4: Help desk staff"
So people aren't willing to work for the salary you are offering.
Offer more money.

"Most companies see the help desk as a necessary evil, a cost center to be contained. And in a way, they are right. With razor thin margins in many industries, the cost of support can make or break the profitability of a company."
Yet there is always plenty of money available for management bonuses.

"law of supply and demand" and all, but your followup paragraph at the end seems to make a far more poignant point...

What is the True Cost of Help Desk Staff? When you factor in the lost production of users whom spend hours creating work arounds because the thought of contacting Support is more of a pain this can cost compainies thousands per user. Not to mention what one error could cost if left un checked. Help Desk support is a multiple of IT Jobs and requires an understanding of All Departments in the Company. With all that a company spends on it's IT Department Help Desk is the First Line of Denfense against angry users. Choosing and Paying the Right Person can mean the difference between Paying a User Hours of time in lost production. Makes sense that your help desk employee should be both knowledge able and personable. It is infact your Director of First Impressions for new users and a place of peace for those whom have been with the company for years. Want to save Money on Help Desk support then stop the Fuzzy Economic's and look at the true cost of lost productivity. It only takes a moment to realize happy employee's are productive employee's. And no one likes to be under valued.

Yes, it's funny how the lowest paid people are responsible for the profits.

Ask the army of highly paid bean counters - they'll tell you how the three helpdesk employees are bankrupting the company. But they have a cure, which is hiring a few more bean counters to look into the problem.

True. An old good management practice was to call your company and act as a client to see what happens. Now it should be call call technical support and see what happens. Two weeks ago I spent two days with my ISP's support trying people trying to convince them my cable modem was "flapping" (going offline and trying to reconnect to the headend) and there was a problem with the modem or the cable. They could not and would not acknowledge the problem and repeated the montra "turn it off and restart the modem" and "it seems OK now". I canceled a big upgrade due to that experience. If they can't provide basic internet service without seeming like idiots why would I order complex services?

At the same time I was changing my phone service provider. They somehow, instead of simply switching my service, disconnected my telephone completely, twice. When I argued that the service had been cut at the computer and the line is live with 50 volts at the terminals (I used to install low voltage lines) the technical support people simply said they will send a man out in a week. After eight hours of arguing someone finally checked and I got a call from a field lineman who said: "Yup, someone cut the connection. I fixed it in 4 seconds." Again, I am not buying more than basic phone service if they can barely do that.

Oh, my cell phone is the only thing that worked during this mess and is how I cleared it up. Viva competition.

I have to agree - sadly Management typically earn the bonuses by reducing the 'costs', i.e. salaries, of the talent beneath them. That is something that management feel comfortable with, as they can quantify it, set targets against it, and most are capable of little else these days.

Then, having commoditised IT, they were the first to look offshore for the next cheapest 'talent'. Again, easy to quantify (too stupid or inexperienced to factor in additional costs).

Now, there is a diminishing pool of people left to fill the positions they really need, with the expertise and commitment to fulfill the role properly and make a company successful, because they have systematically destroyed any incentive to do such a job, created job insecurity, and actively sought to undermine the locally available workforce.

The only shortage that ever existed in the West, was that of capable managers.

"The only shortage that ever existed in the West, was that of capable managers."
I'd also add honest.

were all those where competence was mandatory.

IT in business has made a point of dumbing down all disciplines to produce a fallacious abundance and reduce costs. Hard to fill is a symptom...

Amen Tony!. I've noticed and commented before on what I've observed, that there has been a long trend, over decades, to reduce every skill set to a commodity, making superficial compliance with standards and best practices a substitute for thinking.

and his absurd argument that IT should be treated and managed like railroads or commodities instead of like an integral part of every business.

which is also a symptom of the them and us, or even us and them syndrome prevalent in business.

The phrase "business/IT alignment" is simply suit code for "all you weird geeks have to act like us normal folks" and nothing more. We debunked this fallacious concept in our book "The Geek Gap: Why Business and Technology Professionals Don't Understand Each Other and Why They Need Each Other To Survive." If a business wants their suit and geek workers to communicate better and work more efficiently together, then they both must relearn or outright change a variety of bad habits. Get the book, it really can help. Or better yet, get the book and anonymously drop it on your bosses desk!
Check it out at www.geekgap.com
If you're told you just don't "get" alignment, then you're doing it right.

His analysis only applies to standard IT configurations (like e-mail), or solutions created by third parties. It works terribly for organizations whose IT requirements don't fit these scenarios. What business often misses is the advantage they'd gain from a custom in-house solution, not in the short-term, but in the long-term. It seems easy to buy off-the-shelf equipment and apply it to what they want *now*. It gets ungainly down the road as their requirements change.

Another big problem is the way custom development is expensed. Due to investor requirements, they often pay a lump sum, as a capital expense, for a "quick and dirty" implementation that works now, but ends up costing a lot more than it could have with a better design, with the maintenance expenses that come down the road, which is counted as a "cost of business."

IT is not seen as an opportunity to rework and reimagine a business model, as it should be. It used to be seen as a way of optimizing what they always used to do. Now it's "Just the way things are now." What it used to optimize is now just par for the course in business. Everybody's doing it in the same ways. This is Carr's point, but his assumption is that this is what IT is supposed to be. His analysis doesn't take into account the idea that if a business was reimagined in light of computing's potential (not just what's on offer now), this would reinvigorate IT's ability to create competitive advantage again. The thing is, for that to happen, we need the re-emergence of computer science as a thought-leading discipline. That's not where it is now.

Carr's major argument was that you can treat IT like a commodity. All of it. He likens it to the railroad and other infrastructure projects and says that IT should be implemented and managed just like them.

What he overlooks is the fact that business practice drives IT - not the other way around - and if you commoditize IT, you must also commoditize your business practices - eliminating any competitive advantage you may have sought there.

What Carr's approach totally forbids is innovation, because you can't commoditize or outsource innovation. Innovation happens when someone within a company looks to see how things could be done better. This inevitably means altering or completely re-writing those very business practices that Carr assumes to be static. Computer programs are nothing more than codified business practices: re-writing those practices also necessitates re-writing the software that supports them. And this means that whomever is re-writing the software has to understand the business process they are trying to emulate on the computer. You can't do that using commoditization.

I'm not so sure I agree with your contention that computer science isn't a "thought-leading discipline". It all comes back to the control of the business processes being in the hands of the decision-makers of the business. These aren't usually the IT guys who are charged with mimicking the processes in code. IMHO, THAT is the dynamic that needs to change: the IT department needs to be involved in strategic business decisions and process discussions so that they can help shape and understand the processes they are charged with implementing/maintaining.

I totally agree with your point about Carr, and that program code in the context of a business is nothing but codified business rules and processes.

I didn't mean to say that computer scientists should be leading the business, but I do think that CS as a discipline, or at the very least a modern software engineering, backed by computing as a scientific discipline, should be in a position to inform the business decision makers. As things have stood for decades, business practice and CS/SE have been separated by differing concerns. The suits go out and find investors and customers to finance the business, and the IT staff worry about creating a working product, funded by that financing, never the twain meeting on priorities. The suits don't know much about software (much less that it's codified business processes, etc. To them it's just about "making the box do what we want"), and the IT people don't know much about running a business. The two "sides" have different priorities, and even a different language (though they're both in English) for expressing what matters most.

Chris Crawford, a famous creator of video games, I thought put it very well in some essays he wrote years ago, that programmers have been put into the ancient role of scribes. They're the ones who come up with, and use, the script that records what the masters who finance their work need recorded and retrieved, like how much grain was sold, and to whom, and who owes whom money. What's getting lost is there is tremendous potential in writing...what we're doing right now. It was realized by the Greeks thousands of years ago that writing is so much more than a means for creating financial, and historical records, and edicts and proclamations. In order for this realization to flourish, they had to get rid of the role of scribes. The people who had the knowledge, who had the thoughts that needed to be written down, also had to know how to read and write. We haven't realized this with our new medium yet.

One major factor in this, at least in the line of work I was in, is that the end customers of the software were even more clueless about the process. Nothing against them, but this influenced everything about what the business did, and their lack of understanding tended to make the software a mess, because they had no sense of what software is. It's all magic to them, and we were the "magicians" that made it work. Their expectations set the tone for everything else. Going back to my historical context, in ancient times what scribes did, reading and writing, was considered magical, too.

When I worked in IT, one of the things I was very interested in was talking to the people who would actually use the software, so I could get a sense of why they wanted it. What purpose would it serve? I wanted this, because I hated getting a sheet of requirements telling me "implement this and that," and then hearing word back that, "You didn't do this right. They want this." I thought I did what they asked, but we had different unspoken assumptions. I figured that if I could get a sense of how what I was writing was useful to them--to get a context for it--then when I heard, "They want X," we would be on the same page about the assumptions, and I could just figure it out on my own. I got that opportunity on one job, and I think it worked out really well.

The missing element, though, was reconsidering the business in light of what computing can do. Every time what people wanted was something that would optimize their paper processes. I've always liked Alan Kay's conception of computing, that it's a new medium, and it enables new human capabilities, but bringing this out requires that the people who are making the business decisions, or in many cases, the customers, understand something about computing. The way it's been for decades is that most business people are just trying to automate paper, the old medium, because that's what they understand. To them, this is why computers exist, and I think this notion feeds into Carr's analysis. In the last decade we have successfully transferred all of our old media, print, photos, video, and audio, into "digital." We have been increasingly able to do it all using commodity tools. What's missing in the analysis is that computing is a new medium, which communicates a process in action, and that communication has value. It does not have to merely execute processes.

I personally would love it. Even if all they could do was write a simple "Hello, World" program or retrieve a few rows using an SQL query, I think it would go a long ways towards business executives' understanding of what IT entails. I myself hold both an undergrad in CIS but also an MBA with 15+ years in IT (and I'm looking for opportunities). I can speak both languages (when there's someone listening), and I can understand why it's so easy for the two not to see eye-to-eye. No one can be really good at everything (ESPECIALLY in IT), so we have to specialize. Unless you have at least cursory familiarity with both aspects, it does make it difficult to share ideas.

I agree with your point about computing being a new medium, and I think the main takeaway for any non-IT decision makers is that computers are the ultimate multi-tool for business. You just have to decide if the saw is better than the screwdriver, and if you don't know how to tell the two apart, you should probably get someone who can both identify the tools but also relate to how they can help solve particular problems.

I was reading a book by Jonathan Sacks a while back, and he pointed out that "hieroglyph" meant something akin to prestly symbols, that it was only with the development of a simpler alef-bet (which the Greeks eventually adopted as alphabet) that near universal literacy became a possibility.

Well, I guess machine language was more like priestly symbols, while 2nd and 3rd generation, and now SOME OO PLs, together with changes in apps to make them more user-configurable and scriptable are veerrryy gradually approaching the age where universal programming literacy can be a reasonable ideal.

"most business people are just trying to automate paper"

"Most business people" simply do not have a clue, and worse, they don't want one... or at least that's the impression I got from nursing along numerous B-school profs, grad and under-grad students, and interactions with those who came from B-schools. Instead of thought, when it comes to tech of all kinds (from mechanical engineering to computer hardware and software to nanotech) they operate in knee-jerk mode, as though they'd all just popped out of a Skinner box. Trying to lead them along by the Socratic method won't get you far, either; it requires too much savvy and too much knowledge just to begin.

Simply mention the letters I and B and M in sequence and they slaver all over as though you'd offered them an ice scream sundae with all the fixins, without the least clue about the advantages and disadvantages of various hardware and OS design features. As a matter of fact, many of them still seem to believe that those initials and computers are synonymous, as though there hadn't been numerous firms with much better hardware and software since at least the 1940s. Many of them don't know about those other systems, at all, and their profs never mention any such.

Your description of this role sounds familiar... I had a job like this over 10 years ago, and they were looking for a Jr. programmer who would "learn and grow into the job." They wanted somebody with enough skill to work with C++ and MFC. One person there told me that one reason some developers were leaving was they were already real good at the technology, and were bored with it.

I worked on adding features to existing applications, and fixing bugs. There was legacy stuff around, but I didn't work on it. They had had done a bunch of application rewrites, going from Delphi, and 16-bit Windows apps. written in C, to 32-bit MFC apps, or VB 6 w/ COM. I worked on one of the rewrite projects, but everything was purely 32-bit for me. Fortunately most of the software was recent enough that most of the people who wrote it were still around, and I could contact them. Everything we were working towards was considered current (though aging) technology at the time. It was just at the beginning of the shift in business apps. from GUI to web. A bunch of developers were leaving, taking Java/internet developer positions. That was the hot new thing.

I actually had a good time in the job. I was disappointed that it ended. The technology was on the way out, but I didn't know it. I think the truth was, though, that I wasn't around long enough to find out why people didn't think the place was such great shakes. There were a few people there who had been there a while, and expressed their frustrations with management. Some of them were the ones who left for "greener pastures." The fact that they complained didn't strike me as odd. I had heard developers complain about management for years, and it had nothing to do with working as a maintenance/legacy developer.

I had heard of web applications. I worked on a prototype for one in 1997. Most of them were being done in C++ and Perl, or VC++ or VB 6 with COM. Every time I heard how they were done, they sounded like a kludge, and I wanted nothing to do with them. It didn't sound cutting edge to me. It sounded like a mess.

I didn't see my role in the job I got as a "career killer." I guess for most people it would've been, given the circumstances at the time. The point where I got laid off, along with most of the people there, was right during the dot com bust. I went for a few years after that not able to find paying work in my field. That washed a lot of people out. The only way out for me was to work on web applications. So that's what I did for a couple years. Even after that experience, GUI development made more sense to me in terms of a coherent design concept. Working in ASP.Net didn't improve my perception of how web apps. were built.

Would not wages rise in return to attract the proper talent?

Or are wages low because any parrot can sit in the chair and squawk from its script?

mandatory time on the helpdesk. Yes there are some exceptions as to who might actually gain something from the experience. Hypnotoad: with all due respect, you sir, are NOT one of those exceptions. Furthermore your prevailing opinion of what the job is all about is one that infects others like wildfire and therein cultivates the very problem discussed here.
Yes I do believe 3 to 4 weeks on the helpdesk would give you a fresh perception of what the job entails. Until then, you may go ahead and call them lackeys, speak down your nose at them. The damage to your companies bottom line is far greater than the insult you saddle them with. Consider this, when was the last time you encountered anyone describing their experience with an outsourced helpdesk that was anything less than a miserably frustrating experience. I would bet dollars to donuts that Apple pays their call center technicians better than most. This is evident in their overall demeanor in dealing with customers. From experience I can tell you that the company that recognizes the helpdesk or call center as their front line of defense against unsatisfied customers will pay their help more and as a result will have far more skilled, considerate and patient hands handling the task. The companies' bottom line will improve.

I like doing helpdesk for my own software. It's nice to hear from the users.

But here in Asia, we cannot find good solution architects anywhere. Most are specialist engineers who have been artificially elevated to that title to fill these roles on complex projects, but are not capable of doing the job properly.

They get paid peanuts for what they do, pay them more money and you will find them, not to mention not being a repected position these days, people look down on you but if the money improves things will change!!!

WTF? Is "Product evangelist" even a profession or post? People who call themselves a "Product evangelist" already exclude themselves from the post just by using the phrase. I think that article has miss-labeled the position and meant something else.

Few companies and people in general have a benchmark for good quality IT trainer talent.

Speaking as someone very well qualified in IT Training (100's of global events & policy), project management (10yrs international large scale experience + PRINCE2), specialised programming (distributed computing & cloud), who is currently finding getting a new role difficult; I would say that the roles you mention are always claimed to be difficult to fill but that is generally because recruiters decide they want cheap, consequently unqualified, staff who will still provide a quality service.
Basically recruiters do not find these roles exciting and would rather spend their money on more techy/exciting roles, because that is what they enjoy themselves.

I don't know why you include this in the "hard to fill" category. The problem is not that people are hard to find, it's that the employers are not willing to pay for the expertise. Those of us with decades of experience, and who are most likely at the latter end of our careers are often willing and happy to find a slot working on legacy systems, but who also want to be paid commensurably with our experience, i.e. as "senior developers".

Thus, these roles are being filled, as you state, by juniors/graduates who initially have no idea what they are getting into, and leave as soon as they realise what they have got themselves into.

If the employers/clients change their miserly ways, they would easily find experienced and willing developers to fill their "empty" positions.

I am now at the tail end of my career (after 40 years in IT) doing maintenance on a legacy system for multiple financial institutions. This package has been maintained and modified for more than 20 years now (not by me) and has a very low error-rate, but the ones left really get your attention and makes the work interesting. I will stay with this until my late 60's (as long as I remember how to log in), I love it and am well paid. Legacy all the way!