Don't be fooled by the jargon

Few attempts to destroy the English language have been as successful as the strange utterances of management consultants. To the inexperienced, a comment like: "We are actualising our key deliverables across a broad range of core competency scenarios with respect to synergising the key cost driver alignment as it relates to the human capital matrix analysis going forward" would lead to a number of conclusions:

the medication isn't working very well;

perhaps James Joyce's Finnegans Wake isn't that impenetrable after all;

I bet it would make more sense if you said it backwards.

But this is to miss the point. Management language is deliberately opaque to give the impression the consultant is an expert possessing privileged knowledge. If you cannot understand what they are saying, then they must be clever and worth the exorbitant fee.

There is an implied invitation to join a business "tribe". Management jargon is the linguistic equivalent of tribal paint, the use of which marks a manager's entrance into a privileged elite. The verbal nonsense is also a way of being coy about making difficult decisions. When sacking staff, for example, it is so much easier to depersonalise employees by calling them "human capital" or "knowledge resources" than thinking, feeling humans. It is no accident management jargon is a lexicon of things and objects.

Here are a few definitions to help improve your knowledge-base empowerment in respect of the key-data benchmarking uploads.

Cost cutting. A way for managers to pretend that failure is success.

Dehiring. The consequence of management's dehumanity.

Deliverable. A bit like an outcome, only cuter.

Downsizing. An activity perfectly suited to the small of mind and heart.

Hot desking. For reasons that remain mysterious, desks are much more productive when they are hot.

Human resources. As a resource, human beings are mostly water. Water isn't worth much.

Process. A word that means everything and nothing, but mostly nothing. Managers believe a process is ipso facto a good thing, because then you are going somewhere until the timeline indicates that the process has run its course at which point you will need another process, or at least a process to identify a new process, in order to go forward. Ideally you will finish up with a deliverable or two (see deliverable).