6. Hiring for the Longer Term

Hiring is such a critical long-term event that all too often doesn’t get the attention that it deserves.  Your success as a leader is so dependent on the people who work for you that you should view this as one of the most important things you do.  To hire successfully you need to truly understand your culture and what sort of person will fit in and what sort won’t.

Over the past fifteen years I have left the technical interviewing to my managers and senior technical people.  I have interviewed strictly for “fit”.  For example, if your department (and mine was by design) a collaborative one, then you should avoid hiring lone wolf type personalities.  They would get frustrated, as would the rest of the staff.  I also tried to hire people who had an interest in the business.  To me that is key.  We all know that technology is going to continue to change rapidly.  By having employees who understand and identify with the business, I had employees that adjusted to new tools and technologies.  If you hire people who identify with a technology and then change technologies, they are much more likely to leave because the basis for their identity is gone.  The total cost of replacing staff is very large,

It is easier to train people in a new technology than it is to train them in the business.  Having a temporary contractor who has expertise in a new technology and who is willing to share is a very efficient way to bring employees up to speed with new technologies.  I used this model with great success over the years.

Another advantage of having employees identify with the business is how well the user community receives them.   I constantly had new users tell me how impressed they were by the way my staff, even the most techie of them, would talk in business terms instead of techie terms.  Years ago a wise VP I worked for talked about having Business Smart IT and IT Smart Business.  If IT does the first part, it is much easier to get users to do the second part.  The result is a high performing engaged team and a company that maximizes their use of their IT investment.

My mental model of people and whether they can have a business focus is a normal distribution curve with the one tail being techies no matter what you do and the other tail being business focused no matter what you do.  The majority of people fall in the middle and will be either business-focused or techie-focused based on how you treat them.  Treat them as business people!

5. Tyranny of the Or

“Tyranny of the OR” is a concept I was first introduced to more than ten years ago by the COO of a company I worked for at the time.  He described a facility manager asking him if he wanted a safe plant or a productive plant.  The obvious answer is, of course, both.  The problem is that all too often we accept an “Or” question as a valid question.  Once we do that we are restricting ourselves to a win-lose or even a lose-lose situation.  Even more ironic in the case of the above example is that over time a safe plant will be a productive plant.

Further research on this subject introduces a second clause to the saying – the “Genius of the AND” concept.  While some may view this as striving for “Eating your cake and having it, too”, I view it as a valid strategy that is usually obtainable. 

The first step is learning to recognize when we are being asked a “Tyranny Or” question.  It is not always easy, but with practice you should get an uncomfortable feeling when one is posed to you.  Limiting the boundary conditions in discussion too early in a process is almost sure to lead to a suboptimal result.

Replacing the "Or" with an "And" helps keep more options open for discussion.  It has been my experience that most people who ask "Or" questions do so without realizing the immediate limitations they are imposing on the situation.  These people are usually easy to bring around with a short discussion.  If you run into someone who uses the "Or" proposition intentionally, my advice is to be very careful.  You are dealing with someone who is knowingly trying to get to a conclusion favorable to them without you knowing it.

Let me know of any examples you have encountered.

4. IT Strategy

Last week I talked about Business IT Alignment.  This week I go a little further into developing an IT Strategy.

There are multiple reasons why a company may decide (or should decide) to do an IT Strategy Project.  Some obvious ones are:

• Merger or Acquisition
• New Business Strategy to align with
• Time for a refresh (I think every IT Department should refresh their strategy every four to six years).

Each piece of the strategy needs to address:

• What you have
• What is available (often, but not always a key component)
• Where you need to go (to align with the Business strategy)
• How to get there

The actual execution of the project can clearly benefit from outside help.  Like all strategies, an outside-in perspective is helpful.  That said, internal resources need to play a key role in the project as well to ensure buy-in and ownership.  Boutique firm or large firm doesn’t matter as much as the cultural fit and personal relationships of the key players.

Common components of a strategy include:

• People & Organization
• Technology
• Applications
• Governance

Sub teams can be effectively used to address each component in the pieces mentioned above.  For example, the section on governance should address major projects, smaller projects, baseline requests, how they should be handled, whether a formal or informal PPM (Project Portfolio Management) process is needed, how it should be staffed, rolled out, communicated, etc.

If the Strategy fails to describe in some detail how it should be implemented, in what sequence, and in what time frame, it almost sure to be a waste of time and effort and it will never be implemented.
Different tools can be used for each component.  For applications in particular, there are some great graphical tools that can be used.  So much can be illustrated through quadrants by using:

• X and Y axis can show items like:
• Level of support needed (IT view)
• User Satisfaction (User view)
• Viability of support (vendor or even hardware platform for an old application)
• Circles for Applications / processes with size showing complexity and color how well it fits the future business need. 

What attributes you choose to cover will be partially determined by what problem you are trying to solve!

A project like this for an average sized firm should usually take six to twelve weeks from the actual kick-off (meaning it is fully staffed and organized).  There needs to be a Steering Committee for this project as well to ensure proper direction and boundary conditions.

The proof of the value of a strategy is in its execution and verification that the goals it set to accomplish are being met.   Quarterly to semi-annual updates should be provided to senior management and personnel objectives should be tied to the results.

3. IT Business Alignment - Simple Steps to Make it Work

I don't remember any time over the past twenty years when "Business - IT Alignment" has been lower than third on lists of top issues for IT Departments.  This is truly a sad state of affairs.  It is also, in my mind, a totally unnecessary state of affairs.

Consider three organizational structures:  

1. Divisional IT within an autonomous division

2. Corporate IT where there is only one division

3. Corporate IT serving multiple divisions

The first two have the same solution and there is no real reason it can’t be implemented.  The requirements are:

• IT has a “seat at the table” and is included in business strategy discussions.  They need to have an active role so that their constraints are considered along with other constraints.
• IT projects are then created in support of the business strategy. 
• If the overall business strategy changes then so does the IT component.

The third structure, while more complicated, also works.  A governance structure, usually some form of PPM (Project Portfolio Management), works best.   The portfolio of projects still needs to align with the Business strategy.  If each division has it’s own strategy, which is common, the Portfolio of projects needs to include, at a minimum, attributes for:

• Division
• Size
• Complexity
• Application Area
• Risk
• Potential Return
• Regulatory Requirement

Other attributes should be added based on the parameters considered for the business strategy.  Here some divisions may not get what they want when they want it.  However, all will know up front, and if the IT Group is able to flex its capacity with outside resources, these instances should be reduced.  That flexible capacity should be a requirement for any Corporate IT Group serving multiple divisions.

Another approach to help ensure business alignment is to divide the IT Development budget into:

• Major Project (goes through formal PPM process)
• Discretionary Project (each department (for 1 & 2, above) or division (for 3) agrees to a discretionary budget amount for smaller projects.  The prioritization process for this can vary by department / division based on their wants)

It basically comes down to communicating clearly, estimating well, looking for benefits and synergies, being flexible enough to adjust projects as priorities change, and reporting back on a regular basis.  

The only real exception to all of this is that if there is not a business strategy, there is nothing to align with.

As always, I welcome feedback and suggestions.