I've think I've learned a very valuable lesson: no matter how specialised in financial services you are, you have to have worked in a bank – as an employee – before you have any idea of how to "work" a bank.
I write this, because it has struck me recently (and especially on the vendor side) that there is often a lack of understanding some core things we have to go through to make anything happen. I'm so regularly asked why banks aren't innovative, for example, to which my response is that I don't believe we are either more or less innovative than anyone else. We may look less innovative, but that's a function of internal configuration rather than any lack of basic creativity.
So let me give you some examples of popular misconceptions I've had from vendors.
"You can implement this quickly and get a payback this year".
We can't implement anything quickly. There are too many moving parts in a bank for anyone to be anything but deliberate with what we do. There is testing, testing, testing. We need back-out plans. We have to implement the right processes and systems to support whatever it is. And, of course, we have to schedule the change in against all other changes from everyone else. Fast and dirty only works when what you have around you are people who regularly perform individual heroics to make something work. You might have that luxury in a small start-up, but you don't in a bank. Neither do you want it. Everything has to work despite individuals.
" The productivity improvements here will pay for themselves"
Productivity improvements hardly ever pay for themselves, because in order to make them do so, you'd have to reduce the number of workers you have. Or else give them way more work than they were doing before. Agreements with the labour market make both complicated, though not impossible, of course. But frankly, the problem is not so much that people can do more work, but that you can't quantify how much more work they can do. Social media internally? You know that it has a benefits case, but trying to put a number of it, one that will stick, is pretty hard.
"We have shown you a real business case and the numbers stack up. But you still say no"
Something that lots of people don't get is that no matter how good a business case is from a numbers perspective, we still might not be able to do anything. There are several reasons. The first is financial. We have limited investment budgets, and you can only spend what you have. Even if you have the most amazing numbers anywhere, if there is no money, there is no money. I sometimes wonder if people imagine that a bank is different to any other business in this regard. But we might not do something with good numbers and money in the budget for another reason: we might not be able to absorb the amount of change it entails. This is a big problem for most institutions.
The amount of change we can accept in any given period is finite if we want to preserve the stability of our services to customers. You can't just have people "doing things" to systems. I mean, lets face it, we are entrusted with people's financial lives in a bank, and stuff just has to work. So we have a limited number of change slots, and there is often significant contention for them. There is also a prioritisation applied: if your change is regulatory or critical to service, you'll get a slot. If your change is anything else, you can wait in the queue.
"All I have to do is get a meeting with <C-suite executive> to unblock this deal".
The reality of those kinds of meetings is that C-Suite executives are not stupid. They realise that with their big responsibilities, they can't possibly have every detail of their operations in their heads. So they ask for advice. The idea that they make critical decisions in isolation is really quite bizarre. On the other hand, if despite everything someone goes and sets up one of those meetings in order to "unblock" something, you can guarantee that everyone else will be very annoyed. Annoyed enough, in fact, to probably never take a meeting again.
"I will only meet with <insert senior management level> due to <status/time/preference>"
You'd be amazed at how often deals go south because someone with a year or two of experience – apparently far away from decisions – has decided that something is too hard to do. The fact of the matter is that as in any organisation, the people at the coalface have significant influence on what goes on. Projects can run late, over budget and get cancelled altogether if the coalface people don't like what is happening. Then too, their line managers are likely to be someone removed from the day-to-day tech anyway, so guess who it is they go to get their advice? You got it: the apparently junior people working at the coalface.
I suppose, when you think about it, all of this seems relatively obvious. Still it is amazing to me how many people sail through our bank with notions that the quality of their solution can overcome these kinds of barriers. Practically speaking, technical competence is no longer the differentiator it once was anyway.
Hire people that have worked in a bank to work the bank. Not individuals that have worked "for" the bank as part of a contract. Ones that have had to deal with the realities day to day from the inside.
I'd be surprised if the sales success rate didn't jump quite a bit, if nothing else because stuff that would never get up will simply not get presented.