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.

Why private offices are important for programmers

Around the year 2000, the company that I had co-founded in 1995, Digital Focus, went agile. We adopted eXtreme Programming (XP). We therefore had to undergo our own "agile transformation", to figure out how to adapt all of our processes and infrastructure to support this new way of working. One of the issues that we faced was how to arrange teams.

It is pretty standard nowadays that agile teams are co-located into a bullpen so that they can collaborate easily. A purportedly ideal setup includes lots of whiteboards and a wall for posting the agile stories and other information radiators. This is indeed a nice setup: it is cozy and one can hear conversations that are often relevant. And if you want to talk to someone, you simply stroll over to his or her desk and start talking.

But there is a deep down side to this. In such a setting, distractions are constant. You overhear conversations when you don't want to - often while you are trying to focus on a problem. It is kind of like being in a Starbucks: it is fun, but you will not do your best work there.

I have found that in such settings, people who really need to focus often go home for a day in order to crack a hard problem or to come up with a fresh approach. To really focus, one needs quiet and isolation - like one used to have with a private office.

During the mid 1980s I worked for two compiler development companies. In each case, the teams were co-located in that everyone had an office on the same floor of a small building. Thus, if you wanted to talk to someone, you simply strolled over to their door: and if the door was open, you walked in and started talking. But if the door was closed, you knew that they were trying to focus (or were talking on the phone), and you went back to your desk and tried a little later, or perhaps shot them an email saying that you need to chat.

The disadvantage of this is that you don't have the opportunity to accidentally overhear things that are relevant to your work. At Digital Focus, we solved this by giving each developer their own office, but also having a bullpen right next to those offices. It worked really well.

Unfortunately the use of cubicles and now bullpens for software development is so prevalent that it has set a new standard for the square feet needed per developer, which translates into a direct cost per developer. CFOs will now balk at giving developers private offices - something that was standard practice during the 1980s.

The hidden cost is that we might be losing the best creativity and ideas of developers. In an environment with distractions you never really think deeply. Your thoughts can get down to a certain level of depth, but never all the way. In a recent article in the New York Times Sunday Review, "Hit the Reset Button in Your Brain" by Daniel Levitin, director of the Laboratory for Music, Cognition and Expertise at McGill University and the author of “The Organized Mind: Thinking Straight in the Age of Information Overload,” Levitin says,

"...the insight that led to them probably came from the daydreaming mode. This brain state, marked by the flow of connections among disparate ideas and thoughts, is responsible for our moments of greatest creativity and insight, when we’re able to solve problems that previously seemed unsolvable."

Collaboration is great; but it is not a silver bullet. People sometimes need to think quietly by themselves. If we deny them that, we are not getting the best parts of their mind.