What Should a CEO look for in a CIO

Whether hiring a CIO or a technician there are some fundamentals that always apply.
You should use the same decision criteria you would with proper "architecture" principles
- How will this new addition fit with the current team?
- How will their experience fit into corporate culture?
- How will their execution capabilities fit into corporate goals and objectives?
- Will this person be willing to stand up in front of a large crowd of executives and tell them what's needed and provide reasonable options for getting there?

As I've mentioned in previous posts I believe that in order for a CIO to be outstanding they have to be much like a CEO. The IT function is often times a mirror of the larger organization. There are teams or application groups that are focused on lines of business or certain business functions (I.e., Engineering or Marketing). Because IT is like a small version of the enterprise it's critical for the CIO to be able to tie these groups together in a common vision. Only by tieing the groups together can the CIO expect to deliver on broader cross functional corporate opportunities.

Building a vision for the entire IT organization that helps everyone understand how they fit into the bigger enterprise puzzle is crucial to team moral and to limiting intergroup competition or infighting. Building a vision isn't easy, but the CIO is more likely to be successful if s/he makes it a team effort. Getting your reports and thier reports involved in the effort will help to ensure buyin and it's an automatic way to contribute to the communication of the plan. The vision should demonstrate how each vertical when working together contribute to making a successful enterprise objective. An opposite example might be something like Marketing building a great lead candidate DB, but not realizing that they could be pulling information from the call center and or providing information directly to the CRM solution. IT must be in a position to bridge that gap and no one IT group can do that it takes the entire function.

Some of the best ways for the CIO to stay in the front of the enterprise are as follows:
- Develop strong relationships built on mutual trust with the exectutive team and their direct reports (remember that most of the real work and business understanding is in the 3rd layer from the CEO).
- Recruit and develop a strong IT leadership team
- Push members of the IT leadership team to go out and work directly in each of the business functions for 1 - 3 weeks out of the year
- Keep your communication with the entire team open and responsive. The minute the CIO or any leader believes they have all the answers, they've already failed. Your number one job is to figure out how to get the best ideas in front of the business, not yours!

I'll talk more about the CIO as mini CEO in future installments. My thoughts here aren't widely accepted or published anywhere, but the logic seems pretty clear to me.

More about IT Leadership and the enterprise

In my first blog I noted some topics that I would be trying to tackle: See below
Blog Title:
Best Practices in IT Leadership & Stewardship
Over time I'll be discussing my thoughts on the following and more;
- how the IT role should align with the business
- how does architecture fit in the big picture of the entire enterprise
- where and when does outsourcing really make sense
- how should any company approach business continuity (especially from the IT perspective)
- should IT be a leader of enterprise change and innovation
- what makes a strong CIO
- what makes a strong IT team
- what should a CEO look for in a CIO and why is it so important

In my last few posts I've covered a few of the above mentioned bullets at a high level, although I haven't done a very good job of tying it all together yet. So far I've talked about the following either directly or indirectly:
- should IT be a leader of enterprise change and innovation
- what makes a strong CIO
- how the IT role should align with the business
- how does architecture fit in the big picture of the entire enterprise

Well there are a few more subjects that are near and dear to my heart that I'd like to add before I forget them;
- Data Centers
- Green IT

I've had significant experience in Data Centers and have some strong thoughts about the Greening of IT. Over the years I've built or upgraded 4 different data centers and managed several others. I like to believe I've had enough experience to know what we need and what to argue against. I can't pretend to solve the entire data center question here, but I will try to give you thoughts on how to avoid setting a trap for yourself.

