Oct 05

Strategy and the Startup

Posted on by

In my career, I have worked for large (Fortune 500) and small (startup) companies and everything in between.  Today, I focus on a startup I co-founded with two colleagues that will illustrate the value of strategic thinking.

Two colleagues from my Executive MBA class approached me after graduation about helping them with their video hosting startup.  All that they had at the time was a prototype web page with a few croud-sourced videos, and a strong idea.  I liked the idea, and my friends, so I offered to help.  I said, due to IRS rules for Self Directed IRAs, I could either invest a small amount, or I could become involved directly, but I could not do both.  They chose the money.

I did not think that their idea, and their skills, were strong enough as it stood for this to be a good investment, so I explained to them how I could help them with a better chance to be more successful.  I brought a skill they did not have – online (Pay Per Click / Adwords) marketing that I had developed from my time with the Real Estate company Home Expo Gallery, and I would help them craft their business plan seeking investment (I was the strongest writer in our class).  If it worked, I would get a percentage of the company.

My business plan outlined 3 new products to add to the one they already had, but it made no sense to market products online that did not yet exist, so we had to find an investor to fund the development.  Reaching through my network of contacts, I found an entrepreneur who had sold his business, but was willing to introduce me to his Angel Investor.  We met with him and presented my business plan.  He was impressed with the plan and the background of all three of us, and he had a friend who needed exactly what we were offering in the plan (one of the three products that did not yet exist).

The investor brokered a meeting with his friend, and at the end agreed to fund the development of the new product in order to help both of us.  He also contributed a lot of good strategic ideas that ended up guiding the product known today as the Private Media Channel.  I designed the Minimum Viable Product and the other two went off to get it built with their development staff in India.  As is my hallmark, we delivered on time and on (actually in this case, under) budget.  We jettisoned the other three products to focus on the one we had actually sold.

Over the next 6 months, via cold calling and reaching out to our Friends and Family network, we managed to acquire one more customer.  During that time, we were focusing on the business plan and marketing materials.  We presented the plan at competitions and won three of them (in the top 3 of two others).  We clearly had a good plan, but were failing in execution and in attracting investors.

Then I started the online marketing campaign with the left-over initial investment.  Let me state from the beginning, I am not a marketer and only know what I have learned through trial and error – but I was the only one in the company who knew anything about it, so it was my job.  I won’t go into great detail about the campaign, other than to say it started very unfocused (shot gun), and narrowed over time.  But it worked.  In 4 months, we had 32 customers.  We were literally doubling every month.  Then we ran out of money.  We switched to the principle of “Content Marketing”, and continued to grow (very slowly) over the next two years to about 50 customers organically with no marketing spend.

As with any startup, we all played multiple roles.  Mine were Marketing, Sales, Product Management , and Customer Service (hence, “Chief Customer Officer”).  The CEO managed to find additional small seed funding to keep things going through the troughs, and the COO managed the financials and the development organization that built and continues to support a stable product.

At this point, we had reached break even (even a tiny $500 profit in one quarter) and the business was self-sustaining.  Without marketing funds, we were never going to gain meaningful traction and we were unable to convince investors, based on the track record thus far, that we could come up with a plan that would yield investor-inspiring results.  The standard chicken-and-egg.  At that point, I had to focus elsewhere and left.  I’m still an owner and on the board, and peek in from time to time.  The company is still self-sustaining, and still not growing meaningfully.

So, the business never achieved greatness.  What’s the point of all these words?  Did I fail?  Well, yes, in a sense, I did.  I was unable to market the product over the chasm to market acceptance.  But my strategic contributions (alternative products, angel investor, business plan validation, minimum viable product) were all critical to the fact that the company still exists today and reached a stable state.  Imagine where it could have been today if we had managed to get meaningful investment.

Sep 20

Driving Strategic Direction

Posted on by

I have been branding myself with the tag line “Driving Business Strategy with IT Strategy,” so it seems that I should talk about how IT strategy can drive or enhance the overall business strategy.  My previous post on strategy talked about creating a new product line that the company could sell, and thereby generating an entirely new market.  Although we were building it anyway, it became a new capability driven by IT that changed the overall strategy of the business.

