Talking to a few CIO friends on the much debated and discussed subject of “what next” for us, the CIOs, many aspired to be CEOs. Now that is a good thing given that CIOs are setting their goals high; some are also achieving it within IT companies, a few in other industries too. Making the transition was possible for them as they graduated from technology enabling to business enabling to business itself. Their leadership was acknowledged and when the opportunity arose, they were considered rightful choice.
Emerging as a leader
Trust and respect from peers is garnered step by step everyday with the word and the deed. Conviction that comes out of past experience, the ability to consistently deliver against odds, the cohesion of the team in committing to the stretch and unreasonable, the ability to engage in conflict resolution focusing on the issue and not the people involved. They are always happy to help, sometimes even with personal sacrifice. This separates chalk from cheese.
You would say that this is just a sample of everyday behaviors that make a successful leader and CIO; it is also shaken quickly with hearsay and frequent missed steps. Respect is always earned, rarely conferred if at all; it comes out of consistency in delivery, walk the talk, articulation, coaching and mentoring others selflessly. The mojo develops with practice and stays with them as long as they continue to stay grounded through the journey. Nothing new here too? Hold on a bit.
The gap between perception and reality is based on the demand supply management between IT and business. When CIOs manage this well, they remain relevant to themselves, the business and the enterprise. The progression is determined by the interventions outside of their realm and “out of comfort zone” discussions. The CXO has no boundary defining Job Description; they only have a primary allegiance to a function.
Path to becoming the CEO
So when a successful CIO asked me the path to becoming a CEO, I wondered what qualified me to give advice? While I am a CIO and have held a few P&L responsibilities in my career, I am not a CEO. Having mentored a few people and learned a few tips from the world’s best coach (Marshall Goldsmith), I decided to probe further. He was determined to get there and was willing to work hard. We discussed his winning formula, did a SWOT, and identified a few behaviors that needed attention.
Defining the road ahead was easier than I thought; crafting the evolution plan took some time and then we agreed upon a follow up plan and progress report. I felt humbled by the experience, his faith in my words, and suggestions on his actions which he ardently believed will get him to his goal. Reflecting on what my virtual guru referred to, “I don’t coach losers because they are not willing to change”, I too believed in his plan and hope as he was willing to change. I believe sooner or later he will get there.
And then last week someone asked me the question, “When will we see you as a CEO?”, I started wondering if I should be reading more into these questions and discussions! Flattery is good, but it should not be taken to heart lest the fall hurt the inflated ego!
Every enterprise has an IT function though the name it goes by may be different. Not many call it EDP or MIS anymore, IT is the most prevalent, BT is catching up and there are a few variants which I wrote about sometime back. Similarly the title of the leader has manifested itself in many ways, CTO, CIO, Head, GM, VP, SVP, EVP – IT and some not so common ones that are either legacy, futuristic, or far removed from convention.
Every person in the enterprise has a view on IT and the persona it represents; this is determined by personal experience and hearsay. Sometimes it is relative to past experience in other companies, in most cases it is based on (un)fulfilled expectations and the buzz in the company. The industry, its associates and partners add to or confuse the perception with their views. CIO and the team collectively are thus labelled based on these facts, experiences and views.
CIOs and IT organizations like all beings driven by Maslow’s hierarchy yearn for acknowledgement and recognition. They work hard to create their aura and earn respect with solutions and dialogues that demonstrate understanding beyond technology. They walk the talk, meet customers, and engage with stakeholders to stay ahead in the race. In many cases they succeed in creating a lasting brand value, in few they remain challenged despite doing everything right. Why?
The basic foundation of IT branding happens every day with desk side support on the laptop, desktop, printer, application, network access, email, and various other things that we take for granted. No one cares until something breaks and that incidence ends up being the tag by which IT gets labelled. One incident gets extrapolated to generic statements of (in)efficiency. Some IT organizations have active communication processes to manage this; most don’t leaving a wide gap on how they are seen.
How many CIOs invest in building the brand they and their team represents? Business IT Alignment (BITA) is not only about projects being executed or the discussion the CIO has with the Management teams. BITA happens every day with every interaction anyone within IT has with any other non-IT person (normally referred to as user) within the enterprise. This cannot be left to passive management; it has to be actively managed across the levels.
External branding is another aspect of visibility and credibility that requires a strategy and plan. Go to any conference, event or panel/ roundtable discussion, you will find the same old faces on the stage. It would appear that CIOs were born with stage fright; most are happy to be part of the audience, their views rarely get aired (everyone has a view). Nowadays social media and internet presence too contribute towards the identity of the CIO who represents the IT success of the enterprise.
The combined persona is finally the way s/he is portrayed to the world at large. If the CIO does not actively manage this, it will be managed by forces that s/he does not control. The CIO could then just be an entry in a database or one of the featured ones in a search. If people read about you and read what you stand for, your views on varied or specific subjects, it adds to the perception of who the person is. Some manage this well, the rest leave it to divine intervention.
I believe that CIOs should invest in building the brand not just internally, which is easily done by constant communication and discussion beyond transactions. They should also actively manage their visibility and branding across the IT industry and their chosen industry; participation in industry specific events, membership to bodies, talking to tech journalists and participation in social media make a great combination to get started. Is there more? It all depends on where you want to go!
“I don’t have time” is the first lament (please read ‘Being Busy‘), “how do I get started” is the second; ask the ones who have made it or wait until I write about it.
Last week, one of the global IT biggies invited a bunch of CIOs to their R&D Center with the defined agenda being a discussion on future trends and movements in their technologies; the idea was to get some early traction with old and potential customers and field testing that helps fine tune a product. Apart from all this were the good old peer networking and some high spirits if you know what I mean. So I was enticed enough to join the group to give away a weekend in the name of learning and networking.
CIOs in captivity!
Like all such gatherings it was a good start with key leaders and guys oozing tech from their ears talking about new disruptive technologies are coming our way in the next 2-4 years. They held sway in the graveyard sessions post-lunch, with sleep overpowering only the infirm or the bored indifferent (which did not matter). Most cynical CIOs on the wrong side of forty acknowledged the prowess and the future opportunity. Good things don’t last and this one too didn’t.
After the first two sessions started the mundane, the irrelevant and the hard sell; data center density, cooling, and power consumption. Virtualization and private cloud are good, a higher virtualization ratio even better, but 20K VMs in a rack? Why do I need 20K virtual servers? The nail in the wall was when someone decided it’s a good idea to teach CIOs how to configure a VM and then move it across racks with no downtime. I am not sure if CIOs want to be doing that or enterprises want high cost CIOs to do that!
I mean does a CIO teach the technology architect the finer nuances of VM management? To rub salt into the wounds, they extended the session over the coffee break to cover private cloud extension to the public cloud. Now I am sure that my server admin would be kicked by this demo, none of the CIOs in the room were. They expressed their displeasure in no uncertain terms, some decided to leave the premises as soon as the break was declared closed. Patience too has its limits.
The point of culmination
The climax was waiting for the following day; a visit to the R&D facility! We all got into a bus, arrived at the big building, signed in with sobriety and were taken to the show. We entered a room with biometric authentication to be faced with rows and rows of racks with cables dangling from some. Proudly the scientist pointed to one of the racks and started talking about why it was different and the innovation that went into making the hardware inside and why we should immediately order it.
I could not remember the last time I had visited a data center (even my own); digging deep into memory it dawned that it was more than a decade back. I whispered to the CIO next to me and he too reminisced a long time back. A few others had been to their outsourced or co-located data centers when they had signed the deal. I wished my infrastructure head was present; maybe he would have appreciated the significance. To us, the CIOs, it was a lost experience, we did not share the enthusiasm.
Does or should the data center matter to the CIO? The vehement answer would be ‘yes’ from many. Then what about the cloud? Have you visited the Google or Amazon or Salesforce.com data center? Do you know when you buy SaaS where it is delivered from? I believe that we need to come out of this obsession; the vendors need to start defocussing the data center and start engaging on business outcomes. Yes, the data center makes the IT run, but to pick a line from Nicholas Carr, the data center does not matter anymore!
When I wrote about requirement gathering versus solving business problems last week, I did not anticipate the kind of comments I would get. The agreements and flurry of lateral thoughts gave me enough impetus to continue the chain and focus on some of the views. Almost everyone agrees that we need to solve real business problems; the challenge is the definition of the business problem and changing the mind-set of our customers to stop thinking about technology and really tell us about what they want.
We talk about IT folks not speaking plain English or Spanish or whatever is the lingua franca, business tries to talk IT lingo and confuses the blazes out of the Business Analysts. Every industry has its slang and acronyms that add to the confusion (domain experts know this, but keep quiet). Between the domain expertise and the attempt to straddle the gap, the real problem gets lost in the chasm or some finer nuances remain uncovered. This then leads to what we classically refer to as out of scope functionality or scope creep.
The word creep somehow makes my hair stand up, that is the way of creepy guys or gals. Scope creep however indicates that no one articulated the problem or thought that it was unimportant or irrelevant to the discussion or just simply forgot to talk about. There are also instances of assumptions where the giver assumes that the taker has the knowledge by virtue of it being public domain or so obvious that it does not merit being explicitly being specified.
Translated to a document which the developer (read coder) in some faraway place sitting in a cubicle totally disconnected from the discussion is now writing the software that will be put up to the business. S/he does not have domain expertise and depends on the document to decipher what should be. We all have faced the end results that have missing pieces and functionality since it was not captured. Even when the development is undertaken internally these gaps exist albeit to a lesser extent.
So now the IT team gets beaten up and the Business Analyst bashed up for not translating adequately the business problem. Then the dance starts on what was said, how it was interpreted, and why does not IT make efforts to understand business. Escalations get nasty with the CIO having to face the music. While I generalize the problem, I have not come across too many instances of stupidity or wilful exclusion of documented features or functionality.
The skill of the Business Analyst to ask the right questions and probe are critical to the definition of the problem and thus the document that becomes the Holy document on which the system will be based. Leave out anything and you have a system that does not meet requirements thereby giving rise to “change requests”, the bad word for any developer, business user, IT team, CIO, CFO and whosoever is a stakeholder in the success of the solution.
Is there a way out? I believe that the CIO needs to play an important role in setting expectations upfront and defining the rules of engagement. S/he should educate the business teams on the criticality of the discussion and the necessity of clearly spelling out every aspect of the business and process irrespective of how stupid it looks or its obvious nature. A system is as good as the people who define it; trainees and junior staff with shallow expertise will provide only that, an incomplete system. Creepy no?
The journey of a thousand miles begins with a small step; similarly, the development or deployment of systems and solutions begins with requirement gathering. Conventional wisdom has it that IT teams talk to business users to gather their requirements, and then go about creating or finding a solution which fulfills defined selection criteria. When an agreement is reached between the users and IT, the system is then implemented. No user requirement, no solution.
Over the years many research papers have been written on the methodology and science of gathering requirements. Consultants created templates and promised success with common and uncommon sense. It has also been the subject of ridicule with challenged implementations, many of them attributed to requirements either not being articulated adequately or changing requirements leading to scope creep and thus sliding timelines. The most famous amongst these has been the pictorial representation below.
Image courtesy: © Paragon Innovations
When I reflect back on the time I was a rookie programmer, I too went through the journey albeit with not too many such experiences. I remember instances when the disconnect was complete while in many the users loved the solution and the benefit delivered right first time. It never occurred to me at that time to analyse why I got it right sometimes while everyone was miserable in other instances. Eighty percent success was deemed good and that kept everyone happy.
Seeking some expert advice
So last weekend over dinner when I met a CIO who recently inherited a legacy of many challenged projects, I was curious to find out how he planned to overcome history and get everyone moving in unison in the right direction. When he took on the new position, the buzz in the market was that the veteran of many industries and acclaimed implementations had taken on more than he should have. Everyone wished him luck and wondered what went wrong in his previous company for him to take such a risk.
The first month was spent assessing status, understanding and cataloguing projects, getting the team to wake up from inertia, and getting the business teams to start talking. In the company with many custom solutions, there were many stories on what went wrong in the past with fingers pointing at lack of business domain, incorrect interpretation of requirements, discipline, engagement, low skills, sliding timelines with projects not delivering even with 200% escalation in time and budget. The IT team was demoralized and had given up all hope.
Many months into his new role the vendors were on fire hearing about the transformation, change and the investments that had suddenly mushroomed. Old projects rejuvenated, new initiatives being aired; there was a direction where none was thought possible. The story had believers inside as well as outside. Having heard about this I was excited to be in his company to extract some insights on how he went about solving the unsolvable problem.
The CIO smiled at the questions and said, I coached my team to ask all the right questions and did the same myself with the CXOs. He elaborated user requirements will always contain not just what they need, but also what they think they want or should have. The requirements always contain many elements that are nice to have and not necessarily aligned to current reality. That is why they are referred to as “requirements”. So what are the right questions?
Ask the right questions
“What is the business problem you are trying to solve?”, “What will change for you or your customer once you have this new capability?”, “Is the benefit measurable in money or time or efficiency?”. We all ask these questions but not too often; we are happy gathering requirements and then executing solutions which are then sub-optimally used. Requirements tend to get unwieldy with all the exception conditions being mapped; in the end it does not solve the original problem but creates new ones.
Winning teams today do not focus on requirements, they ask the questions above and create solutions that solve real business problems or capture real business opportunities. I believe that the future holds a lot of promise to those who follow the new way of thinking and discard the old requirements lead approach. What do you think?
Earlier in the month I was invited to a session by a senior well-known IT Research Associate who advises many global CIOs on tactical and strategic agenda. He is a good story teller and had the audience of 20 odd CIOs spellbound with his anecdotes, examples and occasional taunts which most took sportingly or sheepishly depending on how you interpret the expressions on their faces. His consistent grouse was that while CIOs have done a lot for enterprise productivity, they have neglected IT productivity improvements.
Internal IT under scanner
Tracing through history he illustrated the role IT has played in enterprise process re-engineering and productivity improvements driven by automation, new tools and technologies, mobile enabling the enterprise, and providing time sensitive information in the hands of the decision makers. However during this era the IT team has not demonstrated commensurate improvements; solutions still take as long if not longer than what they did many decades back. He postulated despite progress across the industry, the in-house IT team has lagged behind by a big margin with no major visible improvements.
He went on to compare internal IT teams with the work being done at start-up and tech innovation companies globally. Across comparison parameters on innovation, time, productivity, quality, or sheer volume of work done, IT departments lag behind. He blamed this on mind set, archaic beliefs focused on process compliance to whatever framework the IT team had adopted. ITIL, COBIT, PMI, CMMi were boon in the past; they are the bane now. Agile development methodologies find rare favor with IT.
A reality check
He did not offer any empirical data or prescription, but no one from the audience disagreed. They sat there silently reflecting on their own realities. Post the hour, I sat ruminating over the discourse trying to figure out if this was indeed universal truth; if it was so evident, how is it that no one has thus far talked about it because everyone loves beating up IT and if it was so evident a simplistic comparison, it would have been well searched and figuring in the Top 5 priorities of the CIO and every vendor!
How do we measure IT productivity: Lines of code per day? That no longer seems relevant with the shift from procedural to new way of creating programs. How about number of people to support per 100 compute or network assets, or servers; even that is now irrelevant with virtualization and clouds taking over. Maybe number of locations, or solutions in the IT portfolio, time to respond or time to repair; most of these activities are anyway outsourced with SLAs.
Business value of IT
The baseline has been shifting and IT has adapted well to the change. In linear motion it is easy to measure a shift; in the real world it is a little difficult to quantify. So what efficiency parameters should the CIO use to demonstrate improvements if at all? The CIO dashboard and reports have evolved from technology availability to business value. Productivity gain is not specific any more but interconnected and interdependent. People do not measure activity but outcomes.
IT-influenced results are business agility, competitive differentiators, low cost of operation (Business and IT), and growing revenue faster than market. If the CIO is indeed driving these and well accepted and recognized by the enterprise, does it really matter if the lines of code generated by the IT team is lower than the industry benchmark?
The pitch was passionate enough to keep the audience awake. The speaker and his assistant were animated in professing the virtues of their products. They kept on imploring the CIO to consider their wares instead of the market leader, even though they had only 10% market share in comparison to the leader’s 60%. The CIO who had listened patiently for more than 30 minutes thanked them for the presentation signaling an end to the meeting. The entire sales team was aghast! No questions?
It was a large deal that had every vendor wanting to show their wares with a hope of getting the business. The company had embarked on a major transformation after many years of hibernation. Thus there was a sense of expectation in the market and rightly so since whosoever bagged the order would become the standard supplier for a long time to come. The total business potential was very large commercially as well as from market visibility perspective.
For the vendor having discussed the architecture and the overall strategy with the IT team, the final stage to qualification was expected to be the meeting with the CIO. So the vendor pulled all plugs and brought together the best possible team for the presentation to the final decision maker. They knew that they had a chance of making the cut since the market leader had no presence as yet in this account. The CIO was also known to be fair in his approach and that added to the expectation.
The meeting started well with the setting of expectations and illustration of the approach, product features, open standards, and recent wins across industries. So far so good, but midway something broke and the fervent pitch turned awkward; rather than discussing merits of their product, approach and solution, the sales head started talking about the problems the CIO is likely to face if they selected the leader’s products. Now it was not about what they did but what the leader did not do.
It was not evident to them that they were no longer connected to the audience and had lost. The CIO patiently heard them out through the leader bashing; he proceeded to close the meeting with a polite remark that once the decision was finalized, it would be communicated to everyone who participated in the evaluation. As they left there was a sigh in the room; the CIO and team sat quietly trying to shrug off the negativity. Nothing needed to be said; everyone unanimously agreed that this was curtains.
Why do some people resort to negative selling? Why do they not sell on merit? Don’t they realize that it puts off the environment and has an adverse impact on the outcome? Is it the desperation of targets or month/ quarter/ year end, and the need to sell at any cost (ends justifying the means) that brings to fore such behaviors? Despite losing almost every such deal (I am sure CIOs can see through this clearly), the tendency remains to put down others to show superiority.
I believe that good is not always relative to something else where the other has to be proven not good. This maxim has to be understood for the behavior to change. A product or service can be classified superior by illustrating the benefits or features; let the recipient of the information decide in his/ her frame of reference whether it is a better fit than others. Everyone does not use the same yardstick neither does everyone compare the same products/ services every time. It would be great if our IT vendor community understands this and starts creating better services and products.
As a CIO I would love to do business with such a company, wouldn’t you?
I had an interesting discussion with an executive search professional who called to ascertain interest in a position with her client. Her company is known as one of the premier head hunters that work only on C-level placements and does a good job of that. Her client, a large diversified group, wanted a business IT professional for the position of a CIO, reporting to the Group Chairman. She believed that the position was exclusive and merited attention.
As the discussion progressed, she sought my view on current CIO compensation levels. I pointed her to research done not too long ago by an IT publishing house that provided the range in which CIOs were placed with slices for industry, experience and location. She expressed dismay on the median and the fact that most of the IT leaders titled CIO were underpaid in her opinion in comparison to other CXOs. Her data points were the placements her company had executed.
The CIO-compensations analysed
Ruminating over the discussion I saw a thread on one of the professional social sites on a similar subject. Is CIO compensation in line with other CXOs in the company? Does a company perceive similar value contribution by the CIO? Are there CIOs out there who earn more than their other CXOs? The answers validated the revelation the head hunter had a few days back. Most CIOs are ill positioned and not on par with their peers (my definition: 5% variance is on par); the exception group is miniscule.
What contributes to this situation? Is the gap due to the position being still seen as a service provider and not an equal to say the CMO or the CFO? Does the person in position influence the decision on the monetary value? The industry variance exists though the gap varies. I started scanning data from other countries and found that the story was similar. Exploring age or experience gap, the data revealed that this factor was not relevant.
What is the CIO’s worth to a company? S/he keeps the business humming 24X7 across locations with connectivity, business applications, mobile connectivity, information on demand anytime anywhere, business intelligence and analytics, sales force enablement, supply chain visibility, production planning, customer relationship and engagement management, ecommerce and m-commerce, scheduling and operations of flights, hotels, information security, business continuity, phew! Is all this of any value?
Ask anyone in a company the challenges and chaos or the disruptions when any of the above stops working. The impact varies by company and industry as the elasticity is defined by multiple factors. Antagonists will say all this can be outsourced; yes it can be, however someone has to first set it up before the operations can be given away. Even total outsourcing retains part of the IT team along with the leadership to strategically keep the technology in line with the changing market and needs.
You define your worth
I believe that the value of the CIO is defined by the CIO. The discussion, debate, and engagement of the IT team with stakeholders; articulation of change, success and the value creation with IT systems contributes to the perception of value. Contributions to business decisions add up; taking a position on issues not just limited to IT make a well-rounded business leader and earns respect at the table. How the IT team interacts and presents itself is a reflection of the CIOs leadership.
Will all this bring value commensurate to the effort and monetary reward comparable to others in the enterprise? The suggestions above are a small representation of CIO behaviours that contribute to his/her locus standing. Each person has to find their balance and align it to their reality; don’t try to change the world, change yourself for your own sake. I am saying this from personal experience.
The relationship between the CIO and the CFO has been discussed with adversarial undercurrents as the general perception about the CFO portrays a beanie counter. This is analogous to the CIO remaining the EDP Manager, but the prototype has stayed stuck; in a similar vein where the belief continues that the CIO has not evolved and is still the Chief Technician who fixes Boardroom projectors and the Boss’s email.
Recent time, with the resurgence of social media, has seen the emergence of another debate about the CMO cornering a large proportion of the IT budget. This news which could be based on some data points in a survey in a small geography for a sub-segment of a domain, the conclusions depict the CMO usurping the CIO chair; a real stretch of imagination, but which has a group of CIOs vehemently opposing this purported trend. Some discussion groups even want the CIOs to confront their respective CMOs and assert their power over the IT budget.
The CEO factor examined
So when I had an opportunity to partake in a CEO get together, I was looking forward to clarifying a few assumptions and doubts. If you are wondering what this has got to do with the CFO and the CMO, well along with the CIO, they all typically report to the CEO who is expected to mediate in case there is a conflict within his team. The above presumed conflicts will sooner or later end up for arbitration or follow the general trend where the CIO backs off.
I love interacting with CEOs (including my own CEO); they are the better barometer of IT progress and use within their company than the CIO is. As the primary leader of the enterprise, s/he sets the behavioral norms and culture of the company. Their belief system percolates down the spine of the company influencing processes, process discipline, technology deployment and use, risk behavior and finally the cohesiveness of the Executive Committee that runs the company.
Since I knew most of their CIOs it was easy to create correlations: big manufacturing CEO used social media extensively, his CIO is well known for success; mid-pharma CEO who thought of IT as a cost center had high attrition in IT; a diversified group’s young digital native CEO had the CIO soaring high from success to success. You get the trend; the CEO is the lead indicator of how the job of the CIO is likely to be in a company and where s/he will stand in case of a conflict with other CXOs.
The reporting structure
If you benchmark companies with CIO reporting to CEO versus other CXOs, the comparison set clearly demonstrates the ones with the CEO fare better even when the CEO is not necessarily IT friendly. In the control group which ranges from 30-80% (CIOs reporting to CEO) depending on the geography and industry, the next differentiating factor is the CEOs appreciation, tolerance, averseness or indifference to IT. It is evident that the CIO directly or indirectly influences the success of the CIO.
Should the CIO be insecure about the span of control, budget, or technology disruptions? Most CIOs aren’t but the hype created by various factions would make you believe that the CIO is shivering with fear uncertainty and doubt (FUD factor) on his/her future. Reality being diametrically opposite, I believe that CIOs should stop reacting to rumors and instead start proactive communication on the contributions to different parts of the enterprise in making the CMO or the CFO successful. Let them be at the receiving end for a change!
A recent edit in an IT publication discussed the pitfalls of the CIO going out on the field meeting the end customers of the company’s products or services. It highlighted the fact that most CXOs wanted the CIO to stay away from the customers and not encroach on their territory. The CIO meeting customers was seen as disruptive and a threat to their relationship and the final moment of truth with the consumer. This observation was believed to be consistent across industries as well as size of the company.
A call to the Editor resulted in her portraying the reality she had witnessed on the discussion table that included some heavy weight CIOs. They were tentative in their approach to reaching out to customers; this was not viewed kindly with heavy brick-walling. A casual interaction was fine, but not continued engagement that may result in a different reality for the sales / marketing teams. Of course, there were a few outlier CIOs who did systemically meet the customers and shared insights with their teams.
My reality being different from the majority, I decided to chat up with some CXOs to determine if reality was indeed that grim. I picked a few high-touch industries like retail, banking and airlines, and added some low touch ones like pharmaceuticals and FMCG where the end consumer is largely faceless. Then I started searching through the good old visiting card rolodex, my connections on social media and professional networking sites; finally adding some with help from industry bodies.
I had some apprehension if I will get candid responses, so I decided to use the research envelope which does normally get open answers; you know researchers are perceived as non-threatening since in a statistical model, there is no identity. The modus operandi worked well and my research was successful in capturing reality with high fidelity. The correlation to industry or size of company was not decisive, the general trend was however quite evident.
Marketing and Sales have over the last few years faced uncertainty due to the global economic uncertainty and the impact it has had on consumer sentiment. Corporate as well as individual spending has seen a general holding back. Do we really need to spend? Do I really need the latest gadget? Such decision points have resulted in pressure that has everyone looking inward more than outward. Natural reaction has been to hold on to the fragile relationships. What if the discussion turned away the customer? What do you know about customers anyway?
Mr CIO, you have no business to …!
One of them quite paranoid went on to state that IT has no business prying into relationships; he had advised his team to keep everyone at bay like the pirates; auditors, information security, anyone who asked for data was turned away. Even the BI reporting was curtailed lest it be used by someone to create different conclusions. The company in question was struggling for growth though doing better than some of their competitors. In the high growth era, they were the leaders, now that appeared to be chapters in a history textbook.
Can the CIO change this behavior? Being an optimist, I would say, probably yes! Is it worth the effort? Many would say, certainly not! And I tend to agree with the collective wisdom though with a caveat. I believe that CIOs are always at the short end of disruption; so they should not back off in the face of this push back but continue the dialogue while getting others behind the cause. Different perspectives have always created new opportunities. After all, you cannot expect different results if you continued doing the same thing over and over again. I have lived by this maxim and I am still alive.