If you want respect from your business, stop meeting their requirements
permalinkSeptember 29, 2007
Is it me or is IT everywhere suffering a major and debilitating emotional crisis? The response I thought I would get to The Business Alignment Fallacy was one of general disagreement, but in fact it was far from it. One message that did come through in the feedback though, was that whilst it's all very well trying to get ahead of the business and take a proactive stance, it's difficult where a credibility gap has arisen.
Why would the any business buy into a technology strategy beyond simple alignment when the IT dept hasn’t proven itself capable in the past? I have a great deal of sympathy for this view. I’ve managed teams in environments where the first response from IT itself, when presented with a potentially better way of doing something, is "we don’t do that here". That is to say - we aren’t great, but we know our limitations, and we don’t want to adopt risky strategies. We’re comfortable serving the business and getting chastised because of missed milestones and unreliable systems.
I sat in a meeting some years ago and was told by a business analyst that my new fangled approach wouldn’t work because it detracted from "serving the customer". Beg Pardon? They ask. We try to meet requirements. End of.
So today’s article sees your unexpected agreement to not aligning with business strategy and raises the polemical stakes with this statement:
Never serve your customer or try to meet their requirements.
Not only is the accepted view wrong, it’s dangerous, and ultimately counterproductive. The alternative approach works when developing the code too. Let’s work through an analogy.
Let’s say your company is a restaurant, and you compete with a whole bunch of similar restaurants in the same town. The epitome of "serving your customer" is to be a waiter, actually serving actual customers. Your customers are your business and the success of your establishment is based on how much they are prepared to pay, how often they return and what nice things they say about you to other potential customers. The more they do these things the better your restaurant will do, and the worse off the competition will be. So let's first assume conventional wisdom is correct and meeting requirements is the order of the day:
A customer walks in. You are warm and hospitable and you show them to a lovely seat and ask what they require. They think for a bit and say they want an omelette. This creates a minor problem (this has to be a true analogy so we need to throw in a constraint or two). Unfortunately you don't have enough eggs for an omelette and your omelette chef is on holiday. You are open about this with the customer and explain that you can still try and meet the requirement, only the omelette will be a little on the small side and not up to the standard you would prefer to meet. They think for a second and say this will be fine.
They leave having had their requirement met. They came in hungry and they are now satisfied. You were open an honest and all that could be expected. And yet the restaurant at the end of the street (the 'restaurant of business non-alignment') does much better. You may still survive while other eateries fail, but the other has the fullest tables and the best reputation in town. Why? Well let's run our scenario again.
A customer walks in. You are warm and hospitable and you show them to a lovely seat and ask what they require. They think for a bit and say they want an omelette. This creates a minor problem. Unfortunately you don't have enough eggs for an omelette and your omelette chef is on holiday. You are open about this with the customer. You think for a bit and suggest that if it were a light egg-based dish they wanted, you could do them a soufflé. Your sous chef happens to be a master of the soufflé and he can create mushroom soufflés, onion soufflés, and double-baked soufflés. You explore the likes and dislikes of the customer for a while and they settle on a mushroom soufflé. Because you could not meet the original requirement you add a complimentary glass of wine.
They leave having not had their requirement met. They also came in hungry but they are now more than satisfied. They will hardly remember the lack of omelette. You didn't 'serve' them; you crossed the divide, adopted an empathetic stance and mapped this back to your capabilities. You used what you could do well to address their desire, not their requirement.
In fact you would do this even if your omelette-preparing facilities were at full-strength, because your customers come to you for your culinary expertise not your subservience. If they really wanted a plain old omelette they could get that anywhere. In a sense, you recognise that, sometimes, your customer is ‘wrong’. Not wrong in a bad sense, just that they don’t see all the options and possibilities that you do. They aren’t food experts; they’re just experts in themselves. They’ll know when they had a great time and they know when they’re happy.
The happier they are, the more proud you can be. Your business flourishes because you are confident enough to see the bigger picture.
I said earlier that this works at the code level too. And it does. Good developers know that you are never trying to solve the specific problem at hand, but trying to build a system that solves a generic set of problems, one of which you have intimate knowledge of at that moment. That’s what domain-specific languages are, and why they lead to reuse, elegance, ease of maintenance, extendibility and so on.
I hope that makes sense. I’ll be leaving the subject alone for a while now as it’s time to move on to more technical articles. My Why Architects Can’t Cook thoughts will just have to remain thus.