I had been invited to her office to discuss strategy.  This CIO had been in her position for about 10 months.  She had been struggling with implementing her vision.  She wanted my opinion on how to kick start her stalled strategic plan.

She told me about all of her objectives and why she wanted to do them.  She presented how they would benefit her company.  She then asked the question “If you were me, where would you take the organization?”

I replied “Tell me about the history of your IT organization.”  She responded “I don’t want you to advise me based on the past.  I want to talk about the opportunities in the future.”

I paused for a moment and said, “If we don’t talk about the past, there is no way to roadmap the future.  Otherwise, we would be guessing at what is possible.  Your past is a determinant in what your future can look like.”

In the IT field there is a term called “technical debt.”  This means that an organization can build up a liability as a result of an aging infrastructure.  When a CIO takes the reins of an organization they inherit this “technical debt.”  It is a fact of life.

There is another reality that is even more powerful than “technical debt,” and that is the concept of “historical debt.”  This is also something a CIO inherits when they come into a position, yet it is not as widely discussed.  This is the political liability that has built up as a result of the decisions of that organization’s past IT leadership.  This debt is more subtle to identify and more complex to solve.  As compared to the science of paying off “technical debt,” paying off “historical debt” is an art.

Those CIOs who disregard this reality do so at their own peril.  It must be addressed especially when considering a relationship with the business.

In The Tech BuzzKill question number six in the interviews was related to the barriers that IT faces when it deals with the business.  Almost 100% of the interviewees spoke about past events that created barriers.

For example, one CIO came into an organization only to discover that his predecessor was known as the “See I Know.”  Apparently, the former CIO thought he knew everything and would try to dictate to the business what was needed.  That CIO met the predictable fate.

Another CIO inherited an organization that was modeled to be technical only.  There was no business focus.  IT had the stigma that IT was a bunch of “technocrats.”

In each case, the business had shut down the relationship with IT.  It was evident that IT had a political liability that each incoming CIO had to address before real progress could be made.

This was the case for the CIO that had invited me in to discuss strategy from the story in the beginning of the chapter.  In that CIO’s case, the organization she inherited had a conventional IT model that was not bringing new ideas to the business.  IT was seen as too costly (another common barrier for IT), and they were in the habit of being “order takers” who had “no choice” but to say yes to every request.

When that CIO came into the organization, she made the mistake of pressing too fast to implement a vision of IT that she had formed prior to taking the position.  Her vision was perfectly legitimate, and quite candidly was a modern vision.  However, the organization in which she was trying to implement it was not ready.  She violated the cardinal rule of relationship: she did not deal with people where they were at.

These examples are precisely the reason why background matters when dealing with the business.  No matter how elegant, articulate, smart, or advanced a leader is, they cannot make the business forget the past.  Only time and performance can do that.  So, strategies need to address multiple things to launch a business relationship model.

When CIOs implement a new business relationship model they have a once and done opportunity.  They do not have extensive runway for mistakes.  They have to get it right quickly, or at least show progress quickly, or suffer the fate of many, and that is irrelevance, or even worse, termination.

Over a year ago I had the chance to sit down with a CIO of a top global consumer goods company.  The discussion opened up politely enough, and after a certain time the discussion moved to IT’s relationship with the business.  I asked about business relationship managers.  The CIO quickly corrected my terminology.  She asked me not to use that word in the organization.  She said the business had a poor view of Business Relationship Management (BRM).  Why?  Because of a failed launch by the previous CIO.  She admitted that BRM was needed, and she was absolutely implementing it, I just was not allowed to use the term.

CIOs who succeed in business relationship survey the situation before acting too quickly.  They don’t rush into models only to realize they are not achievable in that organization.  They realize that mistake is a ‘toothpaste out of the tube’ moment, and it is hard to put back in.  This situation is to be avoided at all costs.

There are several areas that a CIO should consider before choosing their business relationship roadmap.  These include:

• Current Organizational Structure;
• The Leader IT reports into;
• The Talent of the IT team, specifically its VP and Director Level team members;
• The track record and history of the past several CIOs;
• Industry and Regulatory Environment;
• The business’ current interaction levels with IT;
• Finally, the perception the business has of IT.

Current Business Relationship Model

Question number one of The Tech BuzzKill asked each interviewee what their preferred structure was for alignment with the business.  In listening to the leaders, it was evident that structure was the most common alignment tool for leaders.  There were a variety of structures, all seemingly unique.  It was far and away the question that consumed the most time in every interview.

With that noted, the leaders that succeeded assessed their current structure closely before launching into a new model.  Many of them spoke about the business relationship model being an unpublished structure within the structure.

IT leaders most often formally organize for process and operation but in their choice, they also set the business relationship model.  It can be hard to determine where the business relationships are within IT, even for a CIO.  So, a close analysis must be done.

