4 ms·

what about banks make them so difficult to work with?

jacques_chester 6y ago
It's a mix of things. The biggest is that they're just enormous, so nearly every engagement is pretty much from scratch. As in: single departments of single divisions could dwarf us in headcount and revenue. It can be dispiriting for Labs consultants and I know people who quit because of it. A lot of the time you hit what I call "veto culture". You are forever running into groups, committees, boards, bureaus, offices of the whatever etc etc who have the power to gate some change. Those folks almost always say "no". The logic is simple: if they say "yes", and something goes wrong, and they are blamed for it, then they might lose their job or at least risk a bonus or promotion. But if they say "no", there's no risk to them. In practice it drives everything productive underground. We often relied on discovering the nomenklatura who actually did things as we went. The parallels to the USSR's experiences (as I understand them) were fascinating. It's important to note that I don't see any of this as being a deliberate outcome. In general folks don't wake up and ask "how can I make my company less productive and pleasant today?". People do what makes sense to them, based on their experiences. But I have seen how culture can drift into a bad place that's hard to dig out. Big banks seem to have even more of this than regular megacorps. I know some folks who worked in the Federal sector had some similar experiences, but overall it seems like a lot of the time it seemed more manageable due to different incentives. In fact a lot of the compliance / standards folks were often thrilled that someone wanted to talk to them.
- thebigbank 6y ago
  This is very true. I work for a big bank and purposely overestimate any work because: 1) the veto culture; and 2) it allows me time to do work not counted in the "sprint". The actual amount of development I do is between 20-30%. The rest is taken up by "agile ceremonies" and convincing multiple layers of veto holders not to veto. Often times I'll spend 2-3 days developing a prototype and then 2-3 months convincing people its a decent idea. (I put "sprint" and "agile ceremonies" in quotes because its waterfall presented as agile)
- golemiprague 6y ago
  It is not only that, banks have different needs comparing to a software company or a company like air bnb. Agile is less suitable because many times you need very accurate planning and synchronisation of various system which need to work perfectly in a certain time and according to strict regulations. There is no place for gradual incremental changes, it is money and everything must be perfect by the time it works. So the whole state of mind is more geared towards that and even when you do have projects which could work better by implementing certain agile practices, the general culture is different.
- donw 6y ago
  Also from Pivotal: we had the exact same experience in working for the Federal government.
gen220 6y ago
At huge financial institutions, software improvements do not usually improve revenue. At the very best, if you’re lucky, they might (although not provably) improve the derivative of revenue or cut some costs. And at most banks, revenue projections are fragile and magical, making revenue’s derivatives are volatile and doubly magical. In that context, try explaining to a non-technical director and his or her director, why the system “needs” fixing, when it generated consistent profits for the last decade, and why the risks of instability are worth it. So, banks are understandably the epitome of risk-averse. Why make changes to the current system, when (1) the current system works, (2) almost nobody fully understands how or why the whole system works and (3) it generates revenue that’s 1000x the salaries of the engineers employed to keep it running? It’s not an environment where the dividends of innovation are typically worth the risk: besides, from the bank’s corporate perspective, there’s a whole startup industry (fintech) that exists to do the innovating “for you”. In short, it’s a division of labor, but it’s not a very transparent one to the unannointed, and it’s very frustrating to be on the “wrong side”. Superficially, they have tons of money: think about all the interesting problems they could solve with that money!! But of course, nothing is that simple.
- jacques_chester 6y ago
  This was very insightful. Thankyou. Editing to add that this did fit one thing I concluded (before learning economists found it to be obvious): diffuse risks almost never get handled. Only sharp, tangible risks really get thought about. "We had an outage" can lead to someone getting sacked, so fear prevails. But "we slowly strangle ourselves to death and then get eaten by a nimble upstart" is nobody's risk. It's invisible and immeasurable. I don't think small-team agile is particularly immune to this problem. It just tends to have a smaller surface area for diffuse global risks.

