To Be Certified – Or Not?

Recently in the LinkedIn group “Agile”, Alan Moran posted a question, “How valuable is agile certification to you?”

The general consensus seemed to be that certification was helpful in terms of getting a job. For example, Nicolas Umiastowski wrote,

“Certifications are important to prove your skills to recruiters.”

Joseph Percivall wrote,

“I found it to be very valuable to set me apart from other applicants in my job/internship search. It was a talking point in every interview I had. It showed that I wanted to learn more about my field and thrive in it.”

The last sentence is interesting: it implies that certification demonstrates a level of seriousness about one’s work. Indeed, in a recent interview of Elena Yatzeck by this journal, she said, “Cert speaks to the person’s interest in their seriousness in pursuing agile techniques as a professional.”

The primary dissenting view was that certification is a lowest common denominator of knowledge. For example, Paul Oldfield wrote,

“I'm of the opinion that certification is only of value to mediocre people and mediocre organizations. Good people and organizations find each other without help, the really dire of each cannot be helped by certificates.”

Abhijeet Nikte wrote,

“I find it disconcerting that while a bunch of us are talking about the certification and its value, we seem to be in minority, or so I think. I firmly believe that (demonstrable) knowledge is far more important than a certification. However, there are tons of companies out there that place a very high value on certification. There is an (incorrect, in my mind) assumption that if a person is certified so that person must have knowledge. Sad, but true.”

What do CIOs think?

Interestingly, recently there was also a discussion about this topic in the LinkedIn group “Chief Information Officer (CIO) Network”. The discussion was about the IT skills gap, and it generated many posts on the topic of certification. For example, Greg Scott, CTO of InfraSupport, posted this – it’s long, but it is so powerful that I will repeat the entire thing here:

Consider these two hypothetical job descriptions for the same position:

Description #1:

We need an IT resource to finish implementing our ERP system. Skills required: C++, Java, PHP, and excellent communication skills.

Description #2 - same position, same job, same company

We need a motivated individual to finish our partially completed ERP system. Take the bull by the horns, finish building this system, set up a mechanism for ongoing support, and help us transform our company. The system uses C++, Java, and PHP and developers who know their way around these tools will have an advantage. But developers with a demonstrable track record of constant learning will have an even bigger advantage. If you want to take on a challenge and help us transform our company, we want to talk to you.

If you're an IT pro and looking for a job, which one would you go after?

I propose all hiring managers, all HR departments, and everyone everywhere eliminate the word, "resource" when referring to IT professionals. Your doctor is not a resource. Your accountant is not a resource. Your attorney is not a resource. Why are the people on your IT team resources?

Eliminate this word and begin to change your attitude. Change your attitude towards the people on your IT team and you'll begin fostering that culture of constant learning everyone talks about. Begin to change your attitude about your IT team and the people on your IT team will begin to change their attitude about your company.

Have the guts to do this and the skills gap at your company will go away while everyone else tries to figure out your secret. The counter-intuitive result will be, you'll probably make more money than your competition and leave them behind to eat your dust.

The core opinion expressed in this post seems to be that IT people should not be treated as interchangeable “resources”, and that evaluating people based on which certifications they have contributes to that commoditization. Scott seems to contend that “a demonstrable track record of constant learning” if far more important.

Here is another insightful post by Alexander Freund, President & CIO of 4IT Inc.:

Over the course of the past 10 years, I have hired for many IT positions including L1 and L2 support, project engineering, project management, service management, technical sales, and network and server engineering positions. What I have learned is that IT skills (competence in a specific product or area of knowledge) is generally far less valuable than what I call employee skills. We try very hard not to emergency hire to fill a spot, so immediate impact to our team is generally not the goal. So, what are the employee skills I am referring to? For me, there are really only three:

1. Brain power - The person needs to have enough raw brain power to learn and do the job. We readily accept that not everyone has the capacity to be a particle physicist, but continue to believe that we can train anyone to do almost any function in IT. Our experience is this is simply not the case. Find people that can learn, and teach them how to do the job. Even if they come with experience from another firm, they have never seen our processes and work culture.

2. Work Ethic - Work ethic is the true measure of the impact that any employee will eventually make to the TEAM. I consider this to be the skills gap that I encounter the most, and one which in general, can never be fixed.

3. Team player - When I consider the workload faced by most IT departments, it's clear that only cooperative teams working well together can get the work done on time without costly mistakes. Lone wolves, whiners, and poorly behaved team members are just too costly.

This post is again stressing the importance of soft skills – what Freund calls “employee skills” – over acronym skills.

Tim Magnus, an IT consultant, then says,

We have not established a yard stick or even definitions for the foundational skills. When job descriptions focus on transient skills [such as specific languages, tools, and frameworks], we make IT people into transient resources and so we will continue to search for people and fail to find the correct people to do the job. Foundational skills and fundamental problem solving skills are developed and are not picked up overnight.

I will say that these sentiments echo my own feelings and experience. When I was a CTO, Java was in its heyday. When I interviewed technical people for a job, I did not care what Java certifications they had. What I wanted to know what whether they were problem solvers, and if they were smart. Indeed, I myself did not have any Java certifications, but my book Advanced Java Development was a recommended text for those studying for the Java Architect certification. Would it not have been ironic if I myself had interviewed for a job as a Java architect, and had been turned down because I did not have Java Architect certification?

I personally feel the same way about Agile certifications: that’s why I myself don’t have any. My own feeling is that if someone wants me to be certified in an Agile methodology, then they themselves don’t understand Agile well enough to discern my level of experience with Agile and therefore I don’t want to work for them. That’s my opinion though: I am certainly serious about my work, so the lack of certification does not indicate lack of seriousness.

Many people clearly find that certification helps them to focus their learning in their career. As far as focus goes, I shy away from certification because I do not want to be focused: I want to retain the right to think for myself, rather than endorse the opinions that are demanded by a certification. There was one certification that I once considered obtaining: CISSP. I had just written a 600 page book on application security. While taking a practice exam, I discovered that I disagreed with many of the “answers”. In order to pass the exam, I would have to adopt perspectives that I did not agree with. I stopped studying for the exam and decided not to pursue the certification.

It is also clear that certification is useful for getting a job for many people: that is possibly because HR departments are failing to find the people who have the “natural learner” or “employee” or “foundational” skills that many of the posters to the CIO Network think are much more crucial. It is easy for HR to scan for buzzwords such as CSM than to try to understand someone’s background. That means that if you are hiring for Agile skills, you can’t rely on HR: you need to get involved in the search, and make sure that the best people are not being screened out because they don’t have a checkbox checked.