First, the CIO should confirm the documented current IT structure.  If the recorded org structure they have seems inaccurate, it is imperative to address it and bring it up to date as soon as possible.  Get it published and review it.  Ensure all levels down to manager are visible[1].  Often times, the business has relationship with manager level team members and without this view, a leader may miss a detail that is important.

One trick that can be used to accelerate a review of the structure is for the CIO to analyze a version of the org chart with the years of experience with that organization of each team member in the org chart.  Those with a lot of years may certainly be a team member the business leans on even though it is not part of the formal model to do so.  This helps the CIO assess pockets of pre-existing relationship that might make up “shadow BRM.”

Second, the CIO should then confirm the documented business org structure.  Determining how the business is organized will make the next step worthwhile.

Once the CIO determines the ‘who’ in the relationship (the structures of IT and the business), they can then see the ‘how.’  The CIO should compare the structures side by side to see where the business and IT structures map to each other.  This analysis will be critical when utilizing the structure levers (to be discussed in later chapters).

Relationship structures vary widely, but they most commonly fall into one of three categories.  The structures are either functional, business line focused, or regional unit/profit center focused.  This is a critical understanding in forming a business relationship roadmap.

Figure 1: Conventional IT Structure #1.  This shows applications, Enterprise Services, Infrastructure and PMO as dedicated branches.  PMO is the one function that will vary.  Governance is listed as an assistant organization to the CIO.

The most commonly seen model is the IT organization set up into a functional structure which emphasizes capability centers such as (primarily) applications, infrastructure, governance, quality, enterprise services, and PMO (See Figure 1).  These functional towers are the mechanisms used to align with the business.  Most commonly the alignment would be in the application tower of the structure, where the applications are owned within IT.  Since the applications are supportive of business functions, this is where IT can support and mirror the business structure.

The second commonly seen model is the business line model.  This is where IT organizes its application tower according to business lines.  So, for example, a healthcare company that has offerings in payer, provider, and life sciences might model each with its own substructure in the application and support areas.  (See Figure 2 ).  The business relationship would be set up in the business line branch of the IT org structure.

The third most commonly seen model is the regional or profit center model.  This is an IT organization structure that recognizes the independence and custom needs of a specific region or profit center.  So, to be sensitive to these needs IT creates a branch of the org chart for each center.  This will minimally include applications, but can also include PMO, support, and in some unique cases, application development.  This model would utilize a regional or profit center IT head as the Business Relationship Manager (BRM[2]) liaison.  This is most commonly expressed by using a regional CIO or a departmental CIO.  (See Figure 3).

The Leader Into Whom IT Reports

During the writing of The Tech BuzzKill I asked all of the leaders into which executive they preferred to report.  The answers varied.  Most said Chief Executive Officer (CEO).  Some said Chief Operations Officer (COO).  A small number said the Chief Financial Officer (CFO).

The reasons the answers varied among these three executives had nothing to do with personality.  The CIO didn’t pick CEO because they liked Susie better than Joe.  The reason for the variation is because each C-level leader accentuated a different focus.

In the eyes of those interviewed, the CEO most often emphasizes vision.  The COO most often emphasizes operational efficiency.  Finally, the CFO most often emphasizes cost control.

This emphasis affects the business relationship possibilities.  CIOs will often be pressured to choose a structure that is preferred by the leader into whom they report.  Although each C-level leader that IT reports into might say it is the call of the CIO, there is something unrealistic about that.  No CEO who is trying to transform an organization will tolerate long an IT organization that does business as usual and can’t scale to the need.  No COO who is trying to run a smooth operation will expand interaction points from IT to the business so that “innovation can be improved.”  No CFO who is worried about profit will tolerate long an IT org model that is burdened with “relationship” cost.

The leader the CIO reports into also affects the empowerment of the CIO.  For example, as noted earlier, it was rare that the leaders interviewed in The Tech BuzzKill preferred the CFO as their direct reporting relationship.  The reason was that most did not feel they could do their jobs well under a cost conscious leader.  This reporting relationship manifests itself in real ways, most notably budgetary signing authority.

The Talent of the IT team, specifically its VP and Director Level team members

A wise CIO once said to me “There are three dimensions of a quality IT organization.  The first is people.  The second is culture.  And structure is a distant third.”  His point was right on.  People matter.  It is paramount to have the right people in an organization.

As Jim Collins said in his best seller Good to Great: “We expected that good-to-great leaders would begin by setting a new vision and strategy.  We found instead that they first got the right people on the bus, the wrong people off the bus, and the right people in the right seats— and then they figured out where to drive it.”

Jim’s observation is the exclamation point to the analysis made in the introduction of this book.  A CIO must look at building the business relationship as a lever pulling, game time activity, and not a sequential set-in-stone plan.  One of the key elements (and one Jim Collins would suggest is first) to ensuring success is having good people.