It's a mix of things. The biggest is that they're just enormous, so nearly every engagement is pretty much from scratch. As in: single departments of single divisions could dwarf us in headcount and revenue. It can be dispiriting for Labs consultants and I know people who quit because of it. A lot of the time you hit what I call "veto culture". You are forever running into groups, committees, boards, bureaus, offices of the whatever etc etc who have the power to gate some change. Those folks almost always say "no". The logic is simple: if they say "yes", and something goes wrong, and they are blamed for it, then they might lose their job or at least risk a bonus or promotion. But if they say "no", there's no risk to them. In practice it drives everything productive underground. We often relied on discovering the nomenklatura who actually did things as we went. The parallels to the USSR's experiences (as I understand them) were fascinating. It's important to note that I don't see any of this as being a deliberate outcome. In general folks don't wake up and ask "how can I make my company less productive and pleasant today?". People do what makes sense to them, based on their experiences. But I have seen how culture can drift into a bad place that's hard to dig out. Big banks seem to have even more of this than regular megacorps. I know some folks who worked in the Federal sector had some similar experiences, but overall it seems like a lot of the time it seemed more manageable due to different incentives. In fact a lot of the compliance / standards folks were often thrilled that someone wanted to talk to them.

thebigbank 6y ago
This is very true. I work for a big bank and purposely overestimate any work because: 1) the veto culture; and 2) it allows me time to do work not counted in the "sprint". The actual amount of development I do is between 20-30%. The rest is taken up by "agile ceremonies" and convincing multiple layers of veto holders not to veto. Often times I'll spend 2-3 days developing a prototype and then 2-3 months convincing people its a decent idea. (I put "sprint" and "agile ceremonies" in quotes because its waterfall presented as agile)
golemiprague 6y ago
It is not only that, banks have different needs comparing to a software company or a company like air bnb. Agile is less suitable because many times you need very accurate planning and synchronisation of various system which need to work perfectly in a certain time and according to strict regulations. There is no place for gradual incremental changes, it is money and everything must be perfect by the time it works. So the whole state of mind is more geared towards that and even when you do have projects which could work better by implementing certain agile practices, the general culture is different.
donw 6y ago
Also from Pivotal: we had the exact same experience in working for the Federal government.

gen220 6y ago

At huge financial institutions, software improvements do not usually improve revenue. At the very best, if you’re lucky, they might (although not provably) improve the derivative of revenue or cut some costs. And at most banks, revenue projections are fragile and magical, making revenue’s derivatives are volatile and doubly magical. In that context, try explaining to a non-technical director and his or her director, why the system “needs” fixing, when it generated consistent profits for the last decade, and why the risks of instability are worth it. So, banks are understandably the epitome of risk-averse. Why make changes to the current system, when (1) the current system works, (2) almost nobody fully understands how or why the whole system works and (3) it generates revenue that’s 1000x the salaries of the engineers employed to keep it running? It’s not an environment where the dividends of innovation are typically worth the risk: besides, from the bank’s corporate perspective, there’s a whole startup industry (fintech) that exists to do the innovating “for you”. In short, it’s a division of labor, but it’s not a very transparent one to the unannointed, and it’s very frustrating to be on the “wrong side”. Superficially, they have tons of money: think about all the interesting problems they could solve with that money!! But of course, nothing is that simple.

jacques_chester 6y ago
This was very insightful. Thankyou. Editing to add that this did fit one thing I concluded (before learning economists found it to be obvious): diffuse risks almost never get handled. Only sharp, tangible risks really get thought about. "We had an outage" can lead to someone getting sacked, so fear prevails. But "we slowly strangle ourselves to death and then get eaten by a nimble upstart" is nobody's risk. It's invisible and immeasurable. I don't think small-team agile is particularly immune to this problem. It just tends to have a smaller surface area for diffuse global risks.