In this post, I want to talk about a somewhat different situation.  A mature and solid, large company that I will not name lest their Reputation Bots swarm me, makes hardware and software components for the Freight Rail industry.  Among the reasons I was hired there was my deep knowledge of Positive Train Control (PTC), a critical project in that industry.  This company did not make PTC components, but did make the locomotives on which they were installed, and many components in the locomotive network interacting with it.  Not only did they not make PTC components, they had made the affirmative decision  to avoid offering those components.

In the course of my other duties, I just happened to learn that a key technology foundation of PTC was being deprecated by the vendor in around a year.  This naturally caused a rather large concern within the Freight Rail industry as it was the backbone of the necessary interoperable communications.  Other vendors to the industry provided the components that used this technology, and they suffered from a terrible reputation for quality and service – two of the strengths of the company I worked for.

The company had avoided this market originally because they did not have the in-house expertise to develop the necessary cards and software – a lack they had remedied over the years – and because they did not want to assume the safety liability – imagine two trains colliding because of a bug in this software and killing dozens of people.  Current vendors in this space were protected from that liability by simply being too small to pay any judgment, so they would go bankrupt.  This company had deep enough pockets to need to pay out any liability judgment.  They were, however, familiar with this level of liability as their engines keep passenger airlines in the air.  The real question was: Would the market generate enough revenue to be worth the liability risk?  I took on the task of finding out.

I will not reveal details, but the total market was over 9 figures in 3 years.  That was enough to justify the liability.  The technical hurdle had been solved over the past 4 years.  It would be a very hard project, but the payoff was there.

As I was building the business case, the original vendor of the backbone technology decided not to revive the product, but to extend the maintenance of it another 3 years.  This did not remove the problem, but it made it less urgent.  When I presented my findings and plan, my company decided to use this development as a reason not to pursue the new product line.

Now, let me set the ambient environment.  They had staffed up based on a projection of 20% or more revenue growth per year for at least 4 years.  Instead, they had just lived through a 20% down year and current revenues were indicating yet another 20% decline.  A 9-figure new product line would have erased all that.

IT had developed a new capability that could generate a previously untapped revenue stream in a critical time when they needed it – IT Strategy driving Business Strategy.  Unfortunately, those in charge of the Business Strategy could not see it.  End result?  Significant layoffs making news.  Their competitors may not be so short sighted.

If you are from the company I carefully avoided mentioning, please do not sue me.  Like those other vendors, I have no way to pay a judgment – and these statements are simply my personal opinion and reflect the official position or opinion of no one else on earth.

Sep 14

Strategic IT Thinking

Posted on by

When I started my MBA, one of the goals was to move from a Tactical thinker to a Strategic thinker.  The career coach they assigned me surprised me by pointing out that all my assessments said I already was.  I thrived in the three strategy courses that Georgia State University had in the curriculum for our Executive MBA class and began to see what he was saying.  I had moved into the strategic realm for a few years by that point without realizing it.  But how do you explain to an interviewer that you are strategic?  Perhaps with stories?

I think the best example is one of my “Bet the company” or “burning platform” stories from a while back.  The software house I was working for at the time, managing a branch office, had a single product.  A vertical software suite for managing fleet and facility logistics and maintenance.  It sat on top of a dying (burning) platform called SPEED II on WANG hardware – has anyone heard of these anymore?  Dead.  In the death throws of this platform, the company could no longer sell its only product line.  It had to migrate, and fast.  The president of the company flew up to my branch and asked me to lead the project to re-platform their application suite onto a new technology.  One that was completely incompatible with their existing platform.  Sales had dropped 90% and they needed a new platform NOW.  So I came down to lead that project.  Still tactical, right?  Yep.

It was a massively complex project and I had about a quarter (in the end a third) of the company working for me on it.  We had to figure out what the dying platform was giving us that the new platform currently could not, how to build those features, then how to automatically convert the very large code base into that new platform.  This is the product that became Xponent – a case tool now in use in 56 countries.  But wait, the goal was just to re-platform the vertical application…

