How to stay agile in a competitive fintech landscape?

Oleg

Hi everybody! Welcome to Devico Breakfast Bar! Here we speak with different people involved in the business landscape, share their expertise, delve into the latest tech trends, and explore the ins and outs of IT outsourcing. I'm Oleg Sadikov, and today I'm excited to have Rick Burgess, an experienced executive with a demonstrated history of working in the financial services industry. Don't forget to subscribe and hit the notification bell so you don't miss new episodes. Hi Rick! To start, could you tell us a bit about yourself and your professional background?

Rick

Sure. I'm winding a long journey. As I get more gray in my beard, my experience gets longer. I started on the trading floor, at the CME, had a couple, you know, series of things. I traded some currencies, some bonds, some interest-rate products, things like that. I ended my career down there when it went electric. And I went upstairs and basically started a pseudo high frequency trading system, which I sold to a bank. At that point, I didn't know what I wanted to be when I grew up. So, I went into financial service, got a little ball of money that I earned from the buyout. I realized I hated it. I wasn't fit. Sitting at a desk was not cut out for me at the time. So, I became what's called a wholesaler. And that means I go out and sell financial advisors – my services – to sell to their clients. And that was a lot of fun because it involved getting on planes, and eating with people, talking to people. And that's what I do. You know, I love talking to people. So, I learned a lot about business structures and how people run their businesses in financial service, predominantly, but a lot of other things. And then, I got caught in the 07, 08 stuff. And then we were bought by a little firm called Prudential. And Prudential didn't need another wholesaler. So, I went off and created a firm called Connect Lending. And we grew that to be the fourth or fifth largest alternative lending platform in the country. And my partner and I sold that. And I again moved off. And the stuff we had learned there: we took some of that knowledge of processes, and paperwork, and what we had to do. And we built Forms Logic. And so, Forms Logic ends up being a passion of mine because it solves a real problem. And the fun thing in business is you got to have a problem to solve, or you don't wake up in the morning. So, that's what, you know, in a 30,000-foot view, that is who I am and what.

Oleg

That's amazing! Great experience! Could you share a story that highlights a significant challenge you faced in your career and how you overcame it?

Rick

Well, I mean, if you ever wake up in the morning, you find challenges every single day.

Oleg

Especially if you're a business owner.

Rick

Yeah. Especially if you're in business. Sometimes you don't go to sleep. Sometimes you work right through the night. So, you know, it depends on the challenge. One of my most significant challenges was growth. You know, when you start growing, and you start having to turn over what you do – because you're passionate about it – to some of your staff, you expect them to do what you do, but they don't. They are there for, because they believe in the company at the beginning, but paychecks, right? They're there for earning a paycheck for their family, you know. So, my biggest challenge is turning over responsibilities that I started, and built, and crafted, and I think were the best in what I do, turning them over and watching them grow, and morph, and change into what somebody else is doing. Probably one of my biggest challenges is letting go. And as the company has grown, now there's people that give other people tasks cause I'm two, three, four removed now. So, my problem now is when I look over at a process, and two people are doing the same thing I used to do, I look back and go, 'Why is there two people?' And they explain to me that now that we're bigger, things are changing. And I'm like, 'Okay.' So, that is probably one of the biggest challenges in success, right? It's so horrible to say it that way, but once you get over a certain hump, and you're not as – everyone's a startup at all times cause every, you know, so you're IBM, everybody's a startup – is letting other people and processes help you grow.

Oleg

How many people are in your company?

Rick

Right now, I think we're at 18 or 19. A lot of that growth has come in the last two, two and a half years. So, a lot of coders were brought on because we have five years worth of backlog work to do. You know, you start with an idea, and you start growing, and then improvements happen, and you do things, but then you could go back, and you got to solidify all of it so it's not built on bad code. So, we're constantly in the process of redoing things that we've done 10 years ago, that weren't built to have six, seven, eight thousand clients on it.

Oleg

Wow. Great! With your extensive experience, what changes or trends do you foresee shaping the future of the financial service industry?

Rick

