By Naked CIO, 17 March 2008 14:24
COMMENT
Many IT managers constantly complain about not being understood by non-technical colleagues. But what do they expect when no one can make out what they're saying, argues the Naked CIO.
For years we in IT have revelled in our pig Latin version of language and phraseology that made us uber-cool - or uber-geek, depending on which side of the fence you sat.
It was a source of pride that we spoke using letters or words that meant nothing outside the IT community. Somehow it made us more credible and intelligent.
Exclusive column: The Naked CIO
See what this CIO really thinksÂ…
The Naked CIO: Offshore - or off their trolley?
The Naked CIO: Shadow of the job axe
The Naked CIO: Identity crisis
The Naked CIO: Innovation - same old story
Unfortunately, this language now alienates us from other business colleagues. It makes us look different at a time when we are begging to be included in decisions and trying to be part of business culture.
Technical speak is now so ingrained that most of us only realise we have reverted to LAN, WAN, SAN argot when the faces of non-technical people sitting around the table become blank with incomprehension.
It is very difficult for us to put a sentence together that describes the computing environment without using some combination of letters to describe something very simple in a very complex way.
This perceived communication problem is one of the single biggest issues that still creates a barrier to IT's inclusion in the business world. We refer to layman's terms when really we should be talking about non-IT terms.
I pride myself on my ability to communicate at all levels of the organisation, yet I'm still sometimes hampered by acronyms for which I have no English definition.
We have even started confusing ourselves because we now duplicate acronyms such as CMS - call management system, content management system, or customer management system?
With every piece of new technology that comes out we adopt a similar cryptic reference that is non-transferable to everyday language.
If our world of bits and bytes were not already stretching the comprehension of our business colleagues this abbreviation mentality certainly is.
We then cling to phrases we believe the business understands such as business alignment, which in reality are so ambiguous and without common context that they are just as baffling.
We must find some common business data dictionary that can break down the barriers of isolationism and try to have more dynamic meaning communication with all aspects of our respective businesses.
We need to become preachers of technology and speak in ways colleagues can understand. I used to tease an old boss of mine for his idiosyncratic catch-phrases, such as: "I am only cooking the dinner if I buy the groceries", which meant IT can't be brought in at the later stages of the project. Or, "Always plan for the divorce before you get married" for contract preparations.
But in fact using accessible analogies to communicate IT challenges does work. So I discourage tech speak even on the shopfloor and try to explain technical issues using familiar parallels. Stay away from clichés that are too generic.
Comments
There are 10 comments. Join the discussion
1. Paul Wallis
One of the main differences between professions like engineering and architecture and IT is that for many years they have been fully documented.
Like IT, the very complex projects they manage involve many related assets, processes and people. Yet unlike IT, the business and the professionals can easily understand each other and these days disasters are fairly rare.
Why? Because they have simple means of communicating with each other. After all, how could complex things like skyscrapers or bridges be built without blueprints or engineering diagrams?
It is this easy to understand “big picture” of the business and IT relationship that has been missing.
To create this picture, and enable business and IT to speak a common language, understanding dataflows is critical.
It is the understanding, documenting, and engineering of them which is key to managing complexity.
If we have a simple picture of how each dataflow moves across and through the assets of the business the responsibilities, roles, risks and costs of every IT resource, or group of IT resources, employed in support of each business activity or set of business activities can be clearly visualised and, thus, understood.
By attaching value meta data to dataflows and cost information to IT assets, we can start to assess the ratio between IT support costs and the value of the contribution of IT to the business.
Which means IT can speak to the board in the language it understands – that of money. It also means that IT will be fully documented, providing a standard for governance and a foundation for professionalism.
A critical time for IT is rapidly approaching. The Companies Act of 2006 comes into force in the UK in October 2009. Directors and managers - including IT managers - could be jailed if they fail to ensure that the right IT systems are in place to store and retrieve data and that electronic communication with shareholders is robust and secure.
Without full documentation of assets, people and services and a clear understanding of how data flows through the business, many IT professionals could find themselves with more to worry about than a bad reputation.
2. anonymous
There is also loads of mumbo-jumbo and meaningless rubbish from other departments as well.
HR
Operations
Business Development etc...
Mumbo-jumbo is also beloved of consultants.
3. Ian Sargent
Since time immemorial every trade and profession has developed its own jargon. It allows people in that line of business to discuss otherwise complex technical concepts in a sort of verbal shorthand.
In all cases it's important to remember to switch back to plain English when talking to people who do not share the same field of experience.
It's not specifically an IT problem. It happens in all walks of life - engineering, medical, farming, emergency services, railways, whatever.
4. anonymous
But CMS isn't an acronym - it's an abbreviation.
5. Simon
What a load of bull - to use the vernacular of the article.
The problem isn't that IT has its own language, it's that the rest of the business won't learn any of it. Go to any sector - wether it's engineering, HR, finance, whatever, and you'll find a similar level of sector specific terminology. It's essential for those involved to have a common understanding of what they are talking about.
I'm from an electrical background, so I know my VAr from my kW from my RCCD. If the conversation is about technical issues then the terms have to be used - it's no good waffling on about unspecified units of reactive power if the discussion is about the sizing for, say, an electrical installation. Anyone who intends to be involved in the project needs to learn the terminology that goes with it.
The problem is that everyone else in the business expects IT to talk to them on their terms - and at the same time will refuse to talk with IT on IT's terms. If the CIO is expected to know the difference between EBIT, GM, and RoRE then shouldn't the finance director be able to cope with a conversation about the capacity of the WAN to support his financial apps ?
Sure, the terminology can be overused, or used in inappropriate situations. What is probably more lacking is a better understanding of the limitations or the mere mortals who aren't in IT and adjust our use of language as required.
6. Simon Allen
I think that Paul Wallis has it right. One of the great problems that mitigates against documentation and a common understanding is speed.
Architects and mechanical engineers only change things after careful thought and calculation. The standards are there so that the building does not fall down - aka crash.
We can say, "I'll change that parameter and if the system crashes - I'll put it back again." So, no standard calculation and no standard documentation.
While we are on about jargon:
Time-frame - any time I want it to mean.
Thinking out of the box - I'm accusing you of being narrow-minded and the IT guy replies that they are trying to keep the spec within the realms of possibility.
IT jargon and abbreviations are still very young and so they are still changing. Those engineers use have been around for a hundred years or more.
They complain that they don't understand us - but do we understand what they mean at a project meeting when the architect says, "You can only put that outlet between the third and fourth mullions"? Pah!
7. John H Woods
As a more technically oriented persion it strikes me that the people who really abuse language in many organisations are the non-technical types. I nearly sprayed my keyboard with coffee when I overhead someone say - in all seriousness - "When can you give me an indicative on when you'll be able to leverage those synergies?"
Technical jargon is there for a reason. Words or phrases are used for things that would take a sentence or a paragraph if expressed in layman's terms. Business people, on the other hand, sometimes unecessarily suffer an intellectual inferiority complex and use business jargon for which - apart from deliberate humour - there appears little justification.
I should say many business people I know use clear and concise language and still impress me with their insight and understanding. They will ask me to explain technical terms but then they understand the terms and we can communicate effectively: something we could not do if we simply tried to avoid using technical jargon.
8. Richard
According to the evening news, the business whizz-kids didn't even understand their own language or jobs - hence the financial crisis.
Yes, we should try to explain technical things better but far too many business executives have been promoted well beyond their level of competence.
Too many just won't even try to understand.
They seem to regard anything technical as far too trivial, too boring, and too far beneath them.
9. Paul Wallis
Some interesting comments, thanks for the support Simon A.
Given the complexity of the modern enterprise we need pictures like the engineers and architects. To me it’s not really a 'words' issue.
A few years ago, when working for BP I began thinking about IT in a new way: "IT exists for one reason: to manage the flow of data between business assets."
By taking this approach, techniques used in the oil and gas industries for many years can be applied in any sector.
In oil and gas, the introduction of digital monitoring equipment means flows of product are analogous to flows of data. These flows are displayed, monitored and trended in dollars per second.
This means business processes can be optimised around value, and the contribution each asset makes to the cost/value of the flow can be evaluated in monetary terms.
Today, business resources, which include people and IT assets, are either providers of data, consumers of data or provide the conduit through which the data can flow.
The role of IT is to support, process and optimise the flow of data to maximise business performance.
By thinking about IT like this we can create the big picture.
Imagine a landscape piece of paper split into six horizontal lanes. To the left of the top lane write 'Ownership', to the left of the lane beneath it write 'Business process'. Then come 'Application', 'System', 'Hardware' and 'Infrastructure'.
This 'Obashi' - it's an acronym - framework can be used to organise the elements that represent individual business or IT resources in an organisation. Lines can be drawn vertically and horizontally between the elements to show how each data flow moves through and across the organisation.
The whole enterprise can be modelled in this way. Which means IT can walk into the boardroom, unroll the picture and say something like, "If we don’t upgrade this server, hub or router, then this dataflow is at risk. If that particular flow stops then this application won’t work and these departments will grind to a halt. As you know, together we have costed the value of that dataflow at £35,000 per hour. If it goes down for a day the cost to the business is obvious. I recommend we buy a new xyz server for £15,000 to mitigate the risk."
Then we’ll be talking with the business in terms they easily understand…money.
And hopefully we’ll receive more of it.
10. Robert Machin
Ian Sargent says: "Since time immemorial every trade and profession has developed its own jargon. It allows people in that line of business to discuss otherwise complex technical concepts in a sort of verbal shorthand."
Well, yes. It has also allowed people since time immemorial to exclude those who aren't in their line of business, usually for their own convenience and profit rather than that of their customers.
As to using jargon as a technical shorthand, IT jargon - and here I don't refer to standardised abbreviations but concepts such as SDP, SOA, IMS and so on - is often so ill- or undefined as to be useless for the purposes of establishing common understanding, if perfect for spinning up ever expanding clouds of verbiage and confusion...