My bank workshop experience

In early 2020 I was involved in running a Python workshop for a bank. My involvement was entirely last minute and it turns out that it wasn't in a part of the banking industry I was all that familiar with. I had thought that people would be interested in learning software topics related to the core aspects of banking like payment processing, but this entirely missed the mark. The people attending and their job roles clearly showed that retail banking has changed dramatically. I saw quite clearly that traditional retail banking is far less profitable than in times gone by, the low interest rate era we have is causing tremendous pressures on commercial banking and if this continues many of the traditional banks will close, this seems inevitable in this policy and political landscape. I jotted down some notes on all this in the middle of 2020 because I felt there was something I needed to write about but I couldn't quite put it into words. Looking back on this later I feel there's a bit of a story of a "how not to" do a workshop that might be worth reading.

This workshop was a disaster for a number of reasons, mostly due to poor communications beforehand about what the requirements were which then led to a far inferior preparation for the workshop as compared with usual. As much as it seems completely mundane now, the Covid situation weighed rather heavily on this event, this particular company had never really done remote work before and the week that this workshop happened they made a decision to move as much of the company to remote work effective immediately. There was a general sense of uncertainty as well, a good example of this was that the venue that we held workshops at was clearly concerned about the pandemic situation but honestly didn't know what to do since it was so early on and information at that time was particularly scarce. However this really was the last event I did that was in the pre-pandemic era, as a few weeks after this the pandemic was well and truly happening and had entirely consumed everyone's attention at this point in time. But this workshop was before all that. I remember arriving at the airport, no masks and no disruptions to flights at this point in time, and meeting up with my boss who was flying out where he told me that the participants were really interested in data science and asked if I could scrap the original materials in favor of something that fit their needs better. This was at 7pm and the workshop was starting at 9am the next day. Frequently I'd pull really long hours to meet last minute demands like working 20 hours on the weekend to get something ready for later in the week. But this was so last minute that it was almost comical. I could have prepared something but frankly I was too pissed off by how utterly unreasonable the request was to really give this a good effort, I figured if I'd been set up to fail this badly I just had to let the workshop fail to meet my high standards and just try to salvage whatever could be salvaged. And fail it did, most of what I presented on was poorly prepared and didn't do a good job of meeting the needs of the people there. This lack of preparations came about because I was never able to talk to the participants ahead of time, something that really is a massive red flag in the workshop space. If you can't have direct communication between the facilitator and those attending - sufficiently ahead of time - a workshop will on average be far less good and unfortunately this case was no different. I was left with only being able to go with my assumptions of needs, and these assumptions were way off the mark. I feel like this workshop was a crucial part of sparking my interest into how the banking system really works, something that I spent a lot of time researching in 2020 and 2021, had this situation come up again now I'd be able to make an outstanding workshop presentation, but back at the beginning of 2020 I had no idea how much the banking landscape had changed and what this meant in terms of practical technical and organizational content.

Despite this particular course not living up to my personal expectations in retrospect I'm really glad that I ran this course because it taught me a few things and started off some important chains of thought that I've been investigating further since then.

• Differences in organizational politics between engineering firms and non-engineering firms
• The changing of the commercial banking industry, how there has been a shift from core banking services towards marketing and speculation. This in part stems for a combination of interest rates that are artificially kept low and an environment in which lending has become more difficult.
• Technological progress is incredibly deflationary overall
• Technological unemployment will hit every sector hard in the next few decades, banking being no exception to this broader trend.
• The overall trend of consolidation in banking
• The rise of competitors to the traditional commercial banking sector like neo banks and decentralized finance

One such chain of thought was about the differences in organizational politics between engineering firms and non-engineering firms. This is something I've been thinking about a long time but this workshop really brought it home for me. There were people who were supposed to be doing data science work in converting workflows from other closed source platforms to Python, they had been waiting multiple weeks before they got access to the installs for the closed source analysis software. At this point they then had to wait yet more weeks for access to all the data. I'm fully aware of the fact that big enterprises move slower, but it's this type of peculiar adversarial relationship between people doing development work and the "IT department" that is only possible in organizations with sufficiently advanced political and organizational dysfunction. To be very clear the drivers of promotion at this bank seemed to be mostly political in nature and not based on engineering ability. Another aspect I've seen in many dysfunctional organizations is that the IT department is seen as a narrowly as a cost center, even if technology is completely core to the profitability of the firm. Technology is obviously crucial to any modern bank, any extended outage of services like servers would be devastatingly bad to a modern bank as payment processing would cease to be possible. Maybe at one point in time the non-computerized contingencies would have been viable, but now that people tend to just tap their cards and do online banking and a huge number of actual branches were closed down and even a huge number of offices have closed with more people working remotely from home, it seems that this is now impossible. Interruptions to service are an existential threat to the modern banking system. To be fair a lot of effort is put into ensuring this uptime, but such a value enabling operation, in fact one that enables all of the value is often still seen as a "cost center".