You know, I'm going to say I can phrase AI because AI is going to change everything, right? Until you realize that in financial services where we play – broker-dealers, registered investment advisors, custodians, things like that – no AI is going to write a program because some of these programs have never been written. So, things that have already been done, that are public, and bringing it forward, and helping you. The problem is when it's never been written before, you have to go do that. There is no AI that can help you.

Oleg

At this stage.

Rick

At this stage. Right. And that's true. But again, that's a great conversation point of at what stage do you believe that that ghost employee that's not real kept your best interest in mind and didn't expose something that they weren't supposed to expose? At the end of the day, you, as an owner of a business, are responsible for every single thing that happens in your business. So, AI is a great tool to start a process, and it's really been good for note-taking, and time management, and things that are not mission-critical. But you know, there are people now where we do marketing, and I get the one thing they say is don't let AI write your scripts, or your marketing, or PR because it'll say things that it's not supposed to say. So, in marketing, it's not there yet.

Oleg

I will say in the way that you clearly recognize that it's done by AI, and that's a problem in addition to what you're saying.

Rick

But the good news is if you're an inventive person, and you're solving a problem, that problem is there because AI hasn't figured it out yet, or somebody hasn't figured it out. I mean, we fill out forms, and we do workflow processes, but the fact is that should be child's play for an AI. The problem is there's so much sophistication in what we do. It took us 12 years to get to where we are. If AI can do it in six, I would be really impressed.

Oleg

Who knows? Who knows? Even half a year ago – okay, not half a year ago – one year ago, I wouldn't say that it's possible to do something similar that Sora does now.

Rick

Yeah. Well, the one thing I laugh about is you listen to those at Stanford MIT that always audits the new ChatGPTs and all that it's getting worse and worse at basic math. It's getting great at doing other things, but it doesn't like math anymore. Math never changes, but why is their answers changing? It's not perfect yet. And you know, I keep telling people AI is only as smart as the coders who wrote it and the ability to have as wide of a net as they'll let it cast.

Oleg

Okay. I hope we can talk in a few years to see for it.

Rick

Well, we'll see. Maybe we'll be talking to each other via AI. You'll think you're talking to me, but you won't be.

Oleg

Who knows.

Rick

See in the metaverse. That's still a thing I heard too.

Oleg

Okay. It could be, but I think it didn't go as well as meta planned it to go, let's be honest.

Rick

Well, you can plan for things to be better than current hardware, but until hardware catches up, until people like me die that didn't grow up with a headset attached to my face. I'm never going to walk into a department store on the metaverse, trying a pair pants that I can't feel. So, until that changes – people like me die – there's a whole generation that won't embrace it. And we're the ones that write the checks. So, that's a bit of a problem.

Oleg

How do you navigate the scarcity in the highly competitive fields of AI and data analytics? And what strategies have you employed to attract and retain top talent?

Rick

It's a great question. What I usually tell people is I'm a data company with a forms problem. So, you know, it's somewhat humorous, right? This was amazing. People chipped in things to make words, right? Then they created pens and pencils. And then there was this huge step forward, but they put it on the web, and they called it a PDF. That's still akin to chipping with a piece of stone. So, we, and a bunch of other firms, have taken that step of saying everything that you write or every box you fill out is a data point. And you can normalize all those data points, you have something to work with them. And you have some data to work with now.

So, the interesting thing is what we do now isn't necessarily just filling out a form. It's using some predictive analysis of what's going to be on the form. It's predictive analysis of what forms you need. If you check this box, and it's conditional logic, and it's the simplest of everything you can imagine. But when you start filling out a piece of paper and another piece of paper magically appears behind your other physical piece of paper, that's magic. Online is just called a business process. So, things that we take for granted that we do are sophisticated these days. Now you take all the data you have, and you can run analysis on things. Like, how many times do I say 'um' in this podcast, how many times do I put a comma where you're not supposed to have one – things like that. So, there's data, and what we talk about is data in between the data. How long did it take you to fill out your form? Is it actually a data point we keep? How many times did you write something, hit save, and then go back and change what you already saved? Now people look at that and say, 'Were you lying? Were you changing your questions based on the answers further down in the form?' You know, there's a lot of things that are happening on forms now that you can never do on a PDF or a piece of paper, but only do in a web environment.

