Bruce Pannaman: Fintech Innovation - Bridging Finance and Technology

This transcription of the podcast is AI-generated and may contain errors or inaccuracies.

Matt

My name's Matt and I will be talking with Bruce Panaman out engineering and learning in Fintech. And you lived in London, so it's a capital of Fintech and he worked for nine Fin which is a fintech company, but he worked in a different, in a different like companies before in a different industries. And I'm wondering, do you see some distinctive differences in working as an engineering leader for the fintech company versus other industries?

Bruce Pannaman

Yeah, great question. There's so many differences here and nuances, especially for people who come out of the traditional computer science backgrounds. You come out and obviously you see the big, the big four, especially getting people in consulting side of things and also just the apps that you have on your phone. Think I'd really like to work for one of those. I'm inspired by it, I use it every day. So there's a leaning towards that. But obviously, as you said, finance is one of the biggest industries in the UK and fintech is one of the, one of the gems of this country.

For developers themselves though, there is a bit of access to it. The finance world and the software development world don't really clash until they get to fintech. So you know, one of the big disadvantages, especially for B2B fintech and things like 9fin, it's very hard to explain to your grandma what you do for a living, which is quite funny. You start talking about bonds and loans and AI analysis and it goes straight overhead and you have to start thinking, okay, well it's with, yeah, building apps, building computers, that's the one. So there, it's, there's the glamour aspect which is not quite as great. However, the impact is huge. Obviously with B2B fintechs it's.

Sorry, the B2C fintechs, it's obviously you are part of everyday life without your card, without your Monzo account, but your account, you wouldn't necessarily be able to do anything. You won't be able to go to the shops and get your meal deal at lunchtime. You wouldn't be able to go and get that extra pint in this beautiful hot weather. But in the B2B side, it's even more abstract with 9 fin especially, you know, I was one of the many people who have joined 9fin from engineering have to work out what the difference in a bond and a loan is. The average person down the street doesn't necessarily know, but I've had a fantastic education from all of the amazing analysts and all the amazing specialists at 9th and to learn not just how this world works, but also the sheer impact it has on everyone up and down the street in terms of their pension funds, in terms of their investments. The fintech world in terms of the tech space and how developers are there, it's got a reputation for being a bit harder and being a bit, I guess, a bit more brutal. But I don't think that's always the case.

Obviously there's some companies which have quite an aggressive OKR structure and it's, you know, it's very, very metrics driven and you've got to keep on top of your personal metrics but at the same time there's the impact side as well and that's what drives a lot of people, especially at the early part of their career into fintech. The diversity is also very important as well. Everyone's mind when they imagine a bank or a big financial institution, they imagine that everyone is a white male with a two tone shirt looking out of a glass building down on the city.

But that's not the case. When you come behind the doors with diversity of people you get diversity of thought and that's what's really important to drive the innovation, get the new ideas through that really make a difference the, the customer. And I found that once people are in the door, once they start the interview process and even more once they start at 9 fin, they really enjoy this aspect and they see a level of innovation that they wouldn't necessarily expect from finance because of the reputation of legacy banking systems and technology.

Matt

So thank you for like painting the picture, like really, really complex I would say. And what caught my attention, despite of your experience in the fintech aria, you work as a data scientist in a few organizations and nowadays we are so hyped about it because of the ChatGPT. And I'm just wondering, do you use some kind of large language models currently on the 9th fin? Have you created some interesting proof of concept that worked for you? Maybe you could elaborate on that.

Bruce Pannaman

Yeah, we do use LLM models quite a lot. I think one of the major USPS of 9 fin, very specifically is the speed and the automation that we bring to the process, which traditionally would take flaws of analysts going through, filing reports, you know, kind of feeding into that stereotype I was talking about earlier. But what we've built at ninefin is true automation where we pull in different documents and data sources from open sources and other sources that we buy and that we use LLMs, NLP techniques and other, you know, recommendation engines and things like that to be able to extract the information through A fully QA process, but essentially get the insight from first published into the public domain to into our systems, comparable with other instruments and things like that, within minutes, which obviously with a pure human manual approach is just not possible. So the LLMs are so flexible in terms of what they can do, how they can understand human language, but also how they can create human language as well. There's loads of different clients that we have who are lots of different use cases for the data we're collecting and analyzing. Might be people that want to buy these financial instruments, it might be people wanting to sell them, it might be people looking at the legal aspects of them. It's really important that we can take the same data and create multiple views of it that are as useful as possible to those different use cases as quickly as possible.

