Sometimes companies defend component teams by bending the term customer. They say things like “other teams in our company are our customers, we have internal customers”. For example, they have a “platform team” that delivers the platform to the application teams – their internal customers. Or they have a testing framework team that delivers the testing framework to the other development teams in the company.
I don’t buy it. Internal customer is an oxymoron for me. I have two views that support it – customer view and economic view.
Internal customer is not a customer
First, the customer view. Having an internal customer effectively means splitting the company into two parts – department A that listens to real customers and hands over the requirements to department B, i.e. department A servers as an “internal customer” to the department B that serves as its “internal vendor”. Many lean wastes will occur at that handover – delays (department A waits until department B delivers their piece), information loss, overproduction (duplicate code), partially done work (department B finished their part but nobody from department A is ready to use it), etc.
It also often requires many “A to B” coordinators. Their only task is to make sure that the work of A and B are synchronized. They are pure overhead from the economic point of view.
Why not merge departments A and B into one AB department that can deliver customer requirements as they go? Then, customer is customer – a person who pays for your product and you do not need to invent any adjectives to it.
This is, by the way, consistent with the Scrum idea of the cross-functional team.
Internal customer implies a monopoly
Let’s now look at the internal customer from the economic theory point of view.
Let’s say there is a team that provides an internal “product” to the other teams in the same company, e.g. a UI framework. They are the vendor and treat other teams as internal customers. At the same time the “product” is given to the customers for free (we are inside one company).
Basic economic logic says that if a price decreases, demand increases. If a price decreases to zero, demand is infinite. Internal customers are thus economically motivated to ask for features in the framework, because they come for free for them. Heck, they are motivated to ask for features even if they don’t need them, because they come for free.
On the other hand the vendor team is the only provider of the UI framework code. In economic terms it has a monopoly. We all know from economic theory that quality suffers in this situation – a monopolist can afford delivering whatever he wants, because he knows he will always find buyers.
After some time we have an internal “product” with tons of barely used features and crappy quality. Doesn’t seem like a recipe for success.
And to clarify – I am not saying that it will happen every time in every company, just that the economic forces push in this direction.
To summarize, having an internal customer is usually a very bad idea. Yes, I can imagine having real internal products that have real internal customers. If you work in a corporation with 30,000 employees, it probably pays off to develop an employee portal for the corporation as an internal product and the employees are then internal customers.
However, more often than not the term “internal customer” is used just to mask that the company is internally split into departments for no good reasons.