Oleg

Understanding that you have had experience with outsourcing, could you shed light on how your development team is structured? Specifically, how do you navigate the dynamics between in-house talent and outsourced resources to ensure seamless collaboration?

Rick

Right, so my partner Fred taught me a long time ago: when you outsource, you save a lot of money, but you don't save a lot of time. And he explained that to me, and I'm gonna say things that I know sometimes aren't politically correct because I just don't do that. You know, when we outsourced to the traditional, what you would think of as India, you know, those sorts of countries, we thought we started there to fill out reports, to build reports, to build things that we thought were very simple. There's data, we want it in a certain way, and then you send it, right? The problem was, my partner told me – he's significantly more adapted coding than I am – he said, 'I'm gonna teach you a lesson, Rick. You go deal with this report.' One report we were generating, right? It took me almost four months of twice-a-week meetings to get one report near what we would consider completed. And it was things like spacing. It was things like punctuation. Do you want commas in your numbers? That wasn't specified, so you have to go tell them. You have to put a dollar sign. You have to put a comma every three going from the left, you know, all that kind of stuff. And the lesson I was taught was sometimes you have to write the requirements offshore so specifically. It might have been worth your time to just do it yourself.

Because if I got to go into the detail of telling you put commas, and numbers, and things like that, that's problematic, right? So, that's one. Now you get nearshore. Now, nearshore is, you know, English-speaking countries that know what we do, know commas. But the problem we get now is we still get people that don't know how our addresses work. So, we have to spend time working with addresses, and working with phone numbers, that you don't need a country code if you're in the United States – stuff like that. It sounds really trivial, but that's time. That's time and effort you spend on things, and it's buried in code. That will show up two, three, four, five years later when you don't expect it to, and blow something up. And then you got to dig for a day or two to find it, right? So, the nearer you can get to people that are commonalities of language and understanding of just general things you do, the more time you save in having to teach them or audit their work. So for us, all of our coders are English-speaking. They write in what's called Scala, which is the code we write in. We are fortunate enough to grab some of the most top talented people that write in that code, and they're very good at communicating. So, you know, we have things where we do virtual standups cause no one is in the same office anymore. Everybody's outsourced.

Oleg

Yeah, quite changed rules.

Rick

Oh, yeah. The landscape has changed, but at the end of the day, they are talking together, and we do these little mini groups where, you know, we have a guy named Vlad, and Vlad's our CTO now because he has proven himself the ability to be a mentor to other coders. And way it was explained to me when I first started was I can take a smart person and make him a coder; I can't take a dumb coder and make him smart, right? So, the question really becomes do you want to surround yourself with smart people that can help find things and fix problems before you even need to know their problems?

Oleg

You're telling us about your partner. Who is your partner?

Rick

There's two or three of them now. As we've grown, we've brought in more C-suite people. Originally, it was Fred, a guy named Fred.

Oleg

Fred advised you about outsourcing?

Rick

Oh, yeah. Fred advised me about all this stuff. And you know, he's a serial entrepreneur at heart, so he stubbed his toe on all this stuff. He and I have had almost four companies together now. So, the thing is he told me once – we were at a party or something at a client's party – and he said, 'Rick, you know, it's interesting: most coders dream of someone taking what they wrote and selling it to a client.' He goes it's the first time he ever had someone like me that's a sales guy, that's communicative – they can actually go sell something and then go write it. So, the first year or two of our life was me saying, 'Yeah, we can do that,' and Fred's got the notes, after note, after note. He had to go build things, you know. So, the key was the mousetrap was sold before it was written. And you've heard the term vaporware. You know, the process, the problem was super simple. The problem was we want to fill out paperwork, and we want to do it in a streamlined manner. We want to do all these things. It's super simple conceptually. How do you take concepts and put them into code to make it work? That's where the challenge is, right? And here we are, almost 12 years after we started this company. The first couple of years, we only had maybe half a dozen clients. But those half a dozen clients told us exactly what we did right and wrong, and what they wanted, and how to fix things, and as a law changed, what had happened, how we had to fix things. You know, there's a term called MVP. And I know you know what that term is – minimum viable product. It chills my spine when someone says, 'Just get to the minimum viable product.' All minimum viable product means is you think you can now charge a client. And I tell people all the time, 'Go get a client. Give them the product for free. Get your first client for free. They will absolutely tell you how horrible your code is, how bad your process is, how bad your UI/UX is. They will tell you all of these things. That is what most firms pay for. They pay for them to tell them how bad things are, right? Just go get a client. They'll tell you.'

