Nobody ever got fired for buying...Microsoft??

Like Yogi Berra said, sometimes “it's like deja vu all over again”.

I guess I’ve been at this long enough to remember back to the 1980's when, in corporate IT, we tended to look for the IBM solution first, regardless of what other options there might be, and often overlooked the fact that the IBM option really sucked, as long as it had the illusion of being consistent with our other IBM software.

It seems to me that Microsoft has now assumed this role in corporate IT, with their products being the “safe” choice (remember the old expression “nobody ever got fired for buying IBM”?). The hard part for myself is grappling with the default=Microsoft mentality. It seems increasingly common to make uninformed platform and product decisions that default to the “safe” choice.

Don’t get me wrong, I truly believe that Microsoft is capable of producing innovative software when they are pushed. Things like C# 2.0 and the XBox 360 are examples of products that Microsoft is capable of producing when the chips are down and they are behind the competition, and I'm a big fan of those innovative products. Microsoft earned their current position in IT by coming from behind and delivering more value than the competition – they just don't have a great track record of innovation once they are in front.

It's just that a lot of people in IT are falling into the same trap as the IBM fans back in the day - “If it's good enough for Microsoft to release it must be good enough for us.”.

A lot of organizations are driving their businesses forward using alternative platforms. I listened to a Paul Graham talk a while back about open source and blogging. He's quite prolific with one-liners but my favorite one was "At this point, anyone proposing to run Windows on servers should be prepared to explain what they know about servers that Google, Yahoo, and Amazon don't".

What should we be doing? Challenge assumptions and herd thinking, focus on best of breed, identify where the value in a product comes from and use that to drive our selections. It's OK to use Microsoft products - heck, practically everyone has to – just make sure you're not using it just “because it came from Microsoft”. There are a lot of smart, pragmatic people at Microsoft – look beyond the product marketing and get them to help you figure out if a given solution delivers the value you need.

Hiring skills

In the IT world we often run into gross oversimplifications. One of my favorites crops up during the hiring process. We sometimes see the requirement for a software developer simplified down to ‘we need a .NET developer’ or ‘we need a TIBCO developer’. There’s an implicit defocusing on skills other than the specific technology mentioned.

Hiring the right people is one of the most critical activities that an organization needs to get right so why the oversimplification? Part of the problem is that it can be difficult for HR professionals to assess technical skills so using generic terms makes it easier for them to screen candidates at a very coarse level. The problem is mitigated if the next step in the process involves a thorough assessment of the candidates skills – not just checking off the 'technology X' box on the interview sheet!

So what skills should we be looking for in software developers? Leaving aside non-technical skills (like communication and leadership) for now, I would focus on 3 areas:

• Languages & tools.Here’s where we’ve traditionally focused in IT interviews.What programming languages, tools and frameworks is the candidate familiar with?Look for breadth and depth.
• Design.What kind of design track record does the candidate have?How have they designed systems or components in the past?Do they have a solid approach to software design?Typically depends on experience, but is a good indicator of capabilities.
• Methods & practices.What software development practices has the candidate used in the past?Practices range from code authoring (e.g. code reviews, refactoring), to code collaboration (e.g. source code management, continuous integration) to organizational (e.g test driven development, iterative development).Look for ways the candidate has tried to improve their development process.

Use a simple range (developmental, experienced, expert) to rate the candidates ability in each identified skill. Of course, beyond skills there are other important factors such as attitude and aptitude, but these tend to be more subjective.

So next time you’re asked to hire a ‘technology X’ developer, think about how you assess their skill set.