I was listening to a video from Startup Lessons Learned, where a brief comment was made regarding customer centricity at IMVU, which reminded me of a nagging thought in my head in recent months. Customer Centricity is evil, in IT. That’s a bold statement, so let me explain. There are a lot of mechanisms of providing the customer what they need, and perhaps even want, without placing them at the center of your activities.
Being customer centric, as implemented most places I’ve seen, means an unwavering attitude internal to the organization that it will bend over backwards to provide the customer what they want. This leads to some unintended consequences, such as a continual focus on the functional, rather than the non-functional. For those who spend little time doing software project, program or requirements management, functional requirements are things like “I want the software to be able to calculate taxes and print it on a receipt” and non-functional requirements are things like “I want the software to always work.” Bending towards customer centricity and an attitude that the customer is always right, especially in the world of custom software, means the resources of the organization are constantly allocated to the functional while often largely ignoring the non-functional until it’s too late.
This attitude can and will, at a point in the future, leave you in a situation where the scale and complexity of the software the IT organization is producing will begin to collapse under it’s own weight. The nimbleness once felt, perhaps as recently as a few years back, will begin to become cumbersome, as the continuous iterations of “get it done, the customer needs it right away” lead to band-aids, patchwork engineering, and layer upon layer of complexity. Time for things like application rationalization activities, engineering and architecture improvements, and infrastructure improvements are pushed aside in order to make room in the capacity model for more functional requirements for the customers.
The solution? Simple IT. A culture of simplicity is required around every change to drive compromise between what the customer wants and needs and what IT can deliver and maintain. Constant reinforcement of a simplicity culture is required to drive every individual contributor to ask “is this additional complexity required?” It will drive from monolithic to modular, from n to n-1 layers of abstraction, from customization to off the shelf. No organization is perfect, so additional iterations of software should continually simplify and rationalize the changes that in hindsight complicated rather than simplified. The customer demands the non-functional without asking for it, and the customer gets what they’re asking for through simplicity.
What does the mean for the customer? The customer asks for 30 reports, they get 5, because it’s actually in their benefit. The customer wants business rules that force the agents to jump through hoops to try to upsell customers, which leads to ridiculous clicking and wasted agent time, IT pushes towards training, because the complexity hurts the users’ perception of the software and impacts their behavior negatively. The customer asks for a different pricing model for every market, IT refuses to support it. Will this lead to significant conflict and accusations that IT is not responsive to the business? Absolutely! Perhaps the company will go through three IT leadership teams before they realize their behavior is the problem, or perhaps they will never realize. Either way, IT has a duty to the business to draw a line between what is possible and what is right, and IT is in the unique position to provide the business with facts and data about how decisions driving complexity hurt not only IT, but hurt the business. Simplicity is, in reality, complicated to deliver; it’s the enemy of mediocrity; it’s the champion of forethought and design; and a culture centered around simplicity is the only way to deliver years of iterative software without being forced to spend significant amounts of money, time, and resources, redoing what customer centricity, and by extension, complexity, create.
A couple of things have happened recently which has made it to where I believe it’s time to start writing thoughts, publicly, again. First, I’m relatively certain people do not read this, at least regularly. Secondly, even though I have advanced significantly in my career and I am now a very competent middle manager, I believe my entire happiness in my work life is suffering simply because we seem to defer to political correctness. Making sure no one’s feelings are hurt rather than running an organization as a meritocracy where the best ideas win seems to be lay of the land, at least in American business these days. I used to not be afraid of putting my thoughts out there, now I seem to be in constant fear that being liked is the most important aspect to career advancement. I have decided that while I have come very very far in the last few years attempting to ensure that I am effective at change in a large organization due to being well liked and respected, I will no longer place being liked ahead of stating what I think will be in the best interest of our organization. That does not mean I intended to go back to being a daft prick like I have been in former years, but I will be firm on my thoughts on the direction our organization should be taking. I want these ideas to stand on their own, so this will be immediately followed by another post on being too customer centric.