Oleg

Yeah, it's called audit.

Rick

There you go.

Oleg

Or beta testing.

Rick

Right. And the interesting thing is I now have a lot of clients that tell me what I do right and wrong. Some are fans, some are not fans. And the way we've built our company and why we're growing so fast is very simple – I give every client that requests something, right? I say very simply, 'I don't want to make any money on that upgrade unless you don't let me share it with everybody else.' Then I have to make money on that time and margin, right? So, if you were to tell me your shirt needs a collar, right? Super simple. It's a great request. I think everybody should know that, and everybody should have that option. So, when we build something, we turn around, and we basically offer it to every new client and every old client because some of the best processes we have were from one person telling us their problem and how to fix it. And then we back it in to all of our clients, and they go, 'That's amazing. We would love to do that, but I'd like to do it this way or that way.' So at the end of the day, I got QAs, I got testers, I get all these things happening from one guy or girl requesting one upgrade for one little piece of a process. We don't know what your got, we don't know what their challenges are because we're removed. We're a vendor to them. We knew originally, but now the world has moved, and evolved, and changed so much. The simplest of things like, 'Hey, can you integrate with this little piece of software?' is a massive win for us. So, get a client – they'll tell you exactly what you should be doing.

Oleg

In your opinion, what are the main advantages and disadvantages of IT outsourcing? And how do you navigate these factors to maximize the benefits?

Rick

So, if you have something that doesn't require independent thinking, and this is that whole in, you know, onshore, offshore. Most people that are coders offshore, they don't want to make decisions. They just want to pound code, and they want to get to an end result to deliver something. So, if you ask them, 'Hey, there's this kind of process that we're looking for you to build,' that can't be offshored because they don't understand. I think this is the goal that we have to get to because it'll end up being over here, over here, or they won't start at all. So, things that are very, very specific and very easy to understand – here's the goal, here's the steps, here's the end result – that could be offshore because there's an easy-to-follow process and template there. The moment you introduce something that has to have free thinking, and how you build the code, and how you get to the end result, that's when you run into offshore problems and, you know, outsource problems. Anything that you're building that requires nuance or not quite understanding what you're building yet, but you can still start processing it, that should be done by you or someone on your close-knit team because there are tons of communication that has to happen in real time. And you've never seen a coder as angry as when you get all the way through something, you say, 'Eh, it's not quite right. Start over.' They really don't like that. I don't know why. But the whole point of it is if you can touch them along the process and keep some boundaries, but give them enough free thinking, you'll get what you want. It'll be amazing. But unless you can define the boundaries and have them free thinking in the middle of that, that's when you're going to run into some problems. I don't know if that exactly answers your question. It's the best way I can describe it.

Oleg

That one of the probably benefits, and advantages, and disadvantages. Do you have any other?

Rick

Well, I mean, the common thought process has always been offshore is cheaper so you can get more talent to work on things. And my partner always told me you can't get a girl pregnant with nine guys in a month, right? The whole point is it's a process. Coding is a process. You build, you test, you build, you test. You know, everything builds on itself. Just throwing bodies on it and massive amounts of effort don't make code write itself faster, right? That's the problem. So, in our world, we went with the highest coders we can afford with the most talent, not with the most we can afford with the most amount of brain power because the end result was never what we could get. That's the way we do it.

Oleg

So, you went over quality versus quantity?

Rick

We went with quality over quantity.

Oleg

