What Do the Words User, Partner, Customer and Client Really Mean?

“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.

Of course, this is absurd. There’s so much that IT staff cannot control in producing bottom-line results. And the business is not the least bit interested in giving up control over its processes or its factors of production.

Meanwhile, if IT has some authority over (and accountability for) business decisions in a partnership, then to be fair, the business must have some authority over IT decisions. “Users” will expect to participate in decisions like technology designs, infrastructure, project plans, which staff work on their project, whether those staff take time for training, etc. They’ll claim the right to micro-manage IT.

In doing so, they should be held partially accountable for the success of the entire IT department. Yeah, right.

This whole muddle of shared accountability and authority leads to confusion, tussles for control, strained relations and ultimately no clear accountability.

Furthermore, each party is given some control over the other’s area of competence—and their own area of incompetence! Instead of tapping the unique differential competencies of IT and business staff, it has each meddling in decisions they’re not qualified to make.

Is this any way to run a successful business?

Customer

A highly effective working relationship is indeed based on common interests, but it also establishes clear and distinct authorities and accountabilities, and it aligns these distinct roles with the parties’ distinct competencies.

The best way to think about such a working relationship is from the perspective of a business within a business. IT is a competitive product/service provider, and the rest of the business is its marketplace. In this context, we’d call non-IT people “customers.”

Customers are 100 percent accountable for their own bottom lines. Therefore, they must have 100 percent of the authority to decide how they work (their processes), how they spend their money (priorities and price points) and what they buy from IT.

Meanwhile, IT staff are 100 percent accountable for delivering their products and services as promised. Therefore, they must have 100 percent of the authority to manage their staff, their infrastructure and their internal methods.

This taps everyone’s unique competencies. Business customers know how to run their businesses, and it’s just arrogance for IT staff to claim they know what’s best for them. Customers decide their processes and what they’ll buy from IT.

Of course, IT knows its products and services, so it can offer lots of help. It can help customers diagnose their requirements (a facilitative process, not a matter of studying and recommending). It can offer alternative solutions at varying price points (Chevrolet, BMW, Rolls-Royce) and explain the trade-offs of each.

IT staff can also help customers understand what process changes would best take advantage of the capabilities of new IT tools. But IT cannot be held accountable for changing the business. Change cannot be forced on the business from outside.

In practice, a respectful customer-supplier relationship leads to the best working relationships—to the closest “partnerships” in the first meaning of the word.

Client

The name customer is certainly better than the name partner, but there is a problem with it, and that has to do with teamwork.

Within the IT organization, a number of different groups may participate in a project team. Here too, shared authority and accountability does not lead to effective teamwork. While everybody should help the team succeed, clear individual accountabilities are essential to performance.

Again, the customer-supplier relationship applies. Consider an applications development project. An applications engineer (project manager) must be held 100 percent accountable for delivery of the project. But like the general contractor who builds your house, this project manager is a “prime contractor” who may subcontract to other IT groups for help.

For example, an information engineering group may be called upon to develop the data model, platform engineers may help the applications engineer design for performance on the intended platform, and the operations group is accountable for installation into the production environment.

In this way, every team member is individually accountable for his or her contribution, while the prime contractor is totally accountable for hiring all the right subcontractors, putting the pieces together, and delivering the complete results to the business.

For exactly the same reasons as described above, the customer-supplier relationship leads to the best working relationships within the IT organization—high-performance teamwork.

With that in mind, your customer may be the ultimate consumer in the business (if you’re the prime contractor), or your customer may be a peer within the IT organization (if you’re a subcontractor).

Customer and supplier refer to roles, not to a set of people. Thus, we need a different name to describe customers in the business (formerly known as “users”).

I’ve adopted the name client to refer to people outside IT who consume IT’s products and services—the ultimate customers in the business.

Quick Lexicon