Along the way of building this new platform, I saw how we could make this a marketable tool that would save other software vendors in the same situation.  Our tool could either become an in-house proprietary tool for building the flagship vertical product, or it could become a product in its own right and provide an entirely new revenue stream for the company.  But in doing so, would we enable our competition to beat us at our own game?  I looked at that and decided, no that would not happen.  None of the other software houses played in our company’s market or had the deep expertise to establish a solid enough reputation to sell it once built.  So the company went from one dying product to two marketable products – one slightly crippled as it took time to evolve to the new platform, and a vibrant one with a small but hungry market – and completed first commercial ship of both products in 9 months.  That, to me, smells like Strategy.  And this was a decade before my coach made his “odd” comment.

This sounds like bragging, but the company would not exist today if I had not succeeded in both products.  I do not mean to imply that I am the only one who could have saved the company, it was full of bright people or they could have gone outside.  But the success of my project did save the company.

Sep 07

Crisis and the Blame Game – Stories from the Cauldron

Posted on by

Over my career, like many of you, I’ve had to manage crisis situations.  The “Customer” database goes down and the company cannot process a single transaction involving any customer – online, on the phone, in person…  An earthquake destroys the data center…  Everyone’s had their moment in that critical spotlight.  I thought I would take a moment and illustrate some of the approaches I’ve learned over the years.  I do not hold myself out as a shining example of a crisis manager, but these tools have served me well.

Manage Your Stress

A crisis is by definition stressful, and some people handle stress better than others.  A friend of mine long ago told me a story that I re-play in my mind whenever I feel the stress getting too high.  I also use this story to mentor others on managing their own reactions to stress.

My friend was a part-owner in a software company in South America (that he referred to as a Banana Republic).  They had made the mistake of bidding on, then winning, the job to process the election results for President of the country.  It’s election night, the polls are closing, and the software is not working.  In walks the current President, with his machine-gun toting entourage, saying “I need to know if I’m going to be President tomorrow.”  Then he points out the window, saying “You see all those people in the street with their Molotov Cocktails?  Their pretty interested in the answer too.”

Now I embellished the language a little bit to make it more “pithy”, but the situation was quite real. The potential for a civil war, people will die, if your software doesn’t start working REAL soon.  THAT is stress.  The fact that your company is losing a million dollars a day because the website can’t take customers is, by comparison, NOT.  It also keeps me thinking that I’ll make better, more rational decisions, if I don’t become overwhelmed.  That will resolve the situation sooner as well.

Oh, and my friend?  He “managed” his stress well enough to get the software working so that they had a result 2 hours after the polls closed.  He never did tell me who won. (smiley).

The Blame Game

It is a common reaction (I won’t use the word “normal” for this situation) to begin a circular firing squad in a crisis.  It’s not MY fault, it’s YOURS.  This accomplishes nothing except delaying getting to the solution – even if you have found the right person to blame.  I was on a disaster conference call with that “Customer Database Down” situation where the company was losing about a hundred thousand dollars an hour.  The round-robin blame game started.  When, after two minutes, it was clear that it showed no signs of stopping, I raised my voice on the conference bridge.  “Enough.  It’s all my fault.  I caused this.  Blame me.  Now let’s start figuring out how to fix it.”  15 seconds of dead silence was followed by “well, has anyone thought of this idea?”

Blame has no place in crisis resolution.  Save it for the Lessons Learned session after normal operations have been restored.  Even then, blame the process that allowed the mistake to occur rather than the employee who made it.

Creating Order from Chaos

A crisis easily devolves into chaos unless the team is well practiced in dealing with crises.  If they are, then crises likely happen way to often.  Beyond solving the immediate problem, preventing its recurrence is a secondary priority – but one that is often lost in the chaos.  Attempting to instill order or process during the crisis is often as counter-productive as the blame game, the wide-ranging creativity that results from an unusual pressure situation is needed.  During the fire-drill, however, the critical gaps and flaws in normal processes that allowed the crisis to occur can be glimpsed – and missed if not noted contemporaneously.  These are the best possible fodder for the “Lessons Learned” meeting afterwards.  Don’t ignore them, scribble them down somewhere for later thought.  One or two might turn into a rabbit hole later, but there will be gems in there.

