CIO Tenure: What is Wrong (if Anything)?

April 22, 2009

CIO Tenure ChallengesAlong with IT project failure rates, the average time a CIO stays with a company is one of the most often quoted metrics in our trade. Recent studies cite that 1 in 4 CIOs are fired for poor performance and CIO’s have an average tenure of 4.4 years. These don’t seem to bode well for the CIO. Why is the tenure so short?  And, is this seemingly short tenure really a bad thing?

While certainly not scientific, I’ve been trying to find similarities and differences in the CIOs I work with as they enter a new job and navigate the waters of the enterprise. By personally observing 30+ CIOs over the last 10 years or so and adding to this the observations of my Diamond partners, I have developed a perspective that tries to match the core skill set of a CIO with the point in a company’s developmental lifecycle. I believe that these matches (or mismatches) can lend some insight into the reasons that CIOs do or don’t last in their role.

There are several views of the types of CIOs and I have my own version:

  1. Strategist – very strong CxO collaborator who brings innovative, often disruptive thinking to an enterprise, visual communicator, conceptual and is frustrated with detailed planning
  2. Transformer – comfortable directing large portfolios of projects, both strategic and tactical; great team builder and communicator; develops and understand business cases
  3. Value Manager – comfortable optimizing IT’s processes and platforms, very good sense for IT efficiency and effectiveness; effectively understands and applies benchmarks and frameworks such as CMMi and ITIL

When a new CIO enters, it is interesting to look at where the enterprise is in its developmental lifecycle. I define the developmental lifecycle as having three simple stages:

  1. Evaluation –assessing its business design in light of competitive pressures, cost challenges, or M&A opportunities
  2. Change – planning and implementation of a new business design
  3. Stabilization – operating the new business design and measuring its actual versus desired impact

Obviously, there is a strong correlation between the CIO types and enterprise lifecycle stages (funny how that works). So, my proposal is this:

A CIO will be most successful when his or her skill “type” matches the developmental stage of the enterprise.

CIO Skill Match

Assuming you have a good skill match as a new CIO, the next question is what happens when the enterprise shifts into the next stage. One of three cases exists:

  1. The CIO combines good relationships and a strong IT leadership team to handle the different IT leadership needs
  2. The CIO doesn’t have what it takes to manage the transformation and leaves/asked to leave as the effort stalls
  3. The CIO is “bored” with the changing role and eventually leaves

Before you dismiss the “bored CIO” as a ridiculous scenario because it doesn’t fit you or your colleagues, take my word that they do exist. In fact, they are some of the most effective and creative CIOs out there.

Consider one CIO I am working with now who is a “strategist” (my term not hers). Over the last five years, she has had three CIO positions in different companies. Her style is intense and creative. She sees her role as a disruptor and seeks to turn the enterprise on its head to get real transformational value from IT. Along the way, unfortunately, her style can create relationship challenges and she tends to leave. I would say that in the end, she puts firms on a better path then when she got there. In fact, she is to the point where she considers herself more of a contractor than an employee. This model may not fit you but it does exist.

From a career management perspective, it may be eye opening for you to think about what kind of core skill you have – strategist, transformer or value manager. I’m not saying that you don’t have or can’t have some of the other two, but one is likely dominant.

Now, consider what your firm is trying to do.  Is there a match?

If not, what can you do about it?


IT’s Keystone Skills

April 16, 2009

KeystoneProcess issues are not alone in contributing to IT’s success or failure. People (and their skills) are also part of the “holy trinity” of People – Process – Technology, the three interrelated building blocks of any business capability, IT included.

With the dramatic uptake in outsourcing over the last several years, CIOs have been faced with a new set of organization design challenges and skill needs. In fact, many IT shops have remade themselves to focus on the relationships and inter-operation with their sourcing partners. The messages sent to your IT staff when you announced that your billing system will be outsourced and the organizational and skill restructuring that emphasizes procurement and vendor relationship management, combine to create a murky career path for your IT software delivery staff.  These are the people who have historically planned, designed, built, tested and maintained your application software.  Without a clear framework for how they fit in and can succeed in an organization with significant outsourcer dependence, the top performers will either leave (already have?) or stop giving you their best.

I have worked with many large organizations who have hundreds of outsourced analysts, project managers and developers.  Some of the common characteristics in the relationships between these organizations and their sourcing partner(s):

  • They have problems communicating project requirements with the outsourcer
  • The outsourcer wants project specifications at a level of detail too low for the organization
  • The organization has difficulty ensuring that the outsourcer is following its technology architecture standards
  • General visibility and status issues