So a standard view of what we have in terms of our data models is key to expand into those. But creating manually those different views, those different terminologies and those different focuses on those different use cases would be impossible without state.

Matt

And then regarding the machine learning AI LLMs, I feel that there is a lot of R and D around this area. I mean like even if you create some projects in house, this is a lot of R and D, right? And it's really easy to make a mistake or make like wrong bet. And I'm wondering in your case, because you have a bit of experience here, would you, do you have like some lessons learned that you would like to share or you could share with other leaders, engineering leaders, who are considering, you know, running some pro of concept in their organizations?

Bruce Pannaman

Yeah, completely. So the way of two humans working, communicating with each other, where each other stands for each other. Get from it, from business point of view, this is, you know, hundreds and hundreds of years old in terms of being refined, in terms of making sure that those patterns are there. But having interactions between a AI model and AI output and a human is something that's still quite new, which needs a lot of trust to be built. If you, you know, for instance, if you have a meeting, you do the old style where somebody comes in and presents the information.

Take some Q and A. You know, there's all the standard things you look at.

First impressions matter. This is why, you know, you need to have a nice firm handshake. They always say, because the way that you relay the information, information itself is only half the communication, the body language, how you add to it with hand gestures, how you communicate and build that trust before you even go into the detail. As I said, it's such a Common thing which has been around for hundreds of years and AI needs to be able to replicate that to build trust in what it's actually saying. So with this, what I'd say is a practical tip is to go slowly into it. Make sure that you're running the right A B tests with the right different models. Don't force people down an AI route because not everyone wants it.

Some people want that personal touch and what's kind of do things a different way. Provide the option, but make sure you've got really nice controls over what your coverage is in terms of your user base. So, you know, at 9fin we use feature flags a lot, meaning that we can deploy a new model which you can either replace an older one or could be a brand new one. And then we won't just go, here you go, this is our interface now. And everyone thinks, how do I trust this?

Is this right? I'm not sure. Introduce it to a certain cohort which has been tested with test improve, then open it up ever so slightly, test improve and gently get there. Measuring the results, measuring the interaction, measuring also the conversions to the actual, you know, the success of what the customer is actually trying to do and make sure that with the first user that you've got it correct. And you can essentially go use case by use case to a certain extent so that you don't massively overfit for one and create a situation where another cohort is very, very unimpressed with it.

Matt

Let's talk a bit about what you have on your plate because recently we were discussing about the hiring and setting up the processes. We are currently at the stage where you need to build like a pretty big team and scale it up. And in pretty challenging model, I mean the hybrid, when you have the people remote and you are scaling fast, this is kind of a challenge, I would say. And I'm just wondering if you could elaborate on that, like what is the most difficult part for you here?

Bruce Pannaman

Well, I think this model, I mean there's two different parts there, I guess. The hiring side, it's very difficult. It's really important to get it right, especially for a company which three, four years ago was a tiny little 20 person startup. And we've grown so quickly through the commercial success you've had at ninefin. It's really important to keep that culture. So, you know, just like when you've got a really good crowd of friends, it's really important to make sure that you know who's coming into that group of friends, making sure that everyone's friendly, it doesn't change things in the wrong ways. So there's a big measure with hiring.

The most important thing I find is really working out why people want to move what they're looking for in their career. For us as a company, it's important that there'll be a culture ad something which they can progress the culture of the company. The reason why people are excited to go to work on Sunday, reason people excited to go to that workshop, add to it and create a new element which fits and everyone will be really excited for. But on the other side, making sure that all the projects we've got, it's really closely aligned to someone's career goals. Changing job is a huge risk. You put your notice into your old company, you sign a contract, the new one, you don't know many people there, you don't know if it's going to work out. It's a huge risk for you as an employee to do that.