Common wisdom has it wrong – Focus on the problem, not the solution

It is common for a theory of the problem to emerge and most everyone gets focused on solving for that theory.  Some percentage of the time, that theory will be true and the problem solved quickly.  Some percentage of the time, that theory will be wrong and all the time spent on the “solution” will be wasted.  When a team is working on implementing a “solution”, make sure that there are others on the overall team who work on the assumption that the “solution” is false and more investigation is needed.  Look everywhere EXCEPT where the solution team will be looking.  Have no pre-conceived notions.  Assume this is the first-ever occurrence of whatever caused the crisis and that it is something no one on the team has ever dealt with before.

There are many other good tools useful in crisis situations, but I’ve written more than enough for today.  No one wants to go to a blog and read an entire book.  I am also sure that readers of this article will have dealt with other types of crises with other types of tools – or even run into situations where my tools would be worse than no tools at all.  I hope you will share those experiences, I’d love to learn from you.

Dec 27

Following your Bliss…

Posted on by

Recently, a colleague of mine presented me with a problem.  I’ll anonymize him and the company so as to avoid embarrassment of either.  Joe is a clear expert in a specific technology that is becoming critical to the way the company will develop its software going forward, and was hired specifically based on this expertise.  Walking in the door, he was one of the top three experts in the company on the technology that everyone will end up needing to learn.

Every organization has a distinct personality and way of doing business.  The company in question allows teams great latitude in how they will accomplish the goals they are given.  While this new technology is pivotal to the way the company will operate in the future, it has a very weak mandate.  Adoption, in accordance with company personality, is based on “convincing” the team that the approach is the correct one, not mandating adoption.  If the technology is truly right, we should have no trouble convincing people.  If we can’t convince people, maybe it is not the right choice.

Joe expressed his frustration at not being recognized for his expertise and the fact that the project team to which he was assigned was actively ignoring his input.  In this assessment, he is absolutely correct.  His evaluation of his personal worth is based on his technical ability and the respect he was shown.  This culminated in his statement that he is finding it challenging to motivate himself to come to work every day.

Joe comes from a different organizational culture where his position carried with it the authority of powerful sponsors.  He has not had the need to earn his way to respect, it was handed to him with the positions he had over the years.  Hence the frustration.  His ideas are right.  The team should adopt them.  But they are allowed to say no, and they are doing so. 

I recognize that the organization needs to adopt this strategy, but that politics dictates a more subtle approach.  I am keenly aware that we, as an organization, need both the enthusiasm and the expertise of this individual.  However, if things continue the way they are going, both of those needs are in jeopardy.  The more the solution is pushed, the more reverse psychology will ensure that the new style is not adopted.  The stronger this individual pushed for his ideas, the more he threatens his own position.

So, I took it upon myself to counsel Joe.  I explained that I had been in his situation where I had strong authority, and where I had none.  I pointed out that his problem with motivation stems from tying his identity and worth to the technical solution he was proposing rather than his personal skills as an architect and leader.  If you come to work every day not with the goal of accomplishing a given task, but instead with the goal of improving your personal worth using the technical challenge as a vehicle, life becomes exciting.  You never know what’s coming around the corner, and you have the constant interesting challenge of how to adapt yourself to whatever life throws your way.  If you do your (redefined) job right, all the right things begin to happen of “their own accord” and you have all the success metrics you need to prove your value.   On top of that, you no longer need to prove your value, it becomes obvious to all those around you.  And even better than that – you are following your bliss every day by finding more reward in everything you do as you craft a better you.

My efforts with Joe are still a work-in-progress, and I will share what works and what does not here in this forum as we journey through this together.  I would love to hear your thoughts and suggestions that might help my colleague and me through this discovery process.