These and other challenges point to some fundamental gaps in project management, architecture, business requirements management and quality assurance.  It’s these four skills I call the keystone skills and view them as the essential IT skillsets, regardless of the sourcing relationships a firm has (short of outsourcing their whole solutions delivery capability).  These skills separately and together serve to create a set of links between the business objectives for a project and its final implementation in software.  Specifically:

  • Architecture links the business objectives to the systems design
  • Business Requirements Management links the business design to the business and technical requirements
  • Quality Assurance links the business and technical requirements to the delivered software
  • Project Management links the project plan to the project business case (costs and benefits)

In our 2009 Diamond Digital IQ study, we found that these keystone skills are among the skills in need of the most improvement in IT organizations.


When looking for opportunities, especially in our current economic environment, I would recommend complementing any process improvement efforts with a hard look at building your keystone skills – project management, architecture, business requirements management, and quality assurance.

IT Governance: Does it Work?

April 14, 2009

My good friend Peter Weill, Chairman of MIT’s Center for Information Systems Research (CISR), defines IT governance as “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.” In a perfect system, desirable behavior would be the norm and governance would deal with the exceptions. Unfortunately, in many organizations, the reverse is true.

Consider the results of a question from Diamond’s most recent Digital IQ survey asking for indications of project success. Diamond Digital IQ 2009 - IT Project SuccessAside from the provision of a high quality computing platform, consistent project delivery has got to be one of the primary ways to measure IT’s value to the business. In this year’s survey, fewer than 50% said that projects were delivered on-time and only 16% said they delivered all of the features and capabilities initially planned. What is wrong here? Some would say that this is a governance problem – how could IT leaders constantly allow projects to continue to burn time and money without intervention?

I would argue that IT governance does not work if it is treated as separate set of overlays on top of the core day-to-day processes. In my experience, many of the performance improvements IT governance is intended to fix cannot be fixed by governance alone.

What is likely at fault in the project delivery case, is not a lack of IT governance, but rather poorly understood, poorly trained, poorly documented and poorly enforced set of work processes. In the case of IT project delivery, an organization’s use of its chosen software development lifecycle processes, or SDLC, while often talked about, is usually at the root of the problem. Symptoms of this problem that I often hear:

  1. “We use the vendor’s/outsourcer’s methodology” (you need one too to drive the action)
  2. “We have a standard set of templates” (that’s not enough)
  3. “We use (fill in the name of a project work planning tool)” (a tool cannot replace a well-defined and followed process)

Enterprise architecture (EA) is another area where governance is often applied. In the case of EA, lack of a solid core process is also often to blame in poor architecture adherence and adoption. Again, an organization must spend the time to enhance its project planning and SDLC processes with the proper EA tasks instead of simply adding an EA governance mechanism on top of a set of immature or broken core processes.

So, before launching a new IT governance design effort, make sure to inspect your core work processes first. They are often at the root of the problem.  IT governance does work, but only when designed along with the processes it is supposed to help.

Why Twitter is the Duct Tape of Marketing and Why Every Firm Needs to Know How to Use It

April 3, 2009

Chris Curran & John Sviokla

Duct tape is universally useful because it is incredibly simple, almost infinitely flexible, easily available, and cheap.  Twitter shares all these attributes.  Twitter is a new layer of communication which can be overlaid on everything – just like Duct Tape can be used to repair a chair, or make an artificial flower.  Anyone can use the web and their phone to both send and receive tweets (messages of 140 characters or less) – for free.  It enables people to send messages directly to one person, groups to self form, or to send a tweet to everyone who follows you.  Some people only follow a few dozen compatriots, Guy Kawasaki follows over 100,000 people and has almost 100,000 followers, as well as creating (with some help by others) over 28,000 tweets!  By way of comparison, the Boston Globe had a circulation in 2008 of about 350,000 – falling at a rate of 8-9% per year.  As a pundit, Guy is using Twitter to build an ongoing audience.

But it is so much more as I’ve already discussed here; the range of applications is spectacular.  From online commentary for any off-line event, and the New York Times developed a great visualization of the tweets during the super bowl to Pepsi’s integration of Twitter with geographic information at the spectacularly popular South by Southwest music, film and interactive media festival to Whole Foods recipe tweets.  Almost every major media outlet is tweeting, the Apple App Store has over 100 Twitter applications, and there are over 100 free tools that have already bubbled up.

