There is no “skills shortage”
Allow me to share a discussion I started on Linked-In’s “Getting IT Right” group.
—
The recruiting industry has created a wonderfully self-serving “skills shortage” – perhaps in much the same way that the financial industry was able to create its own bubble.
There aren’t enough square pegs for all the square holes, yet we are sitting on mountains of round, triangular and hexagonal pegs of all colours and sizes, all desperate for a chance!
There’s talented people everywhere, but you have to be a bit open minded, and you have to be prepared to take a rough diamond and shape it yourself. It is myopic and lazy to sit back and wait for the perfectly qualified candidate to be presented to you.
There is a widespread assumption that a recognised certification in a particular discipline equates to a competency in that discipline, and if we simply find the candidates with skills X and Y they will likely be able to do the job that requires skills X and Y. How simple recruiting is, right?
I think that assumption is grossly naive, and leads to good job candidates being overlooked every day, to the detriment of the company and the nation as a whole. I would suggest there is not so much an IT skills shortage, but a chronic lack of people able to spot talent if it walked right past them.
Recruiters with no in depth knowledge of an industry (most of them) will add no value above CV keyword filtering software. How can they be expected to? (BTW, anyone who thinks IT is one industry, doesn’t understand the IT industry – IT probably has more specialised niches and roles than medicine).
Certifications are just one indicator that an individual may have a competency in a given field. Certifications typically rely on exams, and exam questions are crammed and memorised then recited. The certification then only proves that someone has a good memory and general literacy in the field, useful, but memory is a skill that is becoming less and less critical in a searchable online IT world where information in the form of facts can be found quickly and easily.
There are far more powerful indicators of competency. If you are interviewing someone who claims to have a knowledge in a particular field, and you (the interviewer) are experienced in that field, you should be able to spot a fake in 3 questions or less. If you cannot, you add no value to the process, and you should not be interviewing. It is even possible in zero questions, just get them talking about their experiences in their field, or their areas of interest in their field if they lack experience. If they know nothing about the field, let them talk about their other life experiences, how they teach themselves new things, what motivates them, why you should employ them, and so on.
You will quickly gauge their enthusiasm, the depth of their understanding, and their approach to life. Do they recite conventional, textbook answers to common problems or do they think for themselves? Can they provide multiple solutions and ideas to solving a problem, or are they trying to simply give you the answer they think you want? Ask open questions, given them no clue as to the expected answer (indeed have no expected answer) and just let them go for it.
This means that wading though CV’s just got a whole lot harder right? Perhaps, but if you can spot a fake vs someone worth talking to, then you can cut an interview down to 5 minutes or less for the unsuitable, and longer for the more suitable candidates.
Complaining about a skills shortage is like complaining about the weather – our energy might be better directed to working around it – in other words play the hand you’re dealt, search harder for talent, be open minded about what talent might look like, be prepared to help create talent, and be prepared to invest more time in the search for talent.
Perhaps the mistake many employers may make in the recruiting process is to approach the market with a desperate need to fill a hole, coupled with an arbitrary set of required attributes (pay range, certifications, experience level etc.). These attributes are often nothing more than a wish list.
When they find it hard to fill the position, they blame it on the “skills shortage”, and everyone nods in sober agreement, perhaps throwing in that the government needs to “do something about it”.
Knowledge workers are becoming increasingly specialised. In addition to a vast array of niche specialist technology roles, functional roles, vertical market specialisations, and technology product specialisations, there are vastly different levels of experience. Thats not even considering the range of personalities, and the impact that has on the suitability of a candidate to a role. Then you have to throw in that NZ is a very small market – some skillsets are held by only a handful of people in the entire country.
The result is that every knowledge worker is different, and the dated concept of one “resource” being a substitute for another, as if knowledge workers are some kind of high-tech labourer, is very 20th century.
Employers could instead take on keen apprentices and put them alongside their more experienced staff. When that is done right, there’s a kind of magic that happens when skills rub off, often at an astonishing rate. By having a range of experience levels on a team, from apprentice to senior, the employer should have options to promote from within. Then they’d have the option of hiring a new apprentice when a senior member moves on, and moving everyone in between up a notch.
SOAP vs REST
I posted an answer to the following question on StackOverflow today, and I thought I’d publish it here too.
Q: “After reading many tutorials (which seems contradictory to each other) on REST based web services, I was wondering whether we can/should use SOAP to send/receive messages in REST based web services ?”
A:
SOAP is an XML based messaging format for exchange of data. Soap also defines a means for making remote procedure calls. SOAP is an open standard from the W3C. SOAP is agnostic about the underlying transport layer. Frequently HTTP is used as a transport layer, but it can happily run over SMTP and TCP, and other transports too.
REST is an architectural style (not a standard), so be careful not to compare REST and SOAP directly because you are not comparing apples with apples. REST takes HTTP and uses it is the way it was meant to be used, with all its subtleties and richness. The REST architectural style can used to transfer data in any format – it does not mandate any particular data format. So SOAP is a perfectly good serialization format for a REST style web service. But many people use JSON, XML, plain text and many other formats with REST. You can happily exchange binary data over REST too, like image files. The nice thing is you get to choose the data format that makes most sense for your application.
Note that since REST is a pattern, not a standard, there is a lot of debate about what it means to be truely RESTful. There is a concept called the Richardson Maturity Model which lays out a series of steps towards the REST ideal. By comparing with Richardson’s model we can see exactly how RESTful a particular REST implementation is. WS-I BP web services are at Level 0 on this scale (ie. not very RESTful at all, just using HTTP as a dumb transport layer).
I would say this about choosing REST vs WSI-BP web services – it depends on your audience. If you are developing a B2B type interface within an enterprise, it is more common to see WSI-BP web services. Because there is an underlying standard, and because of the mature support by enterprise vendors (such as IBM, Oracle, SAP, Microsoft) and because of the level of framework support particularly in .NET and Java, WSI-BP makes a lot of sense when you need to get something going quickly and you want to make it easy for clients to connect in an enterprise environment, and the data being exchanged is business data that serializes nicely as SOAP.
On the other hand if you are exposing web services to the wider web audience, I would say there has been a trend away from WSI-BP and towards the RESTful style. Because REST only assumes the client supports HTTP, it can be made to interoperate with the widest possible audience. REST also gives you the scalability of the web itself, with the support for caching of resources etc which makes it will scale up to a large audience much better than WSI-BP web services.
The Intranet Landing Page IS the Intranet!
The landing page is going to leap out at every staff member every time they open their web browser. When staff members talk about “The Intranet” they are talking less about all those documents, applications, training materials and forms, and more about the home page.
That’s why the landing page really counts. You already have the documents, applications, training materials and forms – the trouble is finding and accessing them. The landing page is like Google is to the web – a veneer over the top of all this that will make or break it. The landing page is THE page that everyone comes too. It should be the most dynamic page on the whole Intranet, updated frequently with the most important information, and nothing more.
The Intranet is a strange beast – its kind of like your own private Internet, but with lot of strange quirks, such as legacy technologies, security paranoia, and corporate politics thrown in for good measure. The key to a making good Intranet for your organization is to forget all of these things, and just make your Intranet fast, friendly and have people want to use it, not because they are required to, but simply because its the best way to find the information they need.
I wanted to share some thoughts on the subject of the corporate Intranet, so I have published a lightweight whitepaper to help organizations to focus on what really matters when building an Intranet. There’s less than 4 pages of reading, so I encourage you to have a look and leave your thoughts in a comment here.
Read it here: The Intranet Landing Page