So I think to reward that risk, it's really important that we think about that person's CV more holistically. Is their time at ninth and going to be that time where they get the biggest jump in skills and experience. The time where they'll look back in 10, 15 years time in their career when they might be job and think, yeah, that was my big break. That's when I really kind of moved forward. So I think, yeah, that's what I kind of focus on to make sure the hiring goes right. It's really tough to focus on these things, but we have a really, really good talent team at 9fin who are fantastic at listening to the feedback that goes on, pulling it all through, asking the right questions and creating a really effective hiring funnel, meaning that we can spend the right time interviewing in high detail the candidates which are very, very promising and make sure that we give detailed feedback to those who don't get down into that process to help them improve for possibly next time. In terms of the remote work, this is something which obviously everyone moved to remote in Covid and some companies have come back, some people have kind of stayed in the hybrid model.

Trust, autonomy for me are the main themes here. Obviously being respectful of each other, making sure that you come to the meetings, you kind of decline them if you can't come and that's fine. But within that being respectful, other people's time. Some people truly like getting up five in the morning, getting on with that ticket and then they're done by 4:00 in the afternoon of their last meeting. Some people are the opposite and you know, just about get a coffee in for their 10 o'clock meeting and might go till 7, 8 o'clock in the evening. People's, you know, at the end of the day it's a job, your family, your friends, your life is more important. A job may last, hopefully five, six years is very, very rewarding.

But your friends, your family, they lost a lifetime. So neglecting the friends and family for the job because tight hours I think is a real shame. It's a real value of 9th and we kind of have it in our values of friends and family come first which is a huge pull into nine. People really enjoy that and within that it's really important we give a balance. Remote working is a really good way to bring that balance, reduce the commute time. It's still quite nice for everyone to be in the office. We never force anyone to come in.

We sort of encourage and incentivize people to come in with the socials, with the collaboration parts. Because I personally find it, you know, a bit annoying when you join a company that forces you to come in and you're still spending all day with your laptop on a Google Meet anyway. So it's, I think the office has always got to be something more than you can get at home to enhance that work experience whilst at the same time respecting boundaries, respecting that work life balance. And I think with happy people and people with that work life balance, that's where you get the stability in terms of someone's workload. It's also where you get the sustainability of someone being able to really deliver in year three or four of their time with your company just the same as year one in those first six months.

Matt

So we discussed the hiring processes, scaling work life balance. And there is another topic which is really important and we tackled it recently. Growth of engineers from day one. And I read your course on LinkedIn and it got my attention and I remember it as a rule of 70, 2010. Maybe you could elaborate on that because I think this really interesting approach.

Bruce Pannaman

Yeah, definitely. So for me personally I'm a very self taught engineer. I did mechanical engineering at university, never touched any code. It was mostly jet engines and trying to make things break in a simulator which is quite good fun. So with that the way that I learned was through meetups, through learn different things, doing tutorials, lots of online things, lots of books as well for the theory. But really it's the practical side which I really, really engage with and that's how I kind of grew through to learn the different skills I have. So I guess for a job, when you think about growth within a job, yes, you can kind of pay for the courses and you can pay people to go to conferences and give them time off for that.

But the thing that you have within a company that no one else has are projects and work that is so tied towards that growth. People to apply, apply that new knowledge they've learned because that's what solidifies it. That's what takes it from the tutorial to, you know, going towards that mastery of that skill. So the projects is what I've kind of said.

The projects are 70% of learning. Engineering managers at nightfin spend a lot of time discussing with engineers what their ambitions are, what sort of engineer do they want to be in two, three years, and plotting a path towards that. As said, as part of the deal, making sure that 9th Inn is the real step gap in their skills, experience and the projects themselves. We kind of always look at a new project that comes along. Obviously there's a huge commercial analysis, does this help our customers? Does this help the company? But the next thought for me is, who would this be a really good learning experience?

Who would really benefit from applying some of the new knowledge they have to this? Because it then proves that they can do it. It solidifies the understanding and it also means that they can take it forward and apply it in other places, the people side as well. The other advantage that you will have in your company, which other people might not, is the other engineers that you have. So creating the right environment for collaboration, for skill sharing and for, you know, demoing different things means that it's not just learning from the project, it's also from other engineers. You know, you're looking at someone's pr, seeing a new technique that you haven't seen before, Googling, oh my God, what's that? And then you realize, this is blow my mind, I need to use this more myself.