Building a data center comes with a huge number of opportunities and risks. These risks can be the difference between an efficient enabler of enterprise growth and an anchor that gets you fired. Like my breakdown of discussion topics at the top of the page I'm going to stop tonight by leaving a teaser of what will be coming in future installments.
What to Consider when contemplating the need for a new Data Center or Engineering Lab space
How to determine the size and appropriate density of your data center
Who should you look to as a partner and what should you prepare for when dealing with them
What are some of the major political and environmental factors that could/should influence your data center decision and potentially it's eventual design
Team psychology. (This is an interesting one, but you'll just have to wait for it.)
I'd also like to reference the Blog of someone who knows data centers very well.
http://blogs.sun.com/geekismHis name is Dean Nelson and he's the Director for Lab & Data Center space at Sun.

IT Architecture in the Enterprise

What is IT Architecture and why is it important to the Enterprise?

I once looked up IT Architecture on the web and found dozens of different definitions, but not one that satisfied me adequately. I think most people think of IT Architecture as a "technical layout/design" exercise. In other words, what cable connects to what, iSCSI vs. Fiber channel, Windows vs. Linux all Cisco network vs. a mixed environment. While any or all of the above could potentially be part of an architectural decision process, they would only be a small part. Architecture should accommodate how something fits into the fabric of an entire business. In other words, when you drop a pebble into the pond, you need to observe where the waves go and what impacts they have before you make a decision.

What are some of the things you should consider in applying architecture to a project or technology acquisition decision? The following points are in no particular order of priority. In fact, the priority any of these bullets are given would apply differently based on many factors including; business type, size, maturity, industry, etc., etc.:

Does this technology have any negative effects from a business parnter perspective?
Example: If you're looking to buy equipment from Cisco, but your company does a large OEM business with HP or Juniper, then you might want to consider the alternative options these "partner" companies provide. In the end, the cost of the equipment and the cost of ownership shouldn't be any more important than any other decision factor. If one of your decision factors is "potential to decrease business with a key partner" vs. "save a little money on IT" then I would argue that buying from the partner is probably the better way to go, even if the downside is a negative impact on your team's efficiency. IT should never make decisions because they make IT better for IT, only because they make IT a better partner to the business.

How does the solution scale?
Scale could be up, down or sideways, how you view "scale" should really depend on your business requirements. If you have a rapidly growing company then you should be extra cautious about any implementingion of "home grown" or non "mainstream" products. As your scale grows the cost of entry is soon overwhelmed by the cost of on-going management if the wrong solution is implemented. However, this doesn't mean you shouldn't consider the occasional risk. Taking a risk is OK, as long as the potential payoff is much greater that the cost of failure.
How will the solution you choose work or be supported when or if it has to work in a geographically dispersed enterprise?
Many an IT organization has been caught with their collective pants down when they've implemented a solution that has any or all of the following characteristics;
Doesn't have good support outside the US
Staff with training in the new solution are difficult to find
Adding capacity isn't as simple as adding more boxes or licenses
There a huge number of factors to be considered when architecting your next solution, the above are just a few of the more obvious. I'll be talking more about this subject in subsequent blogs. Suffice it to say, don't assume you've done your architectural work because you chose hardware from the same vendor as the time before!

Why Leader & Not Manager (continued)

In my Blog from November 15th titled "Why Leader & Not Manager?" I left four bullets that I planned to follow up on. Well, this is the follow up.

At a high level the following bullets are suggestions for how you might learn whether your boss (or boss to be) is up to being a leader and good manager.

How can you spot the qualities (good or bad) before it's too late?
· The best chance you have of getting helpful information on a prospective leader/manager is by talking to people that have worked with or are working with him/her.
Questions:
· Does "Joe/Josefina" (she from here on out) take suggestions from her team?
· Does she stop to talk to you without there having to be an agenda related to a key project or task you're responsible for?
· Does the executive team actively seek out the leader for advice and council?
· During all hands meetings is she able to connect with the team or does she talk until the meetings over?
· Does she provide strong support for the team when difficult problems occur on a project (i.e., executive participation or push back)
· The above are just some of the questions, but the answers to any of these could be very telling about the type of leader you're about to get involved with.
· Why are the "good" qualities so important and the "bad" so potentially damaging?
· The good qualities allow for strong team development and greater interaction with the customers (see Nov 15th Blog for more detail)
· Good qualities can be the difference between your team being considered a critical part of the business or just a money pit
· Good qualities will attract more good people, which will serve to make the team that much stronger
· Bad qualities (lack of trust, inability to connect with the team or customers, lack of vision and no support for getting through difficult situations) are the death knell of any organization.
In the end a leader can only be successful if they are getting the job done and in the process helping to make IT an integral & trusted part of the enterprise. However, like a successful project should be measured on more than just "on-time, on-budget" completion a successful organization needs to be a place where people enjoy working with one another. I've been on many teams where work got done for a while, but the cut throat nature of the environment meant that we were less efficient and unable to retain or recruit the best people.
· How do you measure yourself against these "good" and "bad" characteristics?
· Can you take feedback (positive or critical) from a subordinate or customer and learn from it? (good)
· Do you find that most of the ideas in your department are yours (bad)
· Does your team participate actively in meetings, even when you're in the room (good)
· Do you regularly talk with each member of your team about things other than work (good)
· Do you send out company wide messages without team input (bad)
· Do you provide regular (monthly or better) performance feedback, both positive and negative (good)
· Do you get invites from team members to participate in activities (good)
· Do you make fun of yourself/laugh at yourself in front of the team (good)
· Do you fold your arms across your chest when presenting to the team (bad)
With most of the above bullets the assumption should be that the converse of a "bad" behavior is probably a "good" behavior and vice versa.

Why Leader & Not Manager

What is a "Manager", well the American Heritage Dictionary quantifies a manager as follows;
1. One who handles, controls, or directs, especially:
2. One who directs a business or other enterprise.
3. One who controls resources and expenditures, as of a household.
4. One who is in charge of the training and performance of an athlete or a team.
5. A student who is in charge of the equipment and records of a school or college team.
6. One who is in charge of the business affairs of an entertainer.
Does the above description sound like the primary qualities or characteristics you'd like to have in your leader? Not for me it doesn't. A leader should be 70% leadership focused and 30% management focused. A manager does your review, handles a budget, hires people, and files stuff or reads email. A leader's role is much different, they should inspire a team by setting an achievable agenda and ensuring the team has the resources and environment that will make them successful in their combined pursuit of said agenda. A leader is someone that you would work long hours for because s/he is the person they are, not because they've threatened you or intimidated you.
Definition of "Leader" from the American Heritage Dictionary:
1. One that leads or guides.
2. One who is in charge or in command of others.
There are other definitions as well, but the above are the primary definitions related to the role of Leader among humans.
One that Leads or Guides, that sounds a little bit more like the person I want in charge of me. Unfortunately, in today's IT shop it seems there is a preponderance of the "Manager" type or maybe the "Dilbert" definition type.
The average IT shop like any large diverse organization or team can be very complex. The diversity of cultural backgrounds, skill sets, and job types can be astounding. There is also the added difficulty associated with having a vision that can't and shouldn't be independent from the enterprise. In other words, you are rarely working on something that is for the betterment of your team or function. You also have to recognize that many folks on the team get daily and even hourly feedback from customers and this feedback is generally about problems. This type of feedback requires it's own special type of leadership to team interaction.

An IT organization is much like a company within a company. You often have groups focused on the different verticals of the business and like a company these verticals need to still have a common vision that fits the entire enterprise. Creating and enabling this common vision isn't something that most CIO "managers" are equipped to handle effectively. Most of their experience often comes from running a portion of IT or a Finance team. I don't pretend to know where the best CIO's should come from, but I do believe they should be picked in a similar fashion to a CEO. Now that I've made the correlation between CIO requirements and the CEO job, it might become a little more obvious why I believe our CIOs generally aren't up to the task. I'll ask another rhetorical question. Do you want a CEO that spends most of his or her time focused on the companies finances, or maybe looking into inventory management issues or would you rather have a CEO who understands the entire business well enough to translate it's opportunities and the associated goals into a vision that everyone can wrap their hearts and minds around? A leader who inspires you to want to do more than you thought you were capable of and then rewards you for doing it. A leader that will listen to the entire team to get the best ideas, but will still make the tough decisions without delay. These are the qualities I look for in my leaders. A leader can't be shallow, and they can't be weak, self centered or insecure, any of these characteristics will eventually lead to disaster for the organization in the long run.
More on this topic in the coming days;
- How can you spot the qualities (good or bad) before it's too late?
- Why are the "good" qualities so important and the "bad" so potentially damaging?
- How do you measure yourself against these "good" and "bad" characteristics?
- How is a leader easy to work with, but not weak? Or, how can they appear to show weakness because it comes from strength?
If you have any questions or thoughts on my ramblings, I'd love to hear them.
Until next time.

What is good IT Leadership

Best Practices in IT Leadership & Stewardship
Hello and Welcome to the first of many thoughts about the leadership role in IT

Over time I'll be discussing my thoughts on the following and more;
- how the IT role should align with the business
- how does architecture fit in the big picture of the entire enterprise
- where and when does outsourcing really make sense
- how should any company approach business continuity (especially from the IT perspective)
- should IT be a leader of enterprise change and innovation
- what makes a strong CIO
- what makes a strong IT team
- what should a CEO look for in a CIO and why is it so important
- Green IT
- Building the right Data Center for your business

A little history on me:
I've been in IT for over 20 years now. I started my career in an old style Unisys mainframe data center working as an operator. I ran schedules, mounted 9 track tapes, loaded paper in big printers and passed out reports. Starting in late 1993 I moved from this legacy environment where I had become a Data Center Supervisor to a completely new job at HP as a PC support technician. Throughout the rest of the 90's I moved up through assorted IT infrastructure management positions at HP and in November of 99 I was leading a large team of 120 with responsibilities for 9000 internal customers (end-users). My years at HP gave me the opportunity to take responsibility for international functions (Singapore, HK, Malaysia, UK & Germany) and I also had staff or partners in several states in the US. My first HP management role was Helpdesk Manager, where my primary objective was to build a helpdesk function to support 3000 end user customers. Over time I also took on client support, technical solutions, web development and data centers. I still look back on my years at HP with a great deal of fondness. I worked with some excellent people and was given the opportunity to contribute in so many ways.

From 2000 through mid 2007 I held positions as Associate Director and then Director of Global Infrastructure for a rapidly growing biotech (200 million in sales to 2 billion in 5 years) and for a technology company in the SAN storage vertical.
In my role as Director of infrastructure I built teams from scratch, and restored teams that were falling apart. I've built Infrastructure including new data centers, global networks, email solutions, application provisioning and much more. I've implemented controls for SOX and compliance for the FDA and build strong change management processes. Of course, I didn't do any of the preceding alone, I had a strong team as my foundation.

The infrastructure I've been a part of creating or implementing and managing is what most people think of when they think of their success, but for me it's the people. I've been a part of some amazing teams whom I've learned a great deal from. Of all the accomplishments that I can claim some credit for, it's my work in developing strong people and teams and then maintaining those relationships through the years that I take the most pride in.