Interviewing technical people can be challenging.  What is the right mix of experience and ambition?  What level of expertise do you need?  I’ve built several technical teams and I will tell you that the ‘magic’ always starts with the core team.  These are the folks that will set the standard for your team.  So how do you find these folks?

Iceberg Test

There are thousands of books out there that discuss interviewing techniques.  All guaranteed to help you find the perfect candidate.   The main issue I find with these techniques is that they are perfectly inept at discovering true IT talent.  So what makes a candidate a great find?  A passion for technology.  This can take many forms.  Some candidates blog.  Some are always learning new technologies.  And others have ‘side interests’, read: side businesses.  

The most difficult thing about interviewing candidates is pulling this information out.  I think most people are taught as young adults or professionals that talking about your external interests during an interview is taboo.  I disagree.  As a hiring manager I want to see that you live, breath and consume your profession.  And for me, finding out about your outside work is pivotal in that determination.

This is how I came up with the iceberg test.  Based on my experience a solid technologist will only have about a third of their relevant experience represented on a resume.  The challenge is to find out if there exists a layer of experience that is not represented.  If you have the good fortune to come across a technologist that passes the iceberg test I would highly recommend you seriously consider extending an offer.

I’ve recently been reading a few articles about the future of application development and IT infrastructure management.  I believe that one of the main issues that face most IT pros is that we get caught up in the buzz word factory.  Today’s latest: Cloud computing, Web 3.0, etc.  What we fail to realize when we speak about the future of our architecture is the changing dynamic of our end users.

We, as a profession, need to realize that the end user is really what keeps us working.  It used to be that the goal of any application was to cater to the least common denominator, the weakest user.  If we could get that person to be productive and make less mistakes while using the software we wrote, then it was a success.  I believe that the paradigm has shifted.

I attend meetings every day where a user has created an application using Excel or Access.  Typically these applications have a degree of sophistication that amazes me given the lack of formal training and IT processes.  I’ve come to realize that most of the folks that work on these have ‘grown up’ in a technology enabled life.  I’m not just talking about 20 something's here.  The level of sophistication spans all generations.  For example, my father called me the other day to inform me that he updated his weather station so that it automatically FTP’s data to his website.  We are talking about a guy who no less than five years ago would ask me how to configure his email account. 

As a technologists we need to start thinking about embracing this trend.  We need to stop thinking about the lowest common denominator and begin thinking about how to enable users to ‘mash up’ or create their own technology solutions.  We can see this trend in BI trends. Analytic capabilities are being pushed to the end user.  No longer is a static report acceptable.  Users need and want the ability to drill through data, create their own reports and share with their peers.

Perhaps we, as technologists, need to re-explore the promise of SOA.  Not as core architecture, but a way for end users to plug-in, utilize the centralized logic and resources so they can leverage tools to make applications that work for them.

My advice for IT pros and lowest common denominator of users is the same: Adapt, or become obsolete.

I’ve recently had the pleasure of working with Microsoft’s 2008 BI stack. I say pleasure because Microsoft has really pulled out the stops.  The architecture is sound, the performance is outstanding.  Gartner has ranked Microsoft’s BI offering in the top quartile of providers.  This puts them in the same league as Cognos (Oracle), Business Objects (SAP) and usual players in the space.  I have used Cognos and Business Objects in the past and have had the opportunity to use or see most of the other vendor offerings.   Each Vendor offers tradeoffs.  Below is my experience with Microsoft’s BI solution up to this point.

Microsoft’s BI offering is centered around SQL Server.  In this case my team and I used Microsoft server 2008 and SQL Server Enterprise 2008.  I wish I could tell you it was because we wanted to take advantage of the performance improvements, However our logic was simpler.  If you’re going to build a new stack just use the latest and greatest.  The most important thing to the team was to use SQL Server 2008 so that we could take advantage of what R2 was going to provide.

The first thing that really struck us was the modular nature of Microsoft’s strategy.  SQL Server is the core, but in terms of delivery Microsoft relies heavily on the fact that most business users utilize Microsoft Office as their main office productivity suite.  It’s a safe bet considering that Microsoft has an incredible penetration rate in this space.  However, external facing customers might prove to be challenging in terms of delivery.  We chose to put a proxy between our Reporting Services implementation and the outside world.  This allowed us to implement URL rewriting and offer another level of security.  Unlike Cognos, which offers an easy to implement portlet we had to custom make a solution for implementation into our ALUI portal engine.  Of course all of this can be solved if you just use Microsoft Share Point.  This was not an option for us.

Typically I’d view this module nature as being a hindrance, or even a lack of integration features.  What we ended up finding is this is actually a strength of the Microsoft BI stack.  Microsoft has a great API/services to access all the functionality.   Building out a custom solution for integration was not that bad compared to the limited options for customization that other vendors offer.  For example, Users can natively access cubes and analysis right from Excel 2007.  However, because the API was so rich, we chose to write our own ‘Excel tab’ to make accessing and running analysis functions as brain dead as possible.  A solution that users appreciate.

So far, as a strategic play, Microsoft’s BI offering is proving to be a good investment.

I just added the Google Voice widget to the blog.  I’m a little apprehensive about adding the ability to call a number directly on the site, but let’s see how it goes.

I’m going to tell you the tale of two software shops.  Both shops have incredible Engineers,  great Product Managers and excellent processes.  The only thing that separates these two shops is release night.  One shop knocks out the change in minimal time, the other is working through the weekend to fix issues.  This anomaly has nothing to do with platform choice, complexity of the stack or location.  The problem is universal across all of these.  The difference between these two shops, a release engineer.

Typically a release engineer is a person, or team of people, who are familiar with the build, deployment and configuration of a product.  This is important because one thing I can tell you for sure, your production environment is not exactly the same as your lower environment.  Even more sure is that your production support team has even less knowledge on how to trouble shoot release issues.  You absolutely need someone who is familiar with your configuration.

Unfortunately release engineers are somewhat of a luxury for many shops.  They are an unappreciated component of a successful software shop. If you can’t get the budget to hire one I have a suggestion that has worked for me time and time again.  Appoint one of your developers (and a backup) as the designated release engineer.  This makes on person solely responsible for the success of your pushes. 

There is a cost associated with dedicating on of your developers.  I generally find it amounts to 10 hours a week as the developer builds and defines the process, approximately 6 weeks total.  After that, maybe 1 hour a week to maintain the process.  It sounds like a modest investment, but it will pay off the first time you have 6 developers working all week to make a deployment successful.