Oct 25

Creative Geekdom

Posted on by

In an interview a few years ago, the interviewer asked me to list some traits by which my colleagues would describe me.  I mentioned “creative” as one of them.  As you would expect, the immediate follow-up question was to provide an example.  I stumbled and fumbled, I drew a complete blank.  The interviewer certainly thought I was simply blowing smoke, that I wanted him to think I was creative when I wasn’t.  The honest truth was that my colleagues did (and still do) call me creative, but I never looked around to see why.

So, I spent some time thinking about it – was I really creative?  I’m not sure, but at least I can think of an example or two of something creative that I’ve done.  You decide.

Flashback: Katrina had just pummeled New Orleans.  I was working as a Solution Architect for EarthLink at the time.  The project was Metro Wi-Fi (a Wi-Fi equivalent of Clear’s service model focused only in high-density urban centers), and I had just finished two large Voice over IP rollout projects.

We were all stunned by the scope of the devastation, and wondering how we could make a difference from Atlanta.  Emails started fly around with all kinds of ideas.  Mine was thus: There were no cellular or landline communications in the deepest areas of destruction and people cannot find out if their loved ones were alive.  We were attempting to sell Wi-Fi phones in the cellular market, and we were wiring urban areas with Wi-Fi access points. We had a bus equipped with a satellite dish for broadband unwired backhaul.  Let’s put all that together and drive into the flooded zones and start handing out phones.  I was working side-by-side at the time with the product VP for voice, and we very nearly pulled the trigger until we found that the bus was a thousand miles away and he could not get it redirected for another week.

Had it worked, we would have helped hundreds or thousands of people to put their family’s worries to rest.  EarthLink’s PR department probably would have made sure the company got some credit for it, though that was a very small consideration given the human situation on the ground.

We ended up going with the second option which was essentially a web-based registry of people and where they could be found.  We helped, but not as much as we had hoped.  Do you have a story of creativity?

Sep 20

Managing Chaos

Posted on by

Managers mostly come in two flavors: the fireman and the accountant.  The fireman is a crisis manager.  This is the one you run to when the data center melts down or your product blows up in the face of a child star on television.  They excel at stopping the bleeding by applying tourniquets and enough emergency care to get the patient out of the hospital.  A crisis manager keeps a cool head during all the shouting, ensures everyone is focused on the most important problem, and bulldozes any road blocks that come up.  They are not good, however, at what I call steady-state management.  They get bored, they are addicted to adrenaline.  If there’s no crisis, they spend a little time getting better prepared for the next crisis, then they go to sleep.

The steady-state accountant manager, on the other hand, is keeping things moving day-by-day, and slowly improving the processes to produce more and prevent future crises.  They manage people and processes, not situations.  The accountant ideally thinks proactively, compared with the reactive crisis manager.  The better they do their job, the less you realize their value – or even their existence.  In a crisis, however, they are lost.  They look for what went wrong, where their systems failed them, rather than the main goal of getting back in operation as quickly as possible.  They can often add to the panic rather than push through it.

So where do I fit in?  I’d love to say I’m the ideal mix between the two, but that would just be self-serving and inaccurate.  I do fit in the intersection, however.  I would describe my approach as building order from chaos.  I do manage to keep everyone focused on solving the crisis if one appears, but I don’t make the intuitive leaps that a natural crisis manager can.  When the crisis is over, my first task is to gather Lessons Learned and divide them into two categories: How to prevent the next crisis, and How to respond faster next time it happens.  But unlike the crisis manager, my next step is building the processes to prevent future occurrences along with the plans and tools to respond more quickly to any similar event.  In between crises, my aim is to build robust processes within my group to proactively address future needs and more efficiently produce current results – similar to a steady-state manager.  I will admit that focusing on the detailed minutia of minor incremental improvements, where the accountant shines, is where I begin to lose some interest.

Where is your sweet-spot in this spectrum?

Jun 18

IT Management, Herding the Cats

Posted on by

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

Posted on by

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

Posted on by

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.