Jun 18

IT Management, Herding the Cats

You know?  There are a lot of management theories and guidebooks out there.  Theory X, Maslow’s Hierarchy of needs.  The five levels (good book, by the way).  I don’t subscribe to any of the more-than-dozen I’ve studied.  As with most things, they have enough truth to be valuable, but not enough to be reliable.  There are some basic ideas which I use when leading people.

First, even when I owned the business and employed several consultants, I have always relied on influence rather than authority to move the people with whom I work.  I get far more results per effort-hour from motivated (and especially from inspired) employees than I would from two people working because they fear for their position.  I begin by building a one-on-one relationship with each one where I understand the levers which motivate them.  In other words, I find out what they want, then explain to them how what I need from them will move them toward what they want.  Then I deliver.  This generates respect and trust.

This goes hand in hand with my practice to pass along kudos – they’re for my people, not for me – and intercept any blame.  The only person allowed to blame my people for anything is me.  In a crisis situation, while on a bridge call to restore a critical service, I heard people saying, in essense, “No, that wasn’t my fault, it was the other guy’s fault.”  I immediately stopped the conversation by saying “No, It is my fault.  Blame me.  Now solve the problem.”  I knew exactly who had caused the problem, and we had a conversation the next day when the service had been restored.  He never made such a mistake again.

On the other hand, I had two people loaned to my team to help out on a difficult project.  They went above-and-beyond, really helping me get the job done.  I made sure that their boss, his boss, and her boss all knew what those two had done for me.  From that day on, I always received instant attention to anything I needed from their group.  This is one of the ways I lead by influence rather than authority.

This same thinking applies to global groups, including outsourcing.  Many seem to think that if the work is being done by an outsource company, the paycheck they receive is sufficient.  I know that treating each one as an individual, and filtering their motivation through a cultural lens based on their culture not mine, makes them perform better.  My projects with outsourced resources do not fail because of communication or lack of domain knowledge issues.

There are a couple of rules I try to never forget, stemming from my time running my consulting company.  First, I always remember that I have some measure of responsibility for the food on their table and the roof over their head – which makes me accountable to them.  I must treat them fairly and make sure they know where they stand so they can make sound decisions about their own future and wellbeing (for good or ill).  Second, helping them to develop into the best they can be only enhances my productivity and chances of success.  In my case back then, it literally affected the amount of food on my table.

There are many other guidelines I use, such as ways to foster collaboration, consensus, and creativity, but I’ve already spouted enough platitudes for one article.  Help me out and tell everyone here how you encourage creativity in your group.

Jun 11

Strategic IT Resource Allocation

So, now that I have pontificated for about 6 weeks on IT organizational structure, I can finally answer the Professor’s question: how do you strategically allocate people to keep normal operations flowing yet still advance strategic IT capabilities that extend the business’ competitive advantage?  If you put all your attention on keeping current things from falling apart, the competition will pass you by.  If you focus only on the future, the floor will rot out from under you – that was the essense of the conundrum he presented (rephrased in my own words).  So: where do you put your best people in order to keep both progressing?

The obvious and over-simplified answer is to balance it out so that they’re spread across the organization.  But I contend that beyond being trite, it is also wrong.  First, the two areas require different talents, meaning it is not an either-or situation.  Second, there are different levels (individual contributors, first-level management, executive direction) that provide more levers to push.  I think that the U.S. Navy has long had the general answer to this question.

A ship is run 24 hours a day, separated into watches.  Let’s divorce theory from reality for this discussion and say that there are 3 watches, one led by the CO (Captain), one by the XO (first officer), and one by the CDO (command duty officer, which is a rotating role, not a person).  Who is on the bridge with the captain?  The weakest, newest officers being evaluated or trained into the positions.  Who is on with the weakest of the three commanding officers?  The best officers for each position – specifically to cover the weakness of the officer commanding the watch.  We’ll ignore the mix characteristics for the XO for the time being.

This same model can act as a guide in strategic personnel assignment.  In the maintenance role, you want a tactical leader who is a great crisis manager.  This role needs little strategic thinking, other than planning for the next crisis.  The people they lead need dogged troubleshooting skills and deep knowledge of how things work, but they do not need to be the “best and the brightest.”  The senior leadership of this group performs mostly an administrative role.  Of the three levels (IC, mid-management, executive), the maintenance/operations group needs the mid-management to be its strongest link.

The development organization, on the other hand, is the exact opposite.  The individual contributors need to be independent and creative, the best and the brightest.  Mid-managers in development often only need resource-management or administrative skills – if the individual contributors are as strong as they should be.  The executive level needs strong vision and inspiration ability.  In this case, the stronger people are in the Individual contributor and Executive positions, while mid-management can be weaker.

Those who show strong management potential might be promoted into mid-management of the maintenance organization where they gain knowledge of how the business works, how important it is that things keep operating, and how to deal with high-stress situations.  Managers from the maintenance side of the house can make good candidates for the executive core of the development organization because they now understand more of how the whole business works and what they need to work better.

As with any organization, there is no one cookie-cutter approach that works all the time.  What I describe here works when the IT organization is structured as I described in the past several articles.  The same kind of thinking (why you need strength at different levels) applied to IT Organizations with different structures and strengths will lead to an optimal layering of talent for that specific organization.

Tell us all how your organization focuses its technical talent to achieve organizational objectives.  Have you seen models that work better?

Jun 07

IT’s Batman and Robin

So we have two TLA’s (Three Letter Acronyms) that look alike and sound alike, what is the difference between a Chief Information Officer (CIO) and a Chief Technology Officer (CTO)?  I will give you a different answer and prospective than you will see by Googling the terms.  The difference is very simple: Whatever the two of them decide it should be.

Sure there are standard definitions, but they should only serve as guidelines.  An organization is unlikely to find two people that fit the textbook roles and they should not try.  The two need many overlapping talents – vision for the future, ability to truly see the present, a deep understanding of the business and industry, and the ability to lead and inspire their people.

I have seen many pairings in different shapes and flavors.  One organization had the CTO as a peer of the CIO, where the CTO (with no direct reports) reported to the CEO and the CIO reported to the COO.  In some, the CTO is little more than the “idea man” for the development organization.  Most common is the CTO who manages the Enterprise Architecture group.  The textbook-ideal has the CIO doing hands-on management of the Operations organization, and managing the Development organization through his proxy, the CTO.

The structure does not really matter as long as it supports the natural division of talents between the CIO and the CTO.  They are partners in helping the business drive for success.  For example, while the CIO would typically be responsible for the supply chain, if the CTO has a very strong LEAN background, they may swap that role.  The two should split up the responsibilities for the department based on which one can best do each major task.

Speaking in generalities, however, the basic distinction is that the CIO focuses more on current operations and efficiencies, while the CTO focuses more on growing the catalog of business capabilities.  Within that very high level division of interest, the two of them operate as a team filling in all the holes and driving excellence into the business.

I have seen a new definition pop up lately, the Chief Science Officer (and every time I hear it, I think of Spock – smile).  Has anyone ever seen such a role in their organization?  How did it compare to CTO and CIO, and did it make an operational difference to the organization?  Please comment here and let us all know.