And if you're in smaller companies or if you're kind of, especially if you're solo coding on side projects, you don't always get that. And this is something that you as an employer can make sure that people get as well. But at the same time, it's really important to emphasize the pair programing aspects, the PR aspects, not just about getting it reviewed and getting into production, but also who's viewing it, who's asking the questions. Even if you put a comment saying, great job, I learned something today.

Thank you so much. That is a perfect contribution to a pr, which helps, you know, that share that knowledge around the different teams.

Matt

And I'm always trying to look for something which is contrarian, like contrarian approaches or controversial approaches in, I don't know, building the team's approach to engineering that works for you, but maybe are not so common on the, within the, within the engineering years. So I'm just wondering, do you have some kind of like, you know, your special sauce, you know, that you could share with us here?

Bruce Pannaman

Good question. Yeah. So the obviously kind of read the books around theories and different methodologies and it kind of seems like they've got all the answers. But then when you actually look at different companies and you speak to different founders and different technical leaders, they don't always follow those frameworks because, you know, one size does not fit all. So I'd say the real secret sauce is being flexible and obviously understanding what's out there because there's been a lot of research done into these different spaces, there's been a lot of trial and error. So you can leverage the learning that's already there. But understanding what the current problems are, understanding where especially the growth problems are how to grow the team, how to grow the efficiency of the team and how to make sure you can produce even more high quality technology for your customers is. Yeah. Once you got that understanding, you can then start applying certain bits of it at a time, trying things out, seeing how it goes, you know, that softly trial analysis, repeat again approach that I talked about earlier that really makes sure that you're not just applying, you know, especially the big things like Agile framework or safe framework.

It's very easy to just come into a new company that doesn't have that and go, cool, we are doing full on sprints and agile. Does it solve problems?

Some problems probably. Does it solve all the problems? Most likely not. So you pick and choose little bits of different methodologies and create that special blend of what creates an engineering culture, what creates that engine of products and engineering delivery.

Matt

It's funny that you mentioned the books. Right. So there is a lot of business books on the market and I think in those books are all the things for like every entrepreneur that they can learn from it and if they apply, it works. But it doesn't work this way. Right. So I think what you mentioned like the blend of those things and this is like kind of the secret sauce that make, that makes the company work.

Bruce Pannaman

Yeah, it does. I mean the ones that have been particularly inspiring to me is teams Apologies was fantastic in terms of how it talks about ways to make your core teams go faster by Abstracting the non domain core work away into those enabling teams or those specialist teams, that kind of support so you can bring people out, make sure that the complex bits have the attention they need. But to remove those bits, the people are in the domain focus the product focus, they call it streamlined. Teams can go at full pace, iterate as quickly as possible, especially things like dev metrics. They always talk about feedback loops and the trick to good engineering teams is having the tightest feedback loops possible. If you're spending time working on infrastructure that is very common across other teams, if you're spending time around security practices which should be common across the company, you're not getting those feedback loops as quickly. Other things that are very inspirational is a great book called Crossing the Chasm which do about when a startup becomes a scale up, what the differences are in terms of thinking, in terms of the skill sets that are needed.

And that's not an overnight thing, that is a sliding scale and it's a progressional change that happens over, you know, maybe two years, two, three years. So it's working out what which of those struggles are coming next, which those struggles are happening now, and tackling those one by one as you go through. But also with the view of future of that, you know, this new solution only has a certain timeline. It's not going to be something that will go on forever. It's something where we will have to change at some point, which is where being humble, taking that step by step approach and keep on analyzing and measuring what's working and what's not is really important.

Matt

And talking about the changes and progress. I experienced that in my company each year. I feel like I run a different company. Right. It's completely different. So and now you're in a stage that you are scaling the team. So I'm just wondering what is your current team structure today and what are the processes around the team, how do, how do you organize and maybe what do you want to change in the future?

Bruce Pannaman

