Chapter 5 - The "IT and the Business" Paradox
There is an innate problem with perceiving the IT department to be something outside of the rest of the business. It is very common for a CFO to refer to the relationship between "IT and the business" but you will likely never hear the CFO refer to the relationship between "finance and the business" or the CMO refer to "marketing and the business" - as they see themselves as being part of the business rather than a separate entity in a contentious relationship with a separate group.
Moreover, this is largely self-imposed. While technology executives may complain of being marginalized by the business, their own behavior has been aloof. The practice of running an IT department as if it were an external operation, a vendor providing service to the business, has created and reinforced this perception on both sides.
As a recruiter, the author reckons that in most instances where she has been called upon to find another CIO because the present one "isn't working out" is not because of the incumbent's lack of technology knowledge - it is because of his lack of relationship-building skills. The ostensible reason for his dismissal might be some financial or operational failure, but the reason they seek to replace him rather than forgive his mistakes is because he has failed to build a relationship with his peers and win their trust.
For decades, there has been a lot of discussion about partnering with the business rather than standing aloof, speaking in their language rather than spouting technobabble, and the like. Some CIOs got the message, but many others have not.
A quote from a technology executive: "because our skills are transferable from one industry to another, we can fall into the trap of thinking of ourselves as IT professionals, as opposed to industry professionals." There is no similar problem in other departments, whose skills are just as specialized and transferrable.
Revisit Communication Basics
The author suggests that CIOs who have worked to close the distance between their department and others, making both operational and cultural changes to avoid the perception of being a separate entity, have largely been successful in breaking the paradox.
One CIO noticed that the weekly report they provided to the executive council (as did every department) was eight pages of jargon and technical details that nobody read. She shortened it to a one-page summary that state what was completed that week, telling the business only what they needed to hear. The CEO commended it as "the best IT weekly report he had ever seen."
This highlights a very significant problem on every level of the IT organization: the compulsion to provide too much information, explaining the technical nuances, rather than limiting it to details relevant to business needs. In a similar vein, if the accountants were asked about the accounts payable balance, they would spit out a number without a long-winded explanation as to how it was calculated.
In her work as a consultant and recruiter, the author indicates she can often assess communications skills in ten minutes. Merely ask a technology executive about a recent accomplishment: some will talk about the value they delivered to the business, but many will disappear into technical concerns that never get around to explaining what any of this did to benefit the business.
Another problem is that unit metrics are likewise focused on technology - when the IT organization holds a "town hall" to talk about accomplishments, it's largely focused on technical achievements rather than value to the business - this focuses the workers, and makes them feel great about, things that don't matter to anyone outside the department.
Another anecdote shows direct reinforcements through awards programs - in which IT employees are recognized and compensated for solving technology problems, rather than for solving business problems. This, too, provides recognition and incentive for doing things that are of no interest to the business.
According to "many" CIOs the author has encountered feel that their best work is evangelizing for their departments - communicating to the rest of the organization the value that IT provides to the business, and ensuring others in their departments recognize that the ultimate goal of technology is to help the business accomplish organizational goals.
Recognize the Innate Power of Language
In addition to reconsidering the core topics of discussion, technology professionals should drill down to the level of language they use in communicating with the business. Technobabble is a language unto itself that people outside the IT department do not speak, and are not particularly interested in learning. Instead, the geeks need to speak their language.
Unlearning tech-speak is likely a challenge because it has become the native tongue of IT departments, and being fluent in the lingo earns nerds the respect of their fellow nerds - while making them seem all the more nerdy to anyone outside the IT clubhouse. The trick is to learn to speak plain English, without being overly condescending.
The author mulls over some of the terms that are in fashion of late - governance, architecture, infrastructure, cloud, agile, and the like. Many of them are meaningless or represent a myriad of meanings, which is tantamount to being meaningless. Ultimately, if you have to explain a term to someone else, it's not a good term. It's suggested that, in some cases, you can turn a boring statement into an engaging one simply by changing the words that you use.
The author returns again to the notion of using metaphors and analogies to explain complicated technical matters in ways others can understand. (EN: And again, I have to say it's condescending and often obscures more than it illuminates, but there it is.) Rather than inventing your own metaphors, consider borrowing on metaphors that the business uses - sometimes you can hang a metaphor of the company's products.
While it may sound frivolous, changing the name of the group can also be useful in communicating the purpose and underscoring the change. One CIO renamed the IT department to "Business Information Technology Solutions" to emphasize the focus on providing solutions to business, not technology unto itself. A similar trick can be done with job titles. However, this alone is not a solution, and if the nature of the relationship between IT and the business remains unchanged, the new title will become a sarcastic joke.
The same can be said of mottoes and slogans: they seem corny, but can be helpful in focusing and communicating intent. They don't need to be clever or kitschy, but if they simply communicate the two or three attributes/attitudes, they can be effective in getting the point across.
Strengthen the Business Skills of your Team
Thus far, the author has discussed perspective and language - but these alone still are not sufficient: you must understand the business, rather than expecting them to seek to understand technology.
A brief return to the notion of having dedicated contact people: they provide a single point of contact for the business, such that there aren't a barrage of questions from random people, but it also gives you a starting point insofar as training IT employees in business. In one shop, they set the expectations that the account rep would be "the only IT person [the business] will ever need to see," and whose primary job was as a liaison and concierge to the rest of the IT organization, whose primary job is to handle communications. Over time, individuals in these roles will develop business acumen - but it's best to expedite by training when possible. Another suggestion is to rotate technology employees through the business - either directly or through a role that has strong contact with the business to spread the business knowledge further.
That is not to say that IT employees have to become experts in the business - but they do have to be knowledgeable to communicate with business people (who hold in-depth expertise) and translate between the two departments.
In some companies, these individuals exist on the business side of the fence - they report to the business, and serve as coordinator for all IT projects. This can be beneficial because they will be managed to support the interests of the business, rather than those of the technology department. The important thing is to have, on whatever department, someone who can facilitate, translate, and have a broader perspective than an individual project.
There's also a caution against making these people "toothless," as a liaison has only the ability to cajole, and no authority to insist that their interests be served. They have to have real teeth and the backing of formal authority (though often by proxy of being able to get backing of a toothy executive).
One CIO mentions creating a "buddy system" between her technical staff and the key staff on the business side, encouraging them to invite the IT person to the regular business meetings to become familiar with their interests and objectives. This brings business knowledge into the IT department and gives IT a voice in business meetings, as an opportunity to serve as a resource when technical questions arise. It becomes a much more complaisant and ongoing relationship.
A few other suggestions are given: to find people in the business and entice them into the IT department, or educate IT people about business. Some local colleges offer seminars that propose to teach the basics of business in three days - which can be a good start.
When it comes to rotation, the author advises choosing employees carefully. IT workers who have little aptitude for business may see it as a punitive assignment and their attitude can do more harm than good.
There's also the suggestion that you should listen rather than speaking. Rather than (or perhaps in addition to) doing presentations in other departments to help them understand the (desired) role of IT, invite executives from other parts of the company to present to the IT department. As a leader, you must make sure that your people make attending a priority.
Another CIO emphasizes negotiation skills as an critical skill for IT workers, who tend to see things in terms of black-and-white and non-negotiable
Sidebar: Stakeholder Relationship Assessment
The author presents a "tool" to assess the degree to which IT has been successful in establishing a relationship with the business. A few sample questions are:
- The business involves IT in their budgeting process
- The business proactively seeks our advice on technology
- The business sees us as a source of ideas for new enterprise opportunities
(EN: I think this is a good concept, but likely not well executed. Aside of providing a scale of agreement rather than a binary yes/no to each question, it should also be evaluated according to the customer's perspective rather than your own. How much you think you are trusted is less important than whether they think you can be trusted. And some can be objectively measured - such as what percent of customers include you in their budgeting process.)