How did this seemingly trivial application that Jack Dorsey created in two weeks back in March 2006 as a way for him to know what his friends were doing grow into this global phenomenon?  We think it is because of three critical things: first, the design is simple, modular, scalable and cross platform.  Messaging used to be a youth dominated phenomenon, but just walk into any business meeting and think about how similar tweeting is to blackberry email.  As social animals, we humans are addicted to communication and understanding how our social group is acting and thinking.  In business this is very practical, and in social settings very entertaining.

Second, Twitter has an open technical architecture.  As I pointed out in another post, it is an example of an application that sits “in the cloud” and is available everywhere.  The interfaces to the capability are simple and well defined in their Applications Programming Interface (API), which makes it easy to plug into their messaging capability.

Third, and perhaps most importantly, it is very easy for people to join, and to self organize around topics, companies, individuals, and events.  In this sense it is an incredibly “democratic” medium – with all the control at the ends of the network.  Our Diamond Fellow David Reed wrote about Reed’s Law in Harvard Business Review many years ago about the power of self-forming networks and it is because of their very flexibility of organizing that makes them so powerful.

Twitter is, and can become so many things, we are suggesting three questions to think about – but they are only a start.

  1. What are people saying about my brand?  There are many tools that can help you track how people are talking about your company, or issues your customers are thinking about, or complaints?
  2. How can I connect and build a direct communication between my firm and all the customers who want to follow our tweets – on their phone, web, or other device?  It is cheap, direct, and growing.  There is no downside, as long as you put thoughtful effort behind the initiative.
  3. What capabilities should my firm have so that we can use the right tools to track topics and conversations being tweeted about in my industry, product/service area, and target market?

We believe – as other pundits have pointed out – that this current wave of the internet is becoming more real time and populated by many mini-applications like Twitter that will be assembled together to create functionality.  Senior executives should care because marketing and sales has always been about communication, references, and word of mouth, and Twitter turbo charges that hugely human process.

Furthermore, we believe that the new “links” that Twitter creates with its Tweets, among and between people and groups will some day be mined for superior search and attention management – just the way Google uses page links to power its search algorithm today.  It is only a matter of time before Google or Microsoft buys them and integrates the functionality into their platform – and it will be part of how every company communicates and markets.  Now is a time to get a jump on the competition!

CIO Leadership: Listen to the Guy on the Ground

April 3, 2009

The Mission, The Men and Me Cover

I’ve been enjoying The Mission, The Men, and Me, an Army Special Forces commander’s account of his missions and the fundamental lessons that he took away from them.  The author, Pete Blaber, is now an executive at Amgen, which both lends credibility to the application of his ideas in a business context and provides a glimpse into the kind of leader he is.

Among the lessons he distills from his experiences is that a leader must “listen to the guy on the ground.”  He tells a story about a training mission they were planning in the Bob Marshall Wilderness in Montana.  During a pre-mission visit, they stopped in a local diner to eat and ran into a crusty old guy who turned out to be a former Special Forces soldier.  When asked what the #1 piece of gear they should take on their training mission, he said “snow shoes” because of the crust that forms over the snow would swallow their legs if they don’t have them.  These were nowhere near their gear list, especially given their trip was planned for June!

The “listen to the guy on the ground” lesson reminded me of a financial services CIO that I have worked with closely over several years.  He has a finance background and is very comfortable working with the senior business leaders – unfortunately, too comfortable.  Actually, this CIO is so focused on his relationships with his business counterparts, that he neglects developing his IT leadership.  Eventually, I believe that it contributed to him leaving the company.

His lack of deep relationships with his IT leaders and managers, led to a number of things:

  1. An ineffective IT organization structure with too many layers of management.  This would have been painfully obvious to anyone who spent any real time in meetings, governance boards, etc.
  2. Too much focus on high-level planning and frameworks, and not enough groundwork to figure out what would really work in his organization.
  3. Overruns in large programs and projects, due in part to delegation of leadership to 3rd party vendors.  On the ground leadership would have certainly reined in these projects or stopped them entirely.

His leadership imbalance could have been caused by many things.  In this case, I think it is a combination of his discomfort with IT concepts and details and his belief that he didn’t want to be perceived as a techie and wanted to maintain his “I’m an IT outsider” positioning.

