Is ITIL Really Evil?

Read a very interesting blog post the other day that got me thinking...

The No. 1 Threat to Private Cloud Deployment: IT Management and ITIL

The basic tenant of the blog posting is that ITIL and other traditional IT managment structures are fundamentally unsuited to cloud style architectures and this is holding people back in their journey to private cloud.

This was directly related to another blog entry on the same site:

The Biggest Threat to Your Private-Cloud Deployment: Your IT Staff

This blog entry put the blame squarely on the IT staff.

Either way, I agree that people and process issues are definately the core issue keeping companies from being successful in deploying private clouds.

On the other hand, I don't think that it's really fair to blame the whole organization for failing to adapt to a new business paradigm.  There are really only a few people who own this type of change.  It really comes down to senior IT leadership and senior technical leadership to drive this kind of change.  Since I am an Architect, and not a CIO, I'll go ahead and say that I think that the senior technical leadership has an opportunity to step up to the plate here.

As you move up through the ranks of a technical organization there is an assumption that you have technical skills.  After all, that's how you got promoted in the first place (hopefully).  On the other hand, you probably did not get promoted for your business acumen.  What I see as the core issue with most IT organization is that there is no expectation that senior technical folks have a broad purview and a high level of business acumen.

I firmly believe that the difference between mid-level technical folks and senior technical folks is their breadth and business acumen.  There is really no other way to build an organization.  Think about the career path of your typical technical person:

• College Hire.  Straight out of school.  Knows nothing.
• Journeyman.  Knows the job and can be left alone with sharp objects.
• Expert.  Really knows their stuff.  Best individual contributor on the team.
• Master.  Teaches others.  Leads teams.
• Architect.   Plans for the future, leads technical programs, owns the solution.

If you think about this journey, your technical depth really starts to plateau around the "Expert" level.  Not that we stop learning, but the point is we have showed that we know how to learn and that we know how to be a techncial person on the team.  That's how we got promoted to that point.

However, becoming a "Master" implies a different skillset.  You need to be able to make others great.  Not all of us can do that. You need to have a broader perspective about how people work, how they learn and what the external organization really needs.  At the architect level, it's all about external inputs.

When I see senior technical people fail, it's usually because they're an "Expert" that's been put into a "Master" or "Architect" type role.  I'm sure if you think about this for a few minutes, you can think of examples from your own career.  When I mentor people I start out by trying to understand where they fit in this continum and what type of job they currently have.  Then I try to understand their aspirations.  Many technical peole do not aspire to make others great.  For those individuals, a "Master" or "Architect" role will never work out. 

If your aspiration is to become an Architect, I would encourage you to think about how you make others great.  How do you increase the overall value of your team?  By imparting your knowledge and expertise to others, you will not only help them succeed but you will also learn about their expereiences and viewpoints which makes you a stronger member of the team also.

So how does this apply to the private cloud adoption curve discussed in the blog posts above?  I believe that both of these blog posts are focused on the SYMPTOM, not the CAUSE.  The symptom is that organizations are not learning and/or adapting to change.  The cause is that senior technical people are acting as EXPERTS, not ARCHITECTS.  An architect is by definition externally facing and is by definition aware of the changing business climate.  An expert is not.  I would not expect an expert to be able to guide an IT organization to adopt the new cloud paradigm.  That's the job of a Master or an Architect.

If the IT organization makes no effort to develop people along this path, then is it any suprise that they cannot adopt to this new paradigm?

If you are an IT director or CIO, ask yourself a couple of hard questions:

1) What am I personally doing to help my people raise their level from Expert to Architect?
2) Who, within my organization is ready for the next step and how do we get them there?
3) How are Experts incented to raise their game from Expert to Master and then Architect?
4) What is the career path within my organization for senior technical people beyond Expert?