By Naked CIO, 20 April 2009 08:00
COMMENT
When hiring, remember to focus on finding the necessary skills - no more, no less - to fit the job, says the Naked CIO.
For a while now I have been looking for a job. This means I've been doing lots of networking as well as applying for jobs, and discussing job opportunities with many people.
For each job I have been lacking something - an application, industry, business focus - that means I don't have the 'required' experience to be properly considered.
It is OK - I have thick skin and am being patient. However, with technology being such a diverse vocation is it possible to find someone who checks all the boxes? Is it even recommended?
Many organisations looking for senior IT people are doing so because they need someone to fix failed projects and programmes - and boost credibility.
Someone once told me, 'If you always do what you always did you will always get what you always got'.
That makes a certain amount of sense. As for me I have always been a generalist. My education is in business - not computer science - and my experience is more about strategy and leadership than hands-on technical work.
So when a strategic and leadership opportunity is presented I get excited - but then get let down when the job requires technical knowledge that seems at least on paper to be somewhat inconsistent with the role the company is looking for.
In one of my more recent roles I spent a lot of time working with application developers to improve the credibility, transparency and effectiveness of their operations. I have never coded nor could I probably read a single line of code. In fact, the whole science of application development technology is something that truly confounds me.
Yet my job was to improve the way in which things were done, streamlining processes, enhancing development methodology, achieving better results from applications and understanding what the business requires. All these things I did well.
If the job description required that I had previous development experience I would be woefully rejected - yet I was obviously capable of the task.
When looking for people to fill senior IT roles, be careful to concentrate only on aspects of the job that are relevant to what you are asking someone to do. Be careful not to require too many technical skills for non-technical positions - and for that matter too many management skills for technical positions.
Part of the failing of technology within business organisations today is the gap between what organisations need to effectively fill positions and what they say they require. This gap leads to getting the wrong skills in key positions.
I have seen this in almost every company I have worked in - and have been responsible for making changes in many positions as a result. Technical brilliance does not necessarily translate into leadership capability - nor does it need to. The mindset of a technician is often at odds with the key aspects of leading and managing people. And that is fine, as long as the individual's job remains technical.
When searching for staff, ask yourself, 'What do I need this job to do?' Then look for someone with the skills and capabilities that will drive that function, instead of looking for an all-rounder who won't be happy in that role anyway. It will help you find the right person - and improve the effectiveness of your organisation.
Comments
There are 5 comments. Join the discussion
1. Graeme Teesdale
Lucidity in form and reality in motion. Excellent post from a significant hire. I too cannot condone the overtly necessary drive for the perfect document match. Effective recruiting is more important and more efficient, alas, our current environment is risk averse, thus, document managers will be recruiting. An opportunity to focus on capabilities, human capital and personal growth exists.
2. Jack Carter
Graeme, I am not quite sure what language you are speaking!
Personally, I find it very frustrating when my CIO gets involved in the minutia - individual incidents and projects. This is surely not the role is all about?
Don't CIOs/Directors usually have a team of managers to look after day-to-day issues.
Jack
3. Mike Tonkiss
That person who made the quote "if you always do....) was David Taylor and I strongly recommend his book the Naked Leader a coaching book that leaves the american versions (Covey Robbins & Co) languishing in their over hyped dust!
4. Martin Walker
I have suffered the same prejudice albeit in a slightly different industry. Fundamentally, the problem is that most recruitment agencies are lazy. If your job title does not match the spec then you are passed over whether you are capable of doing the job or not. There are only a small number of recruitment agencies that will take the time to understand all of your experience and transferable skills and then make the leap of faith to put you forward for a job you effectively have done already and know you can do well but that isn't reflected in your current pidgeon-hole of a job title. You don't necessarily need to be able to write or even read lines of code to be able to manage a team of software developers or IT support techs effectively.
5. Joe Whitehead
"In fact, the whole science of application development technology is something that truly confounds me."
Wait, development is a... science? I was under the impression that it was more like engineering or art. More art and less science, that is. If it was a science, then any idiot could follow a rote guide - although many try anyways. It takes a lot of experience to design software that's easier to program and update, and not just put out some code that barely works ('it runs'). Code that 'just runs' often doesn't do so for long and is very expensive to change. No, not bug hunting and fixes - just adding highly demanded features! Of course, it's possible to overdesign code and never finish a working product... Sigh no way to get all you want.
It's highly tempting to get a working example out to prove the concept, but then it costs a lot more money to get the product out the door if you don't (only) use that example's source code to get ideas on how to design a less costly product that works better and is worth more to the 'black ink' department. It really is aweful to have to do this after you've wasted months finding out that the original program is now unworkable for future profits and you have budgets and deadlines that prevent designing a replacement.