Yeah, great question. So it's a journey, we're along this journey, we're not quite done yet. Last year we're in a position where we had very established front end engineering teams, back end engineering teams and data science teams as well that kind of build the AI and the machine learning models feed in in terms of technology. What it meant is that during the build process of the product life cycle, you would introduce more steps to each milestone. Do you have to do the backend work and then wait for the front end work? Then we can make sure that the Model works back and forth or do you do it the other way around? And it produced a lot of different steps and there was a bit of handover which didn't always work out.

So what we thought is that the customer themselves, they don't really care what's front end, what's back and they care about the product and does it work. So therefore we really focus on how can we bring these iteration cycles, these cycles where we can show what we've got to stakeholders and clients, get their feedback, either pivot or double down depending on that, and work as quickly as we can towards that customer value. That was kind of our North Star for the change and what we really moved towards is a very all inclusive cross functional team structure. So we have PMs and tech leads at the very, very top. This is a great seed for a team because the product manager has all the information they need around. What are the customer pain points, what is the feedback that we've been getting from our stakeholders and our customers, what are the bits that we haven't done and we kind of wish we had done? What are the noise to haps?

What is the most commercially viable thing to do next in the market with our competitors? Better analysis. Then on the flip side, the tech lead, all the information about our current stack, how we can leverage it to create new products, where the weaknesses are that we might have to work on as part of the scope of the project, what skills are needed to take this build from the requirements all the way through to launch. And then after that we just say what, what do we need in this team? What do we need to get that iteration cycle of this idea as short as possible. And we'll have data scientists front, engineers back engineers, designers, all sorts of skill sets that we need within that team in the amounts that that given project or that team needs to really go at it and make sure that we can be as fast as possible on that first version. They focus on kind of two to three week milestones, give or take, where we, as I said, we can either pivot or double down based on the feedback and we do quite regularly, which is very, very important to us.

And then outside of that, as I said, we've got lots of enabling teams that we kind of stole from team topologies. So we've got engineering management as an enabling team. Usually engineering managers are placed within each of the cross functional teams. We've decided to go down a route which is actually, it seems to be meta is the only big meta and stripe seems to be the only Two big companies that have gone down this route. A lot of research into why that is and why they are the outliers. I think a lot of it comes down to context. If you have people seed in one team, it becomes a leveling, leveling field essentially where some teams will be racing ahead, some teams will have the problems, but you've locked in your resource into those teams and it's much harder to huddle and mop towards where the problems are as an engineering management team.

So we have a team that sits underneath, they manage all the engineers in all different teams. And it means that we've got lots of lines of information, different perspectives and different viewpoints to be able to really get an understanding of the problem and proactively try and solve those blockers as soon as possible. The other very exciting team that we've got is the platform team. So, you know, we've moved from DevOps over to SRES and then platform engineering is the new paradigm and we're very excited to be a part of that movement. It feels so much more scalable than having to have all the infrastructure moves go through a single team, which might all be on holiday that week or might be low on resource that week because some people are away or some people are ill. But really enabling developers to have the information, have the resource they need, without the complexity of having to pick up a services sheet of AWS and think, right, what are we going to use to put this into production? So they build paved road approaches where the terraform modules, the CI modules, all those different parts can be moved in and really easily built into bigger.

I guess the engineers are building out of bigger building blocks than what the cloud providers themselves can have, which again, speeds up those teams towards those iteration milestone demo points. It's quite an exciting kind of architecture of an organization. We're seeing quite a lot of success with it. It's been a lot of change and it's been quite a difficult journey to get towards in terms of reorganizing people, especially with the growth aspect, making sure that with all of these reorganization changes, that we are still having people in those positions where they are best poised to learn and grow in the way that they want to in their careers.

But it's very exciting. I think it's something that's very unique to knowing Finn and I'm very proud of what Noifen's created here because it's very exciting. Everyone's enjoying it and we are doing very, very well in terms of delivery.

Matt

Speaking of pain points, I'm always wondering what are the biggest pain points or challenges of your role that maybe nobody's widely mentioning? Maybe what do you type in Google? Right? What kind of challenges are there?

Bruce Pannaman