Don’t neglect the “guy on the ground.”

Twitter: SOA in Action

April 2, 2009

Talk about incredible innovation – look at the application and service ecosystem around Twitter.  Here are just some examples:

  • On-line Commentary During an Off-line Event – The NY Times developed a beautiful visualization of popular words in Twitter posts during the Super Bowl.
  • Real-time Trends – Twistory streams real-time Twitter posts filtered to let you see what people like, hate, etc.
  • Local Tweeting – Pepsi came out with an impressive app during the South-by-Southwest events (SXSW) that overlays real-time tweets on a map
  • iPhone Apps – there are at least 100 Twitter related apps on the iTunes App Store, many of them free.  Two I use are TwitterFon and ReTweet.

Why is this happening?  It’s all about Twitter’s open application programming interface (API).  Twitter has opened up the interfaces (aka services) to its system so that anyone on the web can both perform the basic posting and account management functions and search the massive Tweet database, all from a programatic interface.

We can learn a lot from this:

  1. Open interfaces enable innovation.  In fact, facilitating an open development community around your services is even better.
  2. You can learn and experiment with SOA by working with “public” services like Twitter or Google’s Data Visualization API or UPS’s package tracking API
  3. Using “public” services does not necessarily require re-thinking your enterprise’s architectural approaches, but can give you hints on good/bad practices for your own “private” (internal to your company) SOA efforts.

I will write a few posts on private SOA, but here is a recent survey conducted by Diamond and MIT’s Center for Information Systems Research on the subject.

There are many more super Twitter tools and apps around.  Here is a list to start from: 17 Ways to Visualize the Twitter Universe.

Application Architecture’s Waxy Build-Up

April 1, 2009

Susan Cram’s article on the evolution of systems points to the “clean as you go” approach as the only workable way to reduce the application clutter built up over time.  I agree with her observations as surrounding the legacy systems doesn’t do anything to reduce the cost burden.  Also, the greenfield approach almost always creates a program too large and complex to complete.

The next question is how to approach the cleanup – or application rationalization as we call it.  Should you let each new application project drive the order of the cleanup or should it be more top-down or systematic?  Here’s how we identified candidates for clean-up for one of our clients in the consumer products business:

  1. Reviewed the business cases for the recent systems projects to identify the applications that were supposed to be replaced. Checked their status.  (It’s my bet that you still have some of these around)
  2. Collected usage data for all of the major systems on shared infrastructure.  Saw how many people are logging into them and how often.
  3. Looked at the help desk tickets and the requested bug fixes and enhancements for the top 50 applications.  These are indicators as to what is not meeting users’ needs.

Hopefully, this will get you on your way to developing some priorities for your application clean-up.  Check out this brief video for more on application clean-up.

The OpenCloud is Hazy

March 31, 2009

The Open Cloud Manifesto effort is admirable.  It seems like a lofty goal but one centered on making this cloud thing better for all (ok, maybe not the vendors).  It also shows most of the major old school players in support – although Dell is not on the list.  As far as the newer players – Google, Amazon, Yahoo – cue the crickets.  However, before they get some serious traction, the Manifesto authors (who are they, anyway?) need to better explain a few things, including:

  1. What exactly is the cloud and how is it different from the utility computing and other outsourced infrastructrue concepts we’ve been hearing about from IBM and others for a few years?
  2. Are they more concerned with the “public” cloud or the “private” cloud, or both?  The public cloud is a more interesting thing to talk about, but is not likely to get a lot of traction as the enterprise will be more focused on the private cloud first.
  3. Why all of the concerns about shared infrastructure and mulit-company data residing on the same infrastructure?  These are issues asked and addressed ad nauseum by outsourcing vendors (both app and infra).  What is new and more troubling this time?
  4. The Manifesto discusses flexibility in switching from one cloud provider to another as a goal.  First, it’s not clear what standards are needed that don’t already exist.  Seems like with all of the HTTP, SOAP and other net-based interface protocols, we are in pretty good shape.  What else is needed here to facilitate switching?

On the topic of switching, any robust service in the cloud will require reconfiguration and retesting with a new provider.  None of the need for rigor goes away.  I personally think the switching goal is overblown because cloud users (as all users of a service) will gravitate to those with the best service/value equation.

Finally, I think the Manifesto misses out on a great opportunity to raise awareness and create a discussion around green computing and the responsibility that cloud providers have in creating this new infrastructure responsibly.