Yeah, that's definitely the right approach, especially in software development. But I would like to talk more about your first concern when a developer should take responsibility and deliver the value, not just code, but to deliver, to understand he delivers from the business perspective. Yeah, I agree that it's pretty common in IT outsourcing, but there are a lot of positive scenarios when it works.

Rick

Oh yeah, there is.

Oleg

And it depends mostly on the person rather than on the factor that it's IT outsourcing. I think it depends...

Rick

You're right. If you have a consultant in the middle that understands what you're doing, and they can communicate to their team effectively, and that's sort of the model of outsource. You – the client, there's someone in the middle of you and a team. If that person can identify your requirement, and communicate it effectively, and manage to it correctly, then yeah, it can work very well. The problem I always run into is that person has 15 clients, or they keep stacking on work. It's not about servicing a client well, it's about how many clients can you get in right to the meat grinder. At least, that's been our experience. So, you know, from our standpoint, you have the disconnect between coders and business processes is massive, right? Our world is: I run the business side, and I run the sales side, and I run the customer support side: my partner runs the IT, and tech, and delivery side. So, when we get a problem in, it's always a business person and a coder have to sit down and figure out what that problem is. There's no independent think of one way or another. A business person dreams up a solution, takes it to the IT person, and says, 'Here, this is what I need you to do.' That is going to run into massive problems because they just stepped across 10 pieces of code, but they are all going to break. That little thing has caused massive ripples.

Oleg

Do you know how we resolve this for our clients? That's right, we bring additional layer, this layer called business analysts. And he transforms the requirements from the business side to developers. So basically, he creates user stories that are clear, and that's his goal to create clearly defined, testable, understandable user stories that developer just implements.

Rick

Yeah, done.

Oleg

That helps a lot, but of course, a developer should understand the high level, and it doesn't need to know all tiny business details. That's the goal of business analysts. But if you bring a business analyst, he can cover many of your developers, especially if he works full-time on your project, he fully dedicates, then, I think, you shouldn't have the issue you described.

Rick

Well, and that is where we've run into the problem of finding that middle person. Because usually, the middle person is from the company, not from us. So, it's not like we put our middle person in that understands our business model. We have to bring in someone from their side. And now there's education of what we do. And you have to almost bring them from original code up to where it is today so they know the evolution of how you got there. Because the first thing I always ask is 'How much of my code do you want to rewrite when I bring you in?' And the answer is, 'Oh, all of it.' No!.

Oleg

Okay. That's the typical answer of all developers, I think.

Rick

Yeah, right. Cause nobody wants to work on somebody else's code because it's a different language. It truly is a language, and it's dialect, right? It's how people write Scala over here, and over here, and over here are very different. So, when we talk about it, our coders are turning in code to the CTO who has to sort of massage it to fit the puzzle right. So, they build the process that works. Well, sometimes the connectivity and how it touches other things wasn't thought through correctly, or maybe not all the way through. So, that's where there's layers of deployment, where we would rather spend our time, than layers of development.

Oleg

In your experience, what criteria do you prioritize when selecting outsourcing partners, and how do you ensure alignment with your project objectives and timelines?

Rick

That's a great question. We have churned through a few people over the years that just couldn't keep up with the pace of which we code. So, we're not writing massive, massive, massive code pieces, you know, total structures every day, right? There's little pieces. What we're doing now is we're putting the flesh on existing skeleton and fixing little things. So, what that means is when a problem shows up, that's a production issue. It's got to be done now, like right now. Drop what you're doing. Fix this. It needs to be done in the next hours. Not days, not months, not next sprint – now. So, when you have those sort of requirements where someone has to get pulled from something to fix, do this, do that. And you got to have the talent to be able to go back to what you were doing, go down the level of the depth of where you were when you stopped, and then keep going, right? This is one of those business challenges you asked me about at the beginning is a coder in our world has to be fast enough and smart enough to disconnect from the process they're in, put on the other hat, go into another set of code – you know, same code, different side – fix an issue, make sure it's tested, make sure it's deployed, come back, and then re-engage where they were. That is a trait it's hard to find in coders. Coders in my world tend to like to go down off a path all the way to the end and not be bothered, deliver everything, and then work on the next task. That's just not how real business works with us, because we are a lean team, and we're growing very fast, and we're hiring and hiring more people. But we're looking for intelligent people that can self-manage and juggle multiple things. It's really what's most important to us.