This "cost center" vs "profit center" thinking leads to all sorts of strange political dynamics. A really good book to explain the intricacies of brutal machiavellian office politics and the world many middle managers live in is called Moral Mazes by Jackall. I'd been reading this book around the same time I ran this workshop. I like how this book is written in by an outsider in a sociological study style since it's a far more compelling read than if it were the typical business book. Many of the dynamics behind the interactions with this workshop are covered especially well in the book. Specifically there's a chapter that talked about the interactions with staff and external consultants that was particularly pertinent to this experience. In general there's a difficult dynamic that can arise when upper management calls in a consultant to work with some staff, the staff may not want to actually work with that consultant but if the consultant is hired in by people who hold power over those staff it can lead to some very adversarial interactions. The book has a much better description of all this than I can write in a few paragraphs and I'd highly recommend reading the book.

I do think however that organizations that have advancement based mostly (or entirely) on office politics cannot be solid engineering organizations. The rules of success for projects that actually depend on engineering and technology in a non-trivial manner are just fundamentally different from projects that are of a more political nature. The mindset that makes someone good at one often holds them back in the other, and holding more than one mindset at the same time is difficult and frankly beyond most people's capability. With the juggernaut of negative interest rates looming combined with extreme consumer resistance to seeing their savings deplete in nominal terms I suspect the retail banks will start to really suffer badly if certain economic trends continue. Being more effective with technology could stave this off partially but that effectiveness would be at the expense of headcount, something that cannot be tolerated by the empire building that makes advancement possible in many traditional politics-first organizations.

The rejection of genuine offers of assistance

Over the last few years I've either facilitated or attended a large number of training workshops.

I've frequently offered to people in good faith an offer to help people with their issues if they wanted to follow up and contact me. Despite this very few people actually take up the offer.

There's likely a few reasons for this but one of them was really obvious at this bank workshop, some of the attendees were brutally two faced about the whole affair. I'd much rather someone just have integrity and say that the workshop sucked, since honestly it did, rather than give good verbal feedback and scathing private feedback later. But I'm not some politically naive engineer, I know in many industries and organizations you don't get ahead by having integrity, so I understand this sort of behaviour while at the same time not engaging in it personally and not taking it personally.

What I used to find somewhat surprising is just how few people would stay in contact in situations that weren't so politically toxic. I suspect that this is because many people who offer help aren't doing so genuinely so the offer is immediately discounted, perhaps reflexively, by many people.

Going back to the bank example, there's no way the people at that one specific bank workshop could have known that I actually gave a shit given the information they had available to them at the time. So a natural cynical reaction would be of course to just discount this as salesmanship and in this specific instance I can't blame anyone who would have had that reaction since given what happened the bayesian priors point in that sort of direction. I don't say this to try to salvage something from this bank experience because there's really not much to salvage there but more because the other people I've interacted with over the last few years I'd love to hear from.

Bank python

Seeing as I've talked about what went wrong I figure it would be good to talk about how things could have been better.

Within a bank there appears to be a few different areas of technical effort. Much like other areas of work a crucial distinction must be made between work where the code is a deliverable and where it is not. In banking I feel this is an obvious difference in needs between the teams that do the core payment processing and clearing when compared to the analysts and salespeople. The people who need the data to do research and make investments have fundamentally different needs, they need easy to access data and an environment that makes it easy for them to do the sorts of analysis tasks that enables them to create value. This has to be a sensible process too, anecdotes like the one I had from earlier of people have multiple month waiting times before they can get to be productive is not just a process issue it's also representative of an inappropriate tech stack for the tasks that these people are doing.

Earlier I mentioned that were I to run this now I'd have a totally different approach to the contents of the workshop, there's a good article called Bank python that explains in detail some of the infrastructure that you would really want to get in place to allow people to work on data analysis in a banking context. Knowing what I know now I'd have made some materials that were related to this and I'd also have made a lot more materials about the sorts of data science tasks that many of these people who are working in marketing and sales would encounter at a bank. Also knowing what I know now I'd have put a lot more pressure on contacting the people who were attending ahead of time so I could have found out their actual needs instead of being forced to make a less than fully informed guess.

Much like other things in life the secret to running a good workshop is knowing your audience well and putting in the preparation time.