Sean Kapuscinski, I always thought you were hyphen, you are, but Sean's responsible for Sequoia's technology, infrastructure, and cybersecurity, and he's involved in the systems, training, and support that help drive their client and advisor experiences. And I'm not nervous, I just ran from the other end of this place. Yeah, I am nervous. Sean approaches problems and solutions from an operational perspective, having spent much of his Sequoia career managing the client service team. Kapuscinski is part of the technology group at Sequoia, which strives to equip their team with the best digital resources to serve their clients. Please help me in welcoming Sean Kapuscinski to the stage. Thank you. Can you hear me okay? Good. Well, thanks, Dave. I appreciate that. Happy to be invited here and happy to have you join me this afternoon. I am the nervous one, not Dave, so just bear with me. Hopefully, we'll have a good conversation this afternoon. So first, thank you for coming to this session. I know there's a lot of other, we're up against Secure 2.0 session. My friend Tim Kochus is doing a session. I know there's a lot of good content out there. So I appreciate you guys showing up to hear what I have to say from experience. I was looking at the session this morning, as the gentleman was talking about values and such, and he's throwing up all these statistics. And I'm thinking, oh man, I got none of that. I've got experience and I've got a network to talk about, but I don't have numbers and statistics. So this is a much more, you know, they ask what level of session this is. This is foundational. This is maybe even below. This is like introduction. This is just kind of a basic concept that we've learned. I mean, I do have 20 years of experience at the RIA that I'm with. And I did start Hyphen, which is a network of operations professionals who work at RIAs that I think hopefully some of you are members of and maybe some other prospects in the group, which I'll talk about in a minute. So first off, three learning objectives. I believe I shared these prior to actually preparing the material. So I'm hoping they line up with what I gave them ahead of time. So we're going to talk about how firms get lost in adoption in systems. We're going to talk about the hidden costs related to our tech stacks. And then I'm going to talk about the framework that I think helps our firm be aligned for success. So this is why I'm here. Dave knows me from Hyphen, which you can see comes after Sequoia. Sequoia Financial Group is the RIA based in Akron, Ohio that I work for. I started in 2003. There were 10 people there when I started. We have grown through hiring. We have grown through acquisition. We have over 200 employees now. We are in 10 different offices over three different states. Our firm manages right around 15 billion of assets. So you could argue the firm has grown since when I started there. I'm thankful to have been a big part of all of that growth. Not that it was because of me, but certainly I got to be a part of it. So that was a great team to be on. My role has been 15 of those 20 years was in client service. So I was on our operations team really from the start. I've never been an advisor. I can't say I really know what it means to be an advisor. I did work for MassMutual right out of college and kind of realized I didn't want to sell insurance. But Sequoia almost didn't hire me because they said they thought I wanted to be an advisor or I was going to want eventually to be an advisor. And I had this experience and I was in New York and I said, no, trust me. I know that I should have been working for those people. I know what I'm not good at. And I think I'm good at the kind of back office stuff. So thankfully, they gave me a chance 20 years later. I don't think they've maybe figured out what I do. So I'm still around. Anyway, Hyphen started in 2010. I had gone to some different events like this and maybe rubbed shoulders with some folks like you. And we had conversations about technology. We had conversations about HR. We had conversations about marketing. We had conversations about dealing with people, how we deal with our custodians, all kinds of things related to just running the business, that practice management side. And so what I loved about those events were discussions that I could really kind of mingle with people and was starting what I felt like to get a network of some degree. What I didn't like is I would leave and that discussion just ended. It would just stop. And that always kind of frustrated me. I'd get home and I'd be like, I'm kind of pumped because I had a good time, but I'm like a little frustrated. And for a couple of years, I couldn't figure out why. And I realized because it's like that, if this one ends on Saturday, you go back over the weekend, you're kind of feeling good. You get back to work Monday and you're just like, I want more of that. So I had heard of our, one of our principals being in a study group. And I thought, oh, he's in a study group for advisors. I'll just join one of the industry study groups for operations people. Well, guess what? It didn't exist. So I'm sure people have come up to that fork in the road before. And maybe a lot have taken the oh well route and just didn't do anything about it. I said, I'm actually going to call five of those people that I had met at some of these events and see if they want to talk to me on a regular basis. Not that they just talk to me, but let's talk to each other. Let's do the virtual round table. Let's sit at a table, so to speak, and just have a conversation every month. So that was 12 years ago. We've continued that. We've got an online discussion board now. It's a community. People ask about content and I say, I don't really provide content, but I do throw the party. And I think we could, I don't know how many seats are in here, but we could probably come pretty close to seating this room. We've got 280 members in Hyphen today. So it's a good network, a good variety of firms from all across the country, all shapes and sizes. We break up into small groups for those calls. It's not one call with 280 people. We do get vendors involved. They usually present to us, help educate folks. That's one of the benefits of the group. So we'll talk about that a little bit later. Insiders Forum, many of you may know Bob Veras and his conference that he puts on. Bob helped kind of introduce Hyphen to the world, I feel like, in 2013. So 10 years ago, he invited me to speak at the event and then asked that I be involved in planning the operations track. So very similar to how this event has an operations track. He's been doing that for a while. And with Hyphen sessions, as well as the operations track sessions that we offer there, this year, there's going to be seven different operations sessions that people can attend. So if you have not heard of that or haven't looked at that or have not considered it, please do. And then finally, one of Bob's friends, Greg Friedman. Greg is the co-founder of Juncture, if you remember Juncture, which I think is now Advisor Engine. I don't know if it's named any different. But Greg and I met through Bob, through his event. And within a couple of years, we were having these conversations. One thing led to another. And he's like, I got experience in tech and we're acquiring and you've got a lot of tech experience and you guys are acquiring. Nobody's really sharing with the world how to do this. And not that we both knew how to do it perfectly, but we wrote a book together. So kind of a cool experience. I'm thankful to have been a part of that. All right, let's get into it. Building a tech stack. I'm not going to tell you how to build a tech stack. I think to some extent, we all end up doing that, whether we like it or not. Whether we choose to do it or not, you end up having tech, right? Somebody said it at T3 earlier this year, we're all becoming tech companies, right? You're not just a planning firm, you're actually a tech company. And so it's almost the easy part to say you're going to build a tech stack because no firm is without it. But here's a little bit of the counterpoint. Kitsa's FinTech map says, my goodness, do you have a lot of choices to choose from? Right? And so I look at this and I just get incredibly overwhelmed and think, I don't know if this is such a good idea for me to be in charge of picking the tech stack because, wow, there's a lot of choice and that's a lot of pressure. Well, at T3, I had the opportunity of speaking on a panel with Matt Reiner. Many of you may know Matt. If you don't, he worked for an RA or works for an RA and also co-founded a tool called Benjamin, which actually this year they've decided to kind of move on from. But nonetheless, Matt and I sat on a panel and we talked about one of the questions they asked us, if all this competition is good. And you can tell from my reaction, I kind of said, I don't know. I think there's a lot out there. It's hard, it's overwhelming. Well, I followed up with Matt afterwards because he gave his comment and he's kind of on the other side of the coin on this one. You know, and so this was his long quote that he texted me and I said, okay, I'm just going to underline things because I can't remember all this. I'll put it up there. But he said, yeah, I think all that competition is good. It leads to great things in terms of what is offered. These companies kind of work not against each other, but they push each other to get better, right? Which I thought was a good thing. And he also said the different mix of the technologies that your firm might do that's different than mine is what creates our unique client experience. And I thought, yeah, that's a really good point. So I guess I'll give him credit for that part. And he does kind of come around, maybe a middle ground that we both met on, which he said, it can be overwhelming, right? There's a lot out there. What I really appreciate is the if afterwards, where he says, if you don't know what you're going for, if you don't know what you're trying to build, what you're trying to solve for, he says, but if you can identify the specifics, then okay, it narrows the landscape. All right, that's fair. Joel Bruckenstein, who runs the T3 Conference, the Action Magazine that was put out right around that time, which also, I guess I'm plugging Advisor Engine a bunch here, but they're the ones who promote that. They wrote an article in there, interviewed Joel and asked him about the tech stack. And he kind of said, that's the foundation. He called them the Legos, the building blocks of the firm structure, and that they have to work together. And I said, yeah, that's a really important point. I think that's something to add on to that comment that we had heard or that I had heard earlier about us being tech firms, is that this is a foundation. And this is something that you've got to think about how this stuff's all gonna work together. But then I asked myself, I have had a lot of conversations over the 12 years within Hyphen about firms that say, yeah, we don't have great adoption of our tech. And we run into a lot of problems. And those problems actually lead to bad data. So I kind of think, all right, how do we all get there? What creates that bit of a mess? Well, to start out, I'm gonna define these two words about how I'm gonna talk about them today. It's not the traditional buy versus build in terms of are we going to buy something off the shelf or are we gonna build it from scratch? We're not really talking about that. We're more talking about when you buy something, it's that purchase. It's essentially saying, all right, we're gonna use this CRM software and that's the buy part. The build that I'm gonna talk about, it's not that you're building that CRM from scratch. It's that you're going to decide how your firm is gonna use it, okay? You're going to put together maybe some training. You're gonna customize a few fields. If you think about any technology that you've started with, as soon as you move forward, the vendor will usually set up time with you and say, all right, we're gonna walk you through the setup, right? That's the build essentially that we're talking about and how that kind of moves towards whatever training you're gonna do. And hopefully, you wanna get the adoption. That was the whole point of getting that software from the beginning. So a real simple way that firms might approach this is to say, yeah, okay, we do that all the time. We've got the tech stack that we want, that we need. We're gonna buy something. We want a quick build. We don't wanna take too much time. We wanna be real efficient with this. Hopefully, it's effective in getting us the results we want. We also think that's an economical way to do it. So we're just gonna buy it. We're gonna quickly do our build and then we're gonna push it out and let people use it. So what could go wrong? I can't see too well, but what do you guys think? What could go wrong with the quick, real quick, buy, build, use? Anybody with any experience in this, let me know. Limited standardization. Okay, limited standardization. That's great. Adoption. Give me more. All the advisors at the firm adopting it and implementing it. Okay, so lack of? Yeah. Lack of adoption. All right, you had one? Incorporating the users. So advisors may make a decision that's good for them, but it may not be the best solution going to the back office. Okay, so maybe the different purposes of it. Yeah. It's not that easy. It's not that easy. Give me a little bit more. In which way? It's just not how it works. It doesn't work quick, effectively. Yeah. And it's always, it's not always customizable, but your situation isn't always going to adapt. That's the problem of the adoption. Yes. Yeah, you don't always get. If I come back from this conference and say to my assistants, this is what we're going to do, they're either going to shoot me or not come to work because of the adoption. Yeah. And that's enough to lose the cheese. Yeah, it's not that easy. Right. And so he's explaining, basically saying, it doesn't work that way. Right. So I'm probably, I'm simplifying it by saying, ah, firms do this. I think there are some people over the, let's call it the 40 years, that have said, I do think we can find somebody in this hall and we need to fill in the blank in terms of what category, back from the Kitsis FinTech map. And you find them and you go back to the office and somebody gets told, here, go. I'll write the check, you take care of the rest. And we're just going to start using this. It's going to be phenomenal. Right. All these great promises. All right. I agree with that. Things could go wrong. I only just came up with two things that could go wrong. One, your game plan is thin. Right. If you think of like a game book or a playbook, it should be thick. You should have some meat to it. You should have a good plan where you talk about the different people that would be using it maybe in different ways. And understanding that before you roll it out, you got to have a little bit more meat to that. People might start doing things however they want if you don't tell them to use it a certain way. Second thing is, if they're not rolling together, back to the data. What happens to the data? It's not going to be great. Right. You're going to think ahead of time, I want this certain result. I want some report. I want to know what people are doing or I want to see what our investments are, you know, what reports are used. If everyone can build their own report and you run your report at the end and find out that, oh, the most commonly used report for each person is the one that they built for themselves. Now, if that is the purpose of your tool, great, but that's probably not effective, efficient and maybe the best way that you were, wasn't the reason why you were getting into that in the first place. So I argue that our tech ends up having these hidden costs, right? You do your tech build. If you're not thinking about some of these pieces, you end up with these hidden costs inside. So before we get into the framework, which is really simple, so I hope you're not expecting too much. It's extremely simple. I'm going to say that now. My role now is on our technology team. So if you're on the technology team and you're not, let's say you're an ops person. I consider myself an ops person, not a tech guy, but I'm on the technology team. So here's a little secret, I guess. If you're on the tech team, people think you're an IT guy. So they think you can fix things. They think you know things. Maybe there's some good for that because I can just give them an answer and they're like, okay, that's the right answer. We're going to go with that. But computer systems, IT stuff, like I talk to our managed service provider most of the time. I know what we want. I know where we want to go. I don't really know all the lingo, let's say. Nonetheless, so I looked this up about a computer system and a framework regarding computer systems talks about this layered structure of different programs, what can or should be built together and then how they interrelate. Again, kind of confusing to me. I don't know that I fully understand it, but I could break this down a little bit and just pull what I think kind of makes sense to me. All right, layered structure. That's taking on the Kitsis map and pulling the few pieces that we're going to use or the few pieces that we are using. Now, as we make decisions, as we may add to what we have, do we actually think about this question of can or should these things go together so that they can interrelate? We talk about integration a lot. How many people consider that when they're looking at new technology? Hopefully you are, which is great. I appreciate that. I'm going to say that in our firm over my 20 years, we haven't always considered that. Somebody's over here and they're looking in one spot and they're going that direction and they're kind of like, I don't care what anybody else is doing. That's where we're headed. They're not always, the firm isn't always thinking about how these things might interrelate. Well, here's my super secret, top secret framework. It's really simple. You build, you have maintenance to that build and you're probably going to improve things as you go. And I'm going to spend a little bit of time here kind of talking about what this means and what you should consider and where these hidden costs are with this framework. But first, I'm going to give you some examples just in life of how this kind of relates. A lot of people own homes. Let's say you build a home. Whether you build it or you moved into an existing home, everyone's excited. The beginning is great, right? Got this place, have room for what I want room for. And this is your build, so to speak, right? What comes shortly after that with owning a home? Anybody? Something breaks. Two of those, that's a good one. That's definitely high on the list. Actually, you decide you wanted something else. Okay, so that's going to come into play. All right, so here's my main maintenance item. You know, week one goes by and you're like, man, we got weeds already. I can't believe it. Maybe the faucet leaks, even on these new builds. I have a friend that he's involved in a builder and literally all his job is, is he's in charge of the maintenance calls they get for year one of new builds. And they're really busy because things leak and it's crazy stories. I love talking to him. You're going to vacuum, you're going to clean, you're going to change vents, you're going to clean leaves. There are all these maintenance items, right? That's just part of homeownership. That's our maintenance, all right? So we understand that. And then, yeah, you realize, man, we should have bought that. We should have built the house with the sunroom. We want to improve it. We want to change it. Okay, kind of makes sense. Most people drive around, you get a car. Help me out here. What do you end up doing? Garage? Oh, another one, a bigger one. Yeah, it might affect your house. I have an accident. You have an accident? Okay, you got to deal with that. On the maintenance front, this is the stuff that I think of. My son started driving this year or this past year. So our two cars became three cars and, you know, 50% more maintenance items. Brakes and tires and oil changes and mufflers. Things happen. That's just part of owning a car. And then people want to maybe improve or change things. So what do they do? They might tinker with the engine. They might give it a crazy paint job. Add a little spoiler on the back. Maybe take that old classic car and upkeep, you know, totally renovate it. Restore it, I think is probably the better word. Those are the improve items. All right, how about our own bodies? Right, your parents handled the build. This is our part. We're the maintenance. We jump into this, right? And you do things. You maybe eat healthy. Get your eyes checked. You take your vitamins, hopefully. Maybe exercise or at least stretch to make it look like you're going to exercise. Get out, get some fresh air. Move around. Those are our maintenance items, right? And then I would say that the things we do to maybe expand ourselves, whether it's coming to an event, whether it's reading extra books, whether it's just more education or something physical, like this guy running a triathlon. You know, people do things that kind of are somewhat of an improve, self-help category, you could say. All right, so let's pull this back to technology. So our apps. We're all carrying these phones around. And a new app comes out or maybe a couple of these apps come out. It doesn't really matter which one it is, but they all have versions, right? And a lot of times we just set up the settings so that you don't really see those get updated. If you have your sounds on, you might hear it pinging you. If you've got 100 apps, you might have 100 pings every week or every two weeks because what are they doing? They're maintaining those apps. If you ever actually read, this is version 1.1, 1.2, 1.3. What's the most common reason that they updated it? Bug fixes. Phone fixes? Security. Oh, bug fixes. Yeah, I was going to say, yeah, security or bug fixes. To me, that word bug, like they're just, they love saying that, like, oh, we're on 1.72 because again, sorry, more bug fixes. Okay, that's fine. I'm glad they do it. I'm glad I don't have to worry about it. That's a maintenance item, right? And then they're ready for version 2.0. Big change, right? So over time, they're kind of like, we don't even want you to remember version 1.72, so we're going to change the icon and totally just improve this thing like you've never believed it. And then the next week you got 2.1 and 2.2. So okay, it kind of keeps going, but we carry this thing around and it's happening right there. It's part of our lives. All right, so where did this come from? Where did this concept of the framework come from? This book, Speed of Trust, a Covey book, I think our book club at our office actually read this years ago, and it wasn't like it immediately hit me. It was something that I actually came back to over time, and it came back to me because a couple years later I was reading another book that had this little image at the top of a chapter, and it said, stop worrying about technology, start worrying about who trusts you. And I thought, all right, I'm on our tech team now. These sayings all mean something different to me now, being on the tech team, because I'm thinking I have an impact on how our firm uses technology. I never really thought about it in the sense of trust, and so now I started thinking back, I got to pull out that book and see what I highlighted and see what those principles were, and you know, see what they were saying about trust. Well, I mentioned earlier, when you look at new tech, tech always creates these exciting promises about how things are gonna be great, right? How you're gonna get these awesome results because of the tech. Our tech is gonna just revolutionize your firm, right? Okay, maybe the marketing says that, maybe the salespeople say that, but a lot of times, you know who else says that? The person who paid for it. We get really excited and we're like, oh, this is just, I'm quoting myself here. Guys, we're gonna be faster, more efficient, we're gonna save time, we're gonna hire less, win more business. Those are some big promises, right? What happens if we can't produce results? If we don't deliver anything, then it's kind of like these are empty promises. What happens when you make promises and can't deliver? What goes down? Trust. Okay, so I'm piecing stuff together. Like I said, I'm an ops person, no CFP, takes me a couple years to figure these things out. All right, so tech-wise, I don't know if any of you are the tech people or if you're gonna be on the other side of this, but what happens when something tech-wise doesn't work? And maybe I want to point to advisors, like how do people respond? Just humor me. Okay, you get an email, that would be very kind, yes. You get an email or a phone call, okay. Okay, do what they want. What else? Okay, complete abandonment. Pretty much. There's one over here. Okay, good. I was thinking a little bit different. I was thinking more like office space style, like take that thing outside and just beat the tar out of it. Okay, but you guys are probably right. You know, people respond. I wrote down a couple things when I was thinking about this. I'm like, yeah, there's frustration, right? Even anger. That's why I say when you get an email, I mean, it's like, well, what kind of email? You know, what kind of words are in that email? If there's a phone call, maybe it's like, I don't want this in writing, I need you in my office now, or this has to be fixed now. Like, I've gotten angry phone calls like that. There's frustration. I mean, that's real, right? There's emotions that come up, and we're gonna talk a little bit about kind of what leads to that and how this happens. This was mentioned. People blaze their own trail. They just say, hey, what you told me doesn't work, so I'm going over here. I'm gonna figure this out. I know how to do this. They might say nothing and keep quiet, which I think is just as dangerous as some of these other things. They might not say a thing, and that's the scary part is you don't know what they're doing then. You don't know if they're happy with what it is. You don't know if they're completely frustrated and just staying quiet about it. You don't know if they're blazing their own trail or if they've completely abandoned it. This one is kind of like, please, just give me something. And then this was what everyone had said, is that you lose trust. That trust goes down. The process that you, did you build? Did you really build a process? And I'm kind of arguing that if you maybe didn't spend enough time on that up front, your thin playbook loses a lot of trust pretty quickly because it's not playing out too well. So back to speed of trust. Paul Colby was CIO for 10 years at British Airways. This quote comes from that book, and when I went back to the book, when I saw that tech quote about stop worrying about tech and start worrying about who trusts you, this was the quote that I do think kind of changed how I think about my role on the tech team in our firm. So Paul said, my perspective on trying to build trust is that I don't get in the door to talk about the next great thing we're going to do on BritishAirways.com or some other great new development unless I'm delivering 24-7 IT operations. When you've done that, you can then talk to them about more creative ideas. That was kind of like a watershed moment for me when it clicked and I realized, oh, if we're not delivering at our firm on whatever it is that we've built, this tech stack, I'll say just the basic things. If we're not able to deliver on that, that's our 24-7 IT operations. Whatever those basic things are, if we can't do that, our next biggest, greatest thing that we come to a conference and find in that, not that I'm against finding vendors, I want people to find good vendors and connect with them here, but I want us to consider before the next build kind of what we've already committed to. So he was basically acknowledging, everybody wants to build, that is the exciting part. Driving that new car home, spending that first night in your new house, clean bill of health at the doctor, I guess, I don't know about the body one, but the first two, you know that great feeling that you get with the buy. You're really excited. Those are great moments. People just want to keep going with that. All right, on to the next one. Let's keep building. This is great. He's basically saying, hey, before you build again, can you please consider a few things? And these are my words now. Consider, you've got to maintain that existing thing, that existing program, that existing hardware, software, network, whatever it is that you've already built, you've got to maintain that and that there's a cost to that. You need to consider that. You're probably going to improve it too. So he says, well, I'm saying to consider before you do that next build, consider there's a cost to the improvement. So this is the closest thing I have to any type of what you saw in the sessions this morning, but it was my quick way of kind of visualizing if I were going to plan out next year, and let's say I had four things that I thought we were going to do brand new. You know, maybe if your firm was built in the past five years, like you just, you know, somebody left and started a new firm, maybe they would pinpoint a tech stack, right, and just build it from scratch, so to speak, in terms of building it all at once. But most of us, if the firm has been around, you slowly realize, hey, we've been writing letters to clients, we probably should get email at some point, right? So you kind of start with that, and then you slowly get your other programs. All right, fast forward to kind of where your firm is today, you probably have some objectives tech-wise that you want to do, and maybe some are improvements, but I'm just going to say, let's pretend you had four new builds. And even after I turned this in, I thought, ah, maybe I can move this around, because you're not exactly building the whole year long, but okay, this could go from 12 rows deep to eight rows deep. But you're still adding things together, right? So your green items, you build it, you're going to have to maintain that. So I'm just trying to visualize some of the costs, right? There's some time, there's some people, there's some capacity, those are things that you'll have to consider dealing with as time goes on. This is the part that we all kind of see, right? Somebody says, we're going to put something new in place, we're going to build something, and he used the iceberg image this morning, I thought, okay, that's good, that's perfect. You know, what don't we see, or what don't we consider? What's beyond that? Oh yeah, there's a lot more, right? There's something we've got to consider. And if we continue with that over time, what are we building here? What are we actually building here? Well, I kind of want to argue we're building this tech balance sheet, and everybody gets excited about the new asset, all right, we're going to buy, that's our asset, we've got this, and we're going to kind of start to build it, and okay, now we're going to get it out to everybody. And what are we going to get? What's the equity that everyone's looking for? They want the value that that brings, right? They want those results, they want this technology to meet all those promises that we were initially looking for. What is often completely forgotten and not considered? Oh yeah, this is going to cost us something over time. To keep this thing going, to keep the wheels turning, I had a, my year with MassMutual, lived in New York City, but I went to church in New Jersey, and had a friend there, he was a executive of some sort at Mercedes-Benz. And I don't know how he heard these stories, but he's kind of like, we had a customer that, you know, works its way from the dealers up to the executives, and they all laugh about it and move on. Well, he told us this story where they they had somebody that essentially never changed their oil at all, ever, and kind of went as far as they could until the car or the engine blew. And I was shocked, I don't know if this is normal or not, I don't know if every company tests this, but they got, if I remember correctly, he said they got 50,000 miles, but then it just blew up like it was done. There's nothing they could do. And in my mind, I'm thinking, yeah, that's, that's ignoring the maintenance item, right? They chose not to do something to keep it going. I don't think we want to set ourselves up for some kind of explosion like that in our firm, or using tech that for years sounds like a great idea, and then data-wise you're like, so we're not getting any of the value pieces we were hoping to get, we're not getting any of the data we were hoping to get. Why did we do this again? And when did this go wrong? Why did this go wrong? I don't know, let's just, let's go to the next one, let's build again. Yeah, that's exciting, let's do that. So there's this debt that you're kind of accumulating. The people that work on the tech side, that's the technological debt, the people that actually touch this thing day in and day out and keep it going, this operational debt, you know, you're accumulating this. That's what that last chart was, where it kind of showed like, it grows. And I'll say, there are times that our firm, over the 20 years, especially the last five, we've built a ton. We're starting to feel some of the pain of accumulating this need to have people and bodies and capacity that can actually work on this stuff, not so much the build. Everyone's excited about the build and everyone's got time for the build. It's the maintenance and the improvements that really eat into what you're expecting people to do. So it kind of made me think of, like some of the comments I was making earlier, you might have thought of this too. I remember psychology in college, learned about Maslow's hierarchy of needs, and I thought, ah, there's probably got to be something out there on the tech side. Of course there is. So some guy, I don't know if this kid from Stanford came up with this five years ago, but this is the one I grabbed initially. This tech hierarchy of needs, which kind of starts out and basically says, if you can't turn the lights on or you can't turn anything on, you're not gonna be able to work on that computer, you're not gonna be able to use the network that we've got everything connected through, which has all the software that you need to do your job. And it's probably, in my mind, it's kind of a big leap to jump to AI being next, but okay, that's the tech view. Well, I came up with this, my build, maintain, improve hierarchy of needs. So if you think about kind of what we've been saying, this is a little bit, this isn't necessarily the framework, but this is kind of like explaining how you fall back. Paul Kolbe's idea of falling back into those basic things that you've got to do, the 24-7 IT operations is what he wanted to provide. His baseline IT had to work really well before he could get anybody excited about the cool things they were working on. So here you go, at the first critical level, every business, everywhere, needs these things, minus the AI, let's say, but you got to be able to turn the lights on, gonna be able to plug into machines, gonna have a network that it lives on to some extent. Maybe you don't, but that's, that one's debatable. Most of us do. And then you're gonna have software, right, where we spend most of our time. So every business kind of has that base level. That's the one where Maslow said physiological needs are that base level, right? And I kind of always used like the hunger and the bathroom. Like if you're starving, you get hangry if too much time passes. And what else in life matters in those moments other than like I need to eat? Not much. Same thing with going to the restroom, like many of you probably have kids like I do and, you know, child, children with bladders the size of a peanut, just you go on a trip or you go to the store and it's just like, I thought you went at home. Doesn't matter, right? Everything comes back to that. They could be all excited for wherever you're going and yet it all comes back to that basic physiological need. Okay, so the next level. Critical systems for us as RIAs, things like our CRM system, your financial planning software, portfolio management system. Those are the big three in my mind when you go when you go beyond that start talking about investments. I know they're there but I don't spend much time on them myself. Things you do with risk, etc. That's kind of tier two, level two. Then that third level is where you might make some of your improvements. You make changes, you do things that are a little bit unique to your firm. We're gonna set up a workflow and some kind of automation that's automatically going to route things maybe from our CRM system or we're gonna have something automatically go out to clients or there's something on our website that if a prospect puts their name in we're gonna have something come up in our CRM that's gonna notify an advisor to call them. Something like that, right? That's kind of what makes your firm unique. To me that's that third tier and then beyond that is where you could talk about creative solutions where some of us might might be finding time to work on some of these things. This is where you probably do get to the AI type stuff, right? The point is these all kind of fall back on the first level if the first level has issues and I love how Paul said it. He's like you can't go you can't kind of go up unless you're stable on all these levels before and that just made total sense to me. So has anybody spent hours on something tech wise that you didn't plan for? All right, okay, good. Yeah, I'd say we all have. Now who spends the time on that? We're gonna talk about the costs and that's that's one that I would want to point out is that who ends up spending time on that? Jessica answered you've gotten emails, you've gotten phone calls, I've gotten emails, I've gotten phone calls. So probably a lot of you in here relate to that and usually you don't start your day saying all right at 1154 this morning I'm gonna be interrupted for three hours, right? That's that's not in your schedule, that's not in your calendar, but that ends up happening sometimes. So it's not just how we build, right, but it's how we keep everyone on track. I'm thankful I'm on the water side I guess of the hotel and get to see all these boats, which I don't understand. If anybody's from here, come to me afterwards if you know the answer to this. There's like 140 boats out there and I'm looking at 140 boats like these are beautiful days, why aren't these boats out in the water? I don't understand the boat ownership world, but anyway when these boats go out, which I assume at some point they do, especially the sail boats, somebody's got to be manning that sail, right? There's no clue how it works but I know that if they there's a lot of rocks around too. I'm like if I built a marina or whatever this is called, this bay, I wouldn't have these jagged rocks be like the outline. I know it's pretty but I'd have just buoys like styrofoam, something that wouldn't mess up all these boats, but you got to keep the boat where you need it to go, right? If you just put a sailboat out there and point it west and just let it go, who knows where it's gonna go, right? Wherever the wind takes it. That reminds me of the thin playbook. That reminds me of what could go wrong if you don't have a plan. Speaking of planning, we probably all have some sort of planning cycle in our firm. This happens to be Sequoia's. I don't like these because I don't think they always perfectly work but here I am using it because it makes benefits my conversation today. So okay, so we've got this plan with six different pieces of it. You know, you're grabbing data from a new client from a prospect, you analyze it, develop this great plan, you're gonna deliver it back to them, we're gonna help you implement it, and we're gonna keep an eye on it over time. We're gonna monitor. All right, that makes sense. That's good. Well, just like with the Maslow and the tech, I came up with my own little cycle for the build, maintain, improve. Entry point here at the top, so you follow me because I got a lot of circles here. If it were up to me, everything tech-wise we'd consider would go through this perfect process. Maybe not, and you can certainly give me feedback. We'll do questions at the end here, so I'm open to comments of things you'd want to do different. But in my experience, these would be some reasonable ways to approach adding tech to your firm and considering both the maintenance and improve, which you can see come last, but are a big part of the conversation. First, you design what you're going for. So back to Matt Reiner's comment. He said, yeah, there's a lot out there, but if you're actually thinking about narrowing it down to what you're going after, what objectives you're trying to achieve, that is going to help you figure out the subset of what tool you might be looking for. I remember five years ago when our firm was choosing a new CRM system, we had a custodial tech consultant group help us, and this is what they did, which I thought was a phenomenal process. They did not come up to us and say, all right, here's, you know, here's the Kitsis FinTech map. Choose from which one you think is best. They didn't even talk about solutions until we got through this long process of, where do you guys want to be in five years? What's that experience going to be like for your clients? Going through those questions and then working backwards and saying, we were actually thinking initially, before it was a CRM project, it was a client experience project, and we were thinking, we need a digital solution for our smaller clients. And we went, kind of, to them with that. And after this design process of them asking us all these questions, they basically said, all right, we've got our first recommendation. You need a CRM system that can put you in a foundational spot to be able to do all those things you're talking about. And we kind of went, oh, yeah, actually, that makes sense. But we weren't thinking about that, right? We were just kind of like, we want to go in this direction as fast as we can. And they helped kind of auto-correct us there. All right, so once we got into that spot, then they said, now, based on what we know, we can help you evaluate options. And they boiled it down and gave us four options, which I thought was great. All right, when I see the FinTech map, I run away. When I get four options, I still need people to help me decide, but we can make a decision together. We made our decision. We bought. All right, what comes next? Build. The build is huge. Not just the customization of fields or the pieces that we think we're going to use, but that playbook, right, in terms of how we're going to prepare people to use this. So from a training perspective, I like to say, at the time, there were only two of us. So my boss, who's now our CTO, he was the first member of Skoya's tech team, pretty much because this initial project was his. He didn't realize it would change the trajectory of his career. When I said, yeah, I'll help him out, I didn't realize I was going with him to start a new department. But yet, here we are five years later, and there's 15 people. We're in a large firm, 200 people. So a 15-person tech team now, started by the two of us working on this project to move our CRM system. And I calculated at about 25% of the time we spent on our build was specifically for the training and getting our team ready to use what we had built. Because if they don't know how to use this, if they don't do it the way we've set it up, this is way too expensive and we will get nowhere near the ROI that we've calculated based on people doing what we've kind of designed them to do. And we've thankfully kept that up where we spend a lot of time documenting the process and having some way to keep that up over time. So then you do your training, you get people off the ground. The move towards adoption is where it's very important to have something ongoing, right? I'll just click this now so you can see. There's always feedback. You're constantly trying to ask people, how's this going? What could we do different? What do you think of it? What would you change? And you're doing it right at the beginning when you're designing it and saying, here's the direction we think we're going. Does that work for you? And asking, somebody said it earlier, about different people have different roles in the firm and the planning department versus the asset management folks versus the research team versus the tech team versus we have HR and then compliance and then the advisors, right? A CRM system can probably work for all of them but in different ways. And so you're getting feedback throughout this process. Part of the adoption, part of what you want to spend on adoption is a cost. We'll talk about the cost in a minute here. Obviously the last two there that I'm saying are extremely important to plan for are how will you support this? How will you maintain whatever you're building? How will you improve it? Plan ahead of time for improvement to be part of the process. So there's costs to do this well and then there's costs when you don't do it so well. And how am I on time here? All right, I'm gonna go a few more minutes if that's all right. The cost to do this well. There's obviously the investment you put in upfront, the time you're gonna put in upfront and then there's the opportunity cost, right? That you could have gone with something else or could have chosen to do it a different way. There's capacity of the people that are gonna end up working on this. It's probably the stereotype that an advisor comes to an event like this, sees some new tool, goes back and hands it off to the ops person and says, here, we're doing this, I'm paying for it, go, make it happen. But the ops people often become the de facto tech people if you don't have them and maybe that's part of the role, that's okay. That's not necessarily a bad thing. The advisor, maybe a support person, somebody in another department, they often get involved. If we have new financial planning software, well, we have a financial planning team, there's going to be somebody from that team, if not multiple people who are highly involved in that. That is a capacity cost that we wanna consider upfront and then admin people, they often get pulled into the tech stuff. They're probably kind of good at it. People envision them always having free capacity like they're not doing anything, which is not true but this is a cost of who's gonna do the work. Then your training. I talked about our investment upfront for the initial training. Ongoing, our firm ended up shortly after we went live with our new CRM system. At the time I was doing it, we have a different role today that does it but I started monthly trainings with our whole team. And so we offer three days, a 45 minute session and we recorded the last one so that anybody who misses it but we highly encourage people to come to these live so that they can interact because we're gonna go over things that they should know. There's a lot of remember to do this and you can imagine with a firm our size, things happen throughout the month and we try to remind people of don't forget. We know we have a lot that our systems can do and it's probably hard to remember everything, especially if you're newer or if you're newer to systems like the ones we've built. So we have this monthly training that we expect everybody to attend. And the last thing from a training standpoint, we actually hired a role, a new role for our firm called a digital skills specialist. And I don't know many firms that are doing this. I do think it will catch on and more firms will be interested in a role like this but his role is 100% dedicated to training on an ongoing basis, one-on-one with everybody in the firm. Now he does those group trainings but his role was specific to us getting the most out of our investment in all our technology. If you consider somebody having a full-time role dedicated to the documentation, especially when there are changes, right? That's kind of a maintenance piece. If we improve something or maybe we change our financial planning process, any of those things, he's gotta then meet with all these advisors and all these team members and make sure that they know what happened and that they heard what he said in the monthly training but he might need to spend 30 to 60 minutes on a regular basis with everybody on the team. That is a cost to doing this well. And then regulation. We're all gonna kind of play within the rules. I threw the last two on here from a cybersecurity standpoint because that's been more my world lately. So I get the cybersecurity and infrastructure security agency notices from the government. I get emails from them and then I think Steve Rider mentioned in his session about NIST which is the National Institute of Standards and Technology. Also a great resource from the cyber world. So these are all things that we need to consider when you do this well. I'll be faster on this slide. The cost of not doing it well, you're gonna end up doing the next best thing. You're gonna move on. You're gonna try to look for that next build probably faster than you want. So arguably that could cost you more dollar wise. You're looking for a replacement. You have a strategy of hope. Hope this one works. Hope the next one's better. We talked about the frustration. People end up using workarounds, blazing their own trail, maybe not saying anything. End up trying to use the tool you give them. Let's say it's a knife. They try to use it as a spoon. And then even worse, months go by and the person never said anything. You found out not only were they trying to use it as a spoon but they were trying to use it as a shovel. They're trying to just do crazy things with the tool that you're like, oh my goodness. You know, you stop them as soon as you can. Take away their computer. They're just causing problems. When you have those problems, issues arise. How you communicate within your firm goes back to that trust issue. You know, how you communicate the problems that come up. If you don't communicate, guess what? That communicates something. If you don't communicate, you're basically saying you're leaving it up to them to decide. You're letting them figure out, do they not know this is going on? Do they know it but they wanna hide it? Do they know it and they don't know what to do? Communicate proactively as you're maintaining things, as those blips on the radar come up. Problems also create capacity issues. So if you don't do this well, if you're not planning for that three hour interruption, you're gonna have capacity issues. Who knows how to do it? Does anybody actually know? Is anybody kind of prepared for that? We have what we call app owners. So there are certain software tools that on our tech team, one of us is the app owner. Which means anything that gets escalated past our initial guy that's taken in all of the requests from like users throughout the day, they might have to escalate something to the app owner. And that person's responsible for making a decision or telling them go to the actual vendor. You know, that helps with the know-how. And training is on the cost of doing this well, but it's also on the cost of not doing it well. Because you probably need more if you got that thin playbook, you didn't do much up front. You probably didn't do it well enough before, so you're gonna have to build it after. I'm gonna leave you with five tech strategy tips. These are kind of my ways of not just building your tech stack, but keeping an eye on how you're gonna maintain it, how you're gonna improve it. The first, hopefully it's been obvious, you're gonna spend time on this. So you wanna plan for this. I talked about like when systems go down, sometimes I call them blips on the radar because something goes down and 10 minutes later we're on all these cloud-based systems and they kind of pop back up. I don't know why. I mentioned earlier, I'm not truly the backend tech person that everyone expects me to be. If it's back up and running, we're not big into chasing down rabbit trails to figure out why. So sometimes we say, can you reproduce it? If you can, then put in your case and we'll explore it. But if you mentioned, hey, yesterday for eight seconds this thing didn't work, can you go figure it out? We're probably gonna ask for a little support of that. Those things do happen though. So sometimes it is reproducible, you don't know why. Keep that in mind in terms of planning for this to happen. Second, have that feedback mechanism. People have these ideas all the time, right? Maybe of the improvement items or maybe a way that you can change the way you're currently doing something. It could be an email that everybody knows I can send something to support at your domain. Maybe it's a meeting. You have a training like we do and they can bring it up there. Maybe it's in your system. Maybe your CRM system allows for some kind of suggestion box. Have a way for people to give that feedback. I came across this image before that I'm gonna show next and it made me think of this concept. When somebody has this idea, right? And they're like, you know, I've got this fireball of an idea. I think this is just gonna change how we do stuff. I've been thinking about this a lot. And they come to you and you're like, I'm busy. Leave me alone. I don't have time for this, right? The person that's stressed, maybe it's that admin that has 100 things and you think they're not that busy or it's that app owner and they're totally occupied with stuff and they just, we didn't plan for this. And when it comes up, even somebody's idea, you don't wanna squash that. You wanna give them a mechanism to use. Third, stay focused. This is about people's roles. I want advisors to be out with clients and preparing for meetings and running their reports and not really worrying about the tier one and tier two items. You know, I want them to do what they do best. I want them to be focused in a way that tech doesn't mess that up. I want it to help them. I want them to trust us. So I want everyone to think about what roles are gonna handle your maintenance items and your improvement items over time. Fourth one, you wanna avoid, I think this was mentioned earlier today, maybe it was in the cyber section, that they were talking about blocking people from getting to things that you don't want them to touch. So if you think about like a locked door or a locked cabinet, you know, it's to keep people out. That's a good way to actually keep people from trying to maybe build on their own or improve on their own. We get questions all the time actually from people that say, hey, I figured out that this tool can do this extra thing. Can we do that or can you teach us how to do that? And we actually say, we don't support that. Yes, it's possible. Pretty much every system or some of the major CRM and planning, you could go a ton of different routes and choose not to use all 180 things that it can do. You might say, we're using this list of 10 and we need you to focus on the 10. That's kind of a guardrail. Things could get out of control, right? If you say, oh yeah, we got a process. What does that process look like? If it looks like a bunch of wires, different colors, you know, Tim likes blue and Sally likes red and I like black and somebody else likes orange. Yeah, we have a process. If it looks like this, then I'd say you don't really have a process. Last one, choose to make your systems better. I believe that thinking of not just your build but considering what it costs you to maintain it and what it costs you to improve it is something that you have control. If you don't think about it, it will just kind of happen to you versus you saying, I have a plan of how we're going to build this next technology and we have a plan for how we're gonna support that over time. The improvements can be part of that process and not just something you maybe run into later. So that's the end of my prepared material. I would love to chat if anybody has questions or other items to discuss. Yeah. You're on the other side of that point as a vendor. What strategies have you seen work really well to make sure that you get the implementation and the adoption and the consistency across the entire advisory practice to set it up for success? So the question was, if I were on the other side, on the vendor side, how would I kind of help set something up, set this up for success of whatever our firm was offering to clients? First thing that comes to mind is I don't know because I'm not on the vendor side. What I will say is that I really liked what that consulting firm did with us or what the consulting group or the custodian did for us as it related to making sure our firm knew what the objectives were and then them clearly showing us that we're helping solve for those objectives. Once it's out of their hands and it's in ours, maybe the only thing I would say is, if you were a vendor, share what we talked about today and essentially encourage them to consider those things as they go. If they say, yep, this is great, we're gonna have, Sean spend 4% of his time building this and then half of percent of his time, the next 10 years supporting it, that's when hopefully the vendor says something like, hey, who's gonna support this incredibly complex system that you're building? That might be the only thing I can think of is if they're aware of this to say, hey, there's gonna be time that somebody's gonna have to spend. I think that might help firms prepare for that cost that's probably gonna come later. Anybody else? Yeah. How do you think about your decision to use tools that are built specifically for our industry versus other ones that are much broader when they have other capabilities and just don't connect to the things that we need specific to our industry as well? Yeah, so the question was industry-specific tools versus non-industry-specific tools, right? That'd be kind of the summary of that. And I would say, interestingly, both questions kind of start with the same answer as it relates to not the I don't know part, but the design part, right? If you are clearly laying out, here's the objectives we want, and whether it's somebody in your firm or whether it's a vendor, sometimes those custodian consultants, I think on one hand, they're great because usually they're free. So use them if you're not. But even if you have another consultant of some sort that you're using, if you have a managed service provider that might be able to help with this, some type of, I'll say a greater than me tech source that can help us think outside the box. Because if all you're looking at is that Kitsis FinTech map, and you've decided we need a tool that does X, Y, and Z, and nothing really fits that, you need some broader knowledge. So I'd say I'm very open to that. You know, there are, you could pick categories, document management, for example, and say that there are probably some solutions that are industry specific, a little more so than not. But there are also plenty of options that are not industry specific at all, right? And that's an area where, depending on how you want to use it, what you want to do with it, could determine, should we go outside the box a little bit and use something that's not traditional? That's the type of interaction and conversation that within Hyphen, we love putting that kind of stuff on our discussion board. Hey, what do you use for this category? And then start asking people if they like it or not. We actually share data on our members, which we get through them filling out a survey, and it kind of lists all the software they use. So when our firm was looking at different CRM systems, those suggestions we got from the consultant, I went straight to our member data and sorted it to find the firms that were multi-custodial, multi-office, multi-billion of assets, basically like size initially, and then used the softwares that we were considering. And so I was able to reach out to a bunch of other firms and kind of have the conversation and say, how did you end up there? What did you come from? What were the pitfalls? What should we look out for? You know, what do you think? And that's where sometimes just through peer networks, you get good ideas of doing something outside of the box. Yeah? Sort of similar to that question, when you're evaluating softwares at the top of your hierarchy of needs and creative solution category, usually they're less established companies, maybe startups or ones that don't have big market share or aren't on the Kitsys map. How do you evaluate risk of some of those solutions just back to the need, I guess, and the system that you've found? Yeah, so how do you evaluate the risk? Did you say the risk or the need? I guess both. Both? Yeah, kind of the risk of doing something different being the first to adopt a solution. Yeah, so with a tech startup or somebody that's newer to the industry. Our chief tech officer actually spends a lot of his time right now seeking out solutions, so maybe partially to answer your question as well, seeking out solutions for the needs that our firm has. He stays connected, he attends events. Some of the custodial relationships we have, the folks there know that we have an appetite for new tech. Our firm, I'd say, evaluates it by doing a few things. We go deep with them as it relates to almost like a vendor due diligence process, right? Show us, prove it to us, let us play in it. We also take a lot of stock in talking to other people that use it, so if they say, you know, we usually don't wanna be bleeding edge, but we're fine being first adopters, and so we actually want to talk to some of those bleeding edge users that can then tell us. So I think it's kind of up to each firm. Like, again, larger firm, lot of specialized roles at Sequoia, so we have the luxury, we know, of having somebody that can spend his time doing that. If you're at the other end of that, and you're like Sequoia when I started with 10 people, you're wearing 30 hats, there's no way we're considering something brand new that nobody knows about because you just don't have time to explore all those things that I just mentioned that would be valuable in helping you decide, like, yeah, I think this would be worth it. We also ask for deep discounts, because if we end up saying, yeah, it all looks good, but we just don't wanna commit to your sticker price, usually they'll really work with you, because if they see, especially we're a larger firm, they see the value that we could be in being with us for a long time in the future, and the impact we might have if we share their name and be involved in spreading good word about them. I'd say always pressure your vendors in a good way, but basically make sure it's worth it for your firm. Yeah. Kind of similar vein to the Cat5 slide image that you had. Yeah. A lot of times when firms may be considering a new addition to their tech stack, you have a lot of different buying influences, right? A lot of different buying influences. Buying influences, okay. So the advisors may have a set of needs or demands that they're looking for in a solution. The back office may not even be considering some of those solutions, and instead have something that's specialized to what they do. What suggestions do you have on, or maybe frameworks in organizing what I guess would fall in like the design, evaluate phase of your framework and identifying what all everyone needs and getting them to, again, like we're all in the same direction. Yeah. Yeah, so maybe two things. One, you've heard before about a champion or an executive sponsor. Our CTO is that for our firm. So having somebody in that role goes a long way, right? Now, the second thing is, another thing our firm does is we have a tech steering committee. And our steering committee meets on a monthly basis. Most of the time, we're dealing probably with requests that people might have for new things on existing stuff. So they're more kind of maintenance or improve items. But every once in a while, something will come up, somebody has this idea, it's that fireball, right? That's the appropriate time for it. That's our mechanism for actually discussing it. So having a committee of some sort, again, if your firm's 10 people and this is three, that's okay. But not putting it all on that one person. You want that champion, but they need to have other people with them. And we have representation from all parts of the firm. So we've got an asset management department, we've got people in research, we've got our advisors, we've got marketing, we've got HR, we've got compliance, we've got tech. Whoever brings that idea is, first of all, kind of getting the blessing of a CTO to say, yeah, I think this is something we should consider, but let's consider the big picture. That's the way we do it, is that we bring that group together. So we happen to have probably 10 or 12 people that are on that committee. And they all kind of share their points of view, saying, here's why that won't work, or here's what we think you need to consider. And then that champion, again, if we move forward, has that information, right? Has that value to say to the vendor, maybe it brings up a bunch of new questions. And that way, it is more of kind of an informed decision, which goes back to the question about risk. You always want to do what you can to lower that. So you don't want to find out, if you're quickly buying and building and using, you don't want to find out later, oh, this only works for these people. Like we, our firm acquires. And so as we've acquired, a big change in just the thought process with some of the firms that we've added, or some of the groups that join us, their firm might have had 10 or 20 or 30 people before. And so sometimes the users might ask for something that makes sense when you're smaller, not when you're 10 times that size. And so that is another consideration, right? Is how does this impact the whole firm? How does this impact all of our clients? Not just the segment that, you know, a particular office might work with. Yeah. All right, dwindled down. Thank you guys. Appreciate your time. Enjoy the rest of the night. Thank you.

Sean Kapuscinski

technology systems

building

maintenance

improvement

existing systems

new technology

integration

interrelation

technology solutions