Recently we carried an article on something CapGemini's Steve Jones (SOA thinker) said on his blog about how IT Values Technologies Over Thought. That generated a lot of discussion here on InfoQ and also over on Steve's blog. The comments seemed to roughly split the readers in half between those who agreed wholeheartedly with him and those who didn't. However, several of the comments had a common belief that the problem is often to do with the skills and quality of the people in IT rather than the technologies and the client's belief that what they are told is correct. One of the comments summed this up:
The situation in this market is rather like the one existing when a modern (=clueless) consumer takes his car to a garage. It's not easy to know if the work being done is of high quality, or even if it is necessary. People widely accept that a lot of outright fraud is going on in garages, but for some reason seem to assume this isn't the case with software development projects running into the billions.
Well Steve returned to this topic in his recent blog post, where he asks how you can spot people who are bluffing?
And here I mean people who don't really think they are bluffing because they are rubbish, or those that are bluffing because they think you are rubbish, its related to the challenge of Terry Pratchett Architects (PArchitects?) where how do you tell someone who distaines technology through knowledge v one who distaines through ignorance?
Steve makes an assertion that "95% of people interviewing senior IT people don't understand enough to weed out bluffers" (presumably based on his experiences within the industry, since there is no data within the article to back this up). And based on these experiences, Steve believes that he has regularly come across senior people who are in their current roles based solely on "a level of buzzword knowledge". Therefore, it is this lack of real skill and knowledge that contributes to the general problem he outlined previously. So in an effort to try to help rectify this, Steve's come up with a coupe of tips to spot these bluffers during the interview stage (what you do if they get hired is an exercise left to the reader!)
- Don't do it in a phase 1 Tech, phase 2 HR interview process - add in a middle phase which is set up by phase 1.
- In Phase 1 ask the following
- When was the last time you coded into production, what language, what plaform (sic)?
- When was the last time you created a conceptual and logical data model? What platform for?
- What is the difference between Regex, Regular Expressions and Perl in string handling?
Steve's not alone in believing that an IT architect should not be so far removed from reality that they don't know how the platforms they help design or influence work. Furthermore, he believes than an architect should at least remember how their last platform worked. Hence the reason for questions 2.1 and 2.2. Question 2.3 comes from a very personal experience of his:
[...] the last one is something that stunned me once when someone I was interviewing kept saying "I did Regex" and then later on said 'On that project we used Regular Expressions', I asked him the difference and he said that Regex was a language, Regular Expressions was... a different language. The point here is that you are after an understanding of the languages and platforms for which this person claims some level of expertise.
The point of Steve's multi-phase approach is to determine where the Bluffer claims to have knowledge in the first phase and to then rip a hold in that fallacy during the second part of the first phase. We've carried several articles on what makes a good architect in the past, as the role of architect and lead developer(s) are obviously critical to the success of a project. Most recently the IEEE article (republished here) on The Pragmatic Architect may also help here. But going back to Steve's aim: to help weed out bluffers using this multiple phases during the interview process. Getting this to work requires the right kind of interview panel and sometimes different panels for each pha
In the second interview you should include real deep developers, get them to ask real deep developer questions. You aren't looking for 'this person is a bitch ass programmer in language X' but 'not brilliant, but seems to know his stuff generally'. What you are looking to avoid is 'I don't think this guy has ever used X in his life' or similar statements.
The point here is that you need a first stage to find out where the bluffer claims to have depth and then a second stage to rip the hole if it exists.Of course although Steve's initial focus was on architects, he doesn't want to put the entire Bluffing Burden on them:
Similar approaches, but more abstract should be used for PMs and BAs where you should get PMs and BAs who have done similar technical projects to ask the questions. I'm stunned at how many times I meet someone who is a 'Functional' SAP BA and then when you introduce them to someone who really is a functional expert in that area they fall to pieces... sometimes not even knowing the acronyms of the SAP modules they claimed to have used ('We did supplier management, not sure what SAP called it')
If we return to Steve's original point, that IT no longer desires thinking, then he believes this is the ideal situation for Bluffers to thrive. So although there are a number of changes to our industry that need to occur to help address this situation as many of the commenters on his original entry point out, perhaps it all begins at the interview stage? As Steve implies, if IT hires people who really do know the subjects they purport to understand, perhaps it will return to appreciating thinkers over technology. However, this sounds like a very obvious solution so are IT companies or groups really fooled by Bluffers as much as Steve believes?