What Do the Words User, Partner, Customer and Client Really Mean?
What’s in a name? Lots, including the key to customer focus, teamwork,and effective working relationships.
CIO
—
"What’s in a name? That which we call a rose
By any other name would smell as sweet."
—William Shakespeare, Romeo and Juliet, (II, ii, 1-2)
These days the name user evokes images of drug addicts or sociopaths. In IT circles, too, it has become as reviled as the name Montague was to the Capulet clan. Although Juliet took a different tack, we dare not speak the tarnished name anymore.
The decline of the name user led to a debate over what to call all those consumers of IT products and services. And while we may not argue the question with the same heated passion we do politics, it’s an important debate.
How important is semantics? Very! Language affects the way we think. A pejorative term like user induces IT staff to consider them powerless dependents, sometimes nuisances, or perhaps little more than a mechanical part in a system IT is creating. It certainly doesn’t sound appreciative of their unique knowledge of the business, respectful of their right to choose what they want from IT or connote anything, well, human.
Partner
A popular alternative is the name partner. It evokes images of a warm, cozy working relationship.
Indeed, as a verb, "partner" means establishing a close working relationship between parties who have a common interest. Think, for example, of a partnership between two businesses. Each company contributes its unique products and services, and the whole is greater than the sum of the parts.
But there’s another interpretation of the word that has some terrible side effects. Some use the term partner to imply shared decision making, as in the context of business partners who together own a business. Co-owners share decision making and profits.
In this meaning, IT staff have some say over what IT products and services the business gets. IT has a vote in deciding priorities, requirements and price point (Rolls Royce versus Chevrolet).
Consider the golden rule of organizational design: Authority and accountability must always match. If IT staff have some degree of authority over what factors of production the business gets, then IT staff must accept shared accountability for business results.
I don’t mean just accepting accountability for the success of the IT project. IT staff have to accept accountability for the business’ bottom line—for its profitability. After all, if IT has some authority in deciding that the business will get this instead of that, pay this instead of that and change their business processes in this or that way, then IT has a direct impact on its bottom line.
