Actually the simple picture of supplier and customer doesn’t really describe the world most of us have to live in. If we go with the ITIL concept of a customer (someone who has financial influence or authority) then we also need to worry about what our users think. In other frameworks you might hear a more general concern about taking the whole range of stakeholders into consideration. Doesn’t matter which recipe you follow – does matter that you see the complexity.
Some of the problems come from being so close to how things are done (rather than why they are being done), and by being so close to what you think matters that you don't spot what matters to those receiving the service. Sometime it is the silliest things that make the customers and users unhappy and reject a service. Maybe that is an example of the ‘One Bad Apple’ syndrome – something firmly embedded in the human condition seems to be our ability to allow one bad aspect to overbalance a dozen good things.
I had my own version this week, when I found myself refusing to continue with an online application for a new bank account because the software insisted on spelling my name incorrectly. (For reasons I cannot fathom, it seems to have decided that any name starting with ‘Mac’ must have a capital afterwards – so it turns ‘Macfarlane’ to ‘MacFarlane’ without giving me the chance to turn it back.) I didn’t stay around to see what else the service offered, I just closed the web page and got my new account somewhere else that will let me spell my name properly.
But there is also the positive face of the same coin – the power of ‘cool’. Imagine you have found the perfect shoes for your child – scientifically designed to protect their feet while supporting their bones and they are even waterproof. As a caring parent these are the only pair of shoes you want your child to be running about in (see IKB later in this blog). As it happens your dreams have come true because your child loves them. Is it because they are good for them, and will help their feet develop properly – no, they agree to wear them because the heels light up with each step. They will wear them – and save their feet – but only because they are ‘cool’ – according to rules you will never understand. By the way, don’t think the illogical ‘cool’ factor only applies to children, it is there in just about every service you deliver or use – at work or at home. If you look for it then you will see it. I don’t want to make this posting too long or I could list dozens – but just imagine trying to sell powerful and effective software products against others with less relevant features at higher cost – but with a fancy graphical interface – sound familiar to anyone?
If you think about these two situations – where apparently less important elements disproportionately affect decisions - I am sure you will find many examples of the two extremes; like the fast-food restaurant that you still avoid because of one bad burger or one element of bad service, hundreds of miles away and several years back.
Those issues tend to come from how the service is delivered, yet the same problem can easily come from how it is built (like my name issue). But one of the differences is getting the message back to where it might make a difference, because at best the complaints go to the operations side of the house, and this does not get fed back, maybe because it is dismissed as trivial – because it doesn’t seem important to whoever received the message.
It isn’t just about hiding complaints though, we also have the ability not to pass the cool factors back. Do we always find out why people really like something? It seems to me that we don’t often ask the right people the right questions. And it also seems there are simple reasons why we do that:
- We presume that what is important to us is what is important to our customers, users or others that matter. Is this a common manifestation of IKB (the ‘I know better’ syndrome)? Most of suffer this from our parents, then grow up and do it other people.
- We don’t know who to ask – and we don't know what to ask them.
Both of these situations are understandable – after all, we are human so of course we see things first and best from our own perspective, and without being forced out into another’s environment then why should we have the ability to understand people we have never met? The second is also inevitable in the complicated amalgams of customers, users, services and suppliers we exist within. Never mind the neat little service chain pictures you get in the books – it doesn’t really look that simple, it looks complicated, and mostly because it is complicated.
We can do something about these difficulties – but they require addressing the way we – and our colleagues – think, and that takes time and effort.
There are other causes and factors – and maybe there is one we could do something about, and it is something that would magnify the beneficial effects when you finally get around to addressing the two points I listed above: when we do find things out we don’t tell the people who could do something about it. And the very best way to get that wrong is to build silos within your supplier organisation and stop people sharing ideas and information.
After that last blog on devops, I was thinking about that particular kind of communication issue. There is something deep rooted in the human psyche that needs to dismantle their immediate environment into teams (or groups, or departments or silos or tribes – call them what you will). IT organisations are perfect examples – with high level internal teams always emerging once they gets past a certain size. And if you separate into teams that feel the need to compete, then helpful messages will not be fed across between them. So what was built wrong and delivers the wrong thing stays there and will be wrong in the next version too. That is the inertial element of behaviour that initiatives like devops and whole service lifecycle approaches have to contend with. We shouldn’t think it can be as easy as just telling people to collaborate and communicate. Like all challenges we need to recognise what we are fighting – and to fight back.
So – what are good ways to start? Perhaps as simply as recognising that while we might bond comfortably into (say) a ‘development’ team or an ‘operations’ team (or any one of a dozen more) – that doesn’t make the other team the opposition – I think that would be a good first step, if we can finally realise that – by and large – what benefits one team also benefits the other.