Oleg

Those guys called developers, not coders.

Rick

Developers. See, that's why I'm on the business side.

Oleg

The guys who take responsibility deliver, not all developers, but coders who code, they don’t do what you expect from them.

Rick

To your point, then we hired developers. We don't hire just coders because we have not been able to figure out how to get them to understand our business model yet. Or maybe we're just not big enough that we have verticals that a coder can sit and not be bothered.

Oleg

Looking forward, do you anticipate an increased reliance on IT outsourcing? How do you envision this trend shaping the future of talent acquisition?

Rick

We're running into a very interesting spot right now in our growth pattern, and that is our ability to interact and connect with other vendors. So, as we get a client, that client believes in the story of we own data, right? So, if you think about it from that side of the world, the first thing you have to understand is who owns the data, who owns what we would call the gold source of data. So, the gold source of data is the last transaction that's most up-to-date, with the most accurate information, the most complete data, right? Someone has to stand up and say, 'We own that.' Everyone gets to connect to that. Sometimes it's us. Sometimes it's not us. And then we have to build processes to go touch, and pull, and push. But where we are today is, you know, a great example is CRMs. There are financial service CRMs. Wealthbox and Redtail are two big ones in our world. We've integrated with both of those firms. Well, both of those firms are also now asking us to go update them, and then send something to eMoney, and then send something over to here, and then send something over to there, and have it all tie back in.

And what you're talking about now isn't just filling out paperwork. It's about managing resources and data across multiple platforms that you don't even touch. So, what ends up happening is we spend a lot more time now with our vendors, building relationships. And for the first four or five years, we knew we did something differently because we would find massive, massive errors in our vendor codes, API codes that were basically inoperable. How are you using this? Because we can't figure out how to use it unless you fix this. Well, then we would fix it, and it would work fine. So, what ends up happening is we know we do it differently, and we know we are a data-centric operator. You know, we're not pushing forms around anymore. We're pushing massive amounts of data around and other things like that. And other vendors just aren't used to people like us. So, that's where we are now is in this world of I'm looking for more talented people that can do integration work that not necessarily means business process, but you got to know how it interacts with us.

Oleg

As we wrap up our conversation, what advice would you give to other companies considering IT outsourcing?

Rick

Well, it would be very simple. It would be where are you in your journey as a company? And then I'll give you the right advice. I think outsourcing and in-housing is a path. It's not a straight line. It's not something you decide on when you start. It's going to be something where it's a very attractive model at the beginning because of the cost until you realize that it is going to cost you a lot more than you think because you got to spend a lot more time there. So, a lot of business people don't understand what the value of their time is when they factor in the cost of that IT coding and developer work. So, there's a disconnect there. I would say spend the money at the beginning to find a partner, a coder, developer, whoever, whatever you want to call that. It's in-house, you pay for, you support, and they know everything about your business model and how it affects the code. Over time, as you take your journey, there will be projects, there will be opportunities, there will be things that show up where you need to do massive amounts of code and deployments in a very quick, rapid manner, then you go out and find help. And that's a project specific, that's a time specific, a growth specific. There is no right answer of you should do it all the time, some of the time. It's depending on your business model and where you are in the journey. And I hate to say it this way, where you are in your cash flow. That's really the most important thing. You got to know when and where to pull those triggers at. I would tell anybody that's starting a business or developing a business, find a mentor that's been through this journey, and they can help you decide when and where to pull those triggers, cause there's lots of people that say they can do things and they can't.

Oleg

Thanks for the advice, Rick, and thanks for joining me today. It was a pleasure for me to speak with such an experienced executive as you. I'm sure our guests will find some information useful. I wish you all the best in your journey. If you enjoy our discussion and want to stay updated on future episodes, don't forget to subscribe and hit the notification bell. That way, you will not miss the latest insights and conversations from Devico Breakfast Bar. See you next week!