Yeah, so I think it's the same challenges I think with lots of other teams and I guess that's kind of velocity versus quality. If you go too far one side of the spectrum towards quality, you build the most world class technology systems that people will look at and just think, wow, this is genius. I love that I'm going to write books about how good this architecture is. But you run out of Runway and your customers don't like it and you're not focused there. If you go too far the other way and purely focus on velocity of product development, you have very happy customers. But it won't last very long because your product won't work and it'll be very buggy because of all the tech that's there. So I think the challenge that we have is about finding that balance and really addressing that balance whenever we get to it.

Because the answer could be different every time. If there's a really good commercial opportunity where we can be first to market in something or we can overtake competitor on something, it's worth leaving a bit of tech there as long as we make sure that we come back to it. As long as when things are a little bit quieter or when we don't have those opportunities, we, we can use the opportunity in terms of time to go back, bring that tech bit in and move back along the spectrum towards that high quality, fully fledged engineering system we always envisaged and we had in our perfect minds.

Matt

And what is the hardest thing that you have ever done in your career and what are the lessons learned out of it?

Bruce Pannaman

Good question. Hardest thing in my career. So I guess it's not necessarily to do with technology directly. When I was at a small startup called stalkcard, I was part of the FCA small banking license application which brought a whole level of compliance that I'd never seen before. I'd always worked with open source technologies, open open source machine learning models or self trained machine models and working. What it meant is we then had to describe what was there, fit it to that formula and it was quite brutal. There were so many intricate questions that I just hadn't considered yet because the company wasn't at that stage.

Our technology is not at that stage yet. It involved the entire company's operations, it involved the business plan, the governance side. So you know, really the learning was within this one is not to go Too deep into things. Make sure you're answering the question and avoid giving yourself any more rope to hang yourself. But we got through in the end. We got to a point where we were out there. We were, you know, servicing around 20,000 users in terms of their parental banking needs, and it was really, really fantastic.

But that was really tough. A lot of thought, a lot of going through the different questions, huge documents that had to be gone through and draft after draft as well. It became very frustrating at times, but I'm glad we went through it, but hopefully never again.

Matt

And Bruce, last but not least, the question I wanted to ask you is could you recommend any books, podcasts, resources that have been particularly helpful to you as a tech leader?

Bruce Pannaman

Well, of course, your podcast, I listen to it a lot. It's fantastic. He's some really interesting interviews, some really interesting insights. Kind of give you that purview of different startups and different parts of the tech space and what being worked on. My other favorites is I really like the stories that come out of the acquired podcast. It talks about those startup journeys, even ones that become big, big companies, but focuses on where they started, how they got to where they are, and the different struggles that happened along the way. But it's built in a really nice story format.

Say in chapter one, we started up, we're at probably had no idea. Chapter six, we'd raised our series C.

Things got heavy. Series eight, we ipo. Another one that I love is the Scrum Master Toolbox podcast. This is very, very regular. They're like 10, 15 minutes kind of. You can listen to one of them. I always listen to them when I'm on the way to the train station.

And it's almost a little point to think about for that day around team structure, around kind of giving ambition to teams to move forward. Slots of management tips as well, which I usually use and actually kind of create templates my one to ones later that week. There's a really good point. So it fills me with inspiration, new ideas. The other thing I love as well, not a podcast, but I absolutely love CTO Craft conference and the Slack group. I went to the conference this year and I really enjoyed it, Meeting the people, meeting, seeing the different talks from all the different spaces. And they have a fantastic Slack group, the community there to ask questions of.

You can help other people with different questions and you really get that insight and that collaboration between that group.

Matt

Yeah, the city of craft. I can confirm my head of engineering is going always there and he really, really appreciate it. So I think they are making the good job there. And it's great community, right? Yeah, it is.

Bruce Pannaman

That's what I really enjoy about it. There's lots of great meetups that are good for different developer frameworks or coding languages, but when you get to kind of that tech leadership level, there's fewer meetups. I think there are definitely some good ones, but these communities that you kind of really start to go into more. Yeah, Amazing.

Matt

Thank you Bruce for today. Thank you for all those insights and your time.

Bruce Pannaman

No worries. Thanks so much for having me on. It's great to speak to you. Follow Matt on LinkedIn and subscribe to the Better Tech Leadership newsletter.

‍