A CIO must assess the talent on the team.  This goes beyond technical and management experience.  The CIO must assess the team for the ability to know the business and relate to the business team members.  No matter how much technical or management experience an IT leader has, unless they are able to relate to the business their goldmine of skills is in vain.

Therefore, the CIO should review the org chart that was created and refined and review each team member down to the director level.  The review should include a personal assessment as well as an assessment of how the business perceives that team member.  This is not to suggest a formal survey.  The CIO must find alternative means to gain that information.  A caution: A CIO should not automatically assume that a staff member that has a negative perception with the business is not able to relate with them.  The negative view just may be because that team member was aware of best practices and tried to hold true to them when IT in general was not.  The presence of a negative view may just be proof they are a keeper.

The Track Record and History of the Past Several CIOs

Remember the story of the CIO who did not let me say the term Business Relationship Manager in her organization?  She was a victim of the errors of her predecessor.  She was in a position that required her to repair the relationship with the business while positioning for the future.  She had to do this at a time when IT’s perception was in the dumps.  Her request of me not to use a phrase that was politically charged was appropriate, and a good example for all CIOs.

Whether we like it or not, the past does affect the present.  In IT, this is especially true.  The business deals with IT based on the old adage “past performance is the best indicator of future success.”  Each and every business organization reviews IT in this way.

As a result, CIOs need to thoroughly understand how the past CIO was perceived before they embark on an active strategy.  There is one surefire way to learn this: seek active interaction with the business.

When this is done the business will start dropping comments.  They might seemed surprised that the new CIO is around so much.  Or, they may suggest that the new CIO not come to every meeting (a sign they want to keep IT at a distance).  They may even put the new leader off entirely.  In all cases, the new CIO will get a quick view of how the past CIO (and IT) was perceived in that organization.  The past perception is the perception they inherit.  If trouble is indicated, the CIO should delve deeper into what the cause may be.  If they get interaction, use it to learn more.  Either way, action is the best mechanism to flush out issues and their causes.

Industry and Regulatory Environment

When a CIO embarks on Embedded IT, they have to consider the IT structure to determine the best model with which to embed.  Embedding requires people, and people make the structure.  It is that simple.

With that said, structures are affected by the industry in which they serve.  IT structures that align to the business must align in the way the business structures.  Naturally, the business structure will affect the IT structure.

Regulation affects business structure.  Whether it be because regulation caused a spinoff of the business for tax reasons or oversight reasons, or because state laws require a business unit be incorporated in that state to do business, increasingly business structures change to accommodate or avoid regulation.

For example, a healthcare provider with many regional hospitals that are in different states will require some autonomy in each state.  As a result, each hospital or system would likely have its own executive leader.  IT will often mirror this model by creating a regional CIO.  This regional CIO would report into the overall CIO, but their greatest responsibility is to the regional business owner.  This allows for tailored service, and it also allows for consideration of regulation differences over state lines.

These two points and supporting examples illustrate the need for CIOs to understand their regulatory and industry environments before fully embarking on their embedding strategy.

The Business’ Current Interaction Levels with IT

Recently, I had the opportunity to work with a CIO who was crafting an embedding strategy.  His initial idea was centered on moving his organization into an agile structure using agile development.  His rationale was sound.  He had felt the business was continuing to be disappointed by what was delivered by IT, and their chief objection was that they only see it at the end.

There was one problem with this CIO’s approach.  The cause of the issue was not all IT’s.  Apparently, the business was in the habit of throwing a project over the fence at IT.  Since it involved technology, they would be absentee stakeholders, thinking IT would get the job done.  So, their interaction was low.

In addition, the business felt it was over tasked and did not have time to work on IT projects.  So a middle structure between IT and the business was created.  This group of “business representatives” were supposed to act as a go-between for IT and the business.  Instead of being a go-between it created a “no-between” scenario.  The business and IT did not interact frequently.

When I heard this, I advised the CIO not to embark on pure agile too quickly.  I suggested he needed a plan to move the business along.  If he were to implement agile, the business would rupture, as they would not engage.  It was too much of a leap for them.  As such, it would have produced the exact opposite result than the one for which the CIO was looking.  The CIO eventually landed on a version of “agile-fall” to proceed to the final goal.

Each CIO needs to assess the current climate of business interaction before structuring an embedding model.  We have all been with people who have screamed for attention only to get it and then complain they are being smothered.  This can happen in organizations as well, and especially between IT and the business.  It is incumbent upon the CIO to determine interaction readiness.

[1] For the very largest IT organizations this may not be possible.  The point is to document as low as possible.

[2] BRM Acronym is used for both Business Relationship Management and Business Relationship Manager