#226 Exploring Tech Startups, Data Security, and Healthcare Technology with Jeff Rick

0:00:01 - Mehmet
Hello, I will come back to a new episode of the CTO show with Mehmet Today. I'm very pleased to have with me from Boston Jeff Rick. Jeff, thank you very much for being on the show. The way I like to do it is I keep it to my guests to introduce themselves. So can you please tell us a little bit about you and what you do? 

0:00:19 - Jeff
Yes, sure I am. So I'm Jeff Rick. I'm, as you said, located in Boston, massachusetts. I am a kind of I'm a serial entrepreneur. I typically have the role of chief technology officer and kind of. You know, I've had a varying degrees of experience. 

I started my work life really as a network engineer for a credit card processing company, as I started that very, very young, right before I got into college even and then, you know, transitioned into into actually working as a consultant. We built a commission system for an investment bank, which was kind of interesting and fun for an investment bank called Fleet Bank. This was way back in the late 90s. I'm aging myself a little bit with that, but yeah, so did that and then eventually got on to, you know, graduated from college and became started with a company called the internetcom that did group collaboration software. So it was kind of like a Slack or Google application. 

You know, way back prior to any of that being there. We were probably ahead of our time, but we were at the height of the dot com boom, a advertising supported application that eventually had to go and get people to pay for it and that was a very. We went from 4 million registered users down to. You know, just a couple hundred thousand. But you know, having just a couple hundred thousand people paying you money was was a was a good deal, and we got bought by WebEx communications. 

So I worked for WebEx for a while. My boss there actually is the is now the CEO and co-founder of Zoom, so I worked with him, eric you on for a while and that was fun and interesting. We did get acquired by Cisco along the way, which is a huge company right, and all of a sudden I'm a startup guy at a large company. So that was that was very challenging and an interesting time Ended up starting a startup after that that was really focused around filtering and aggregating social media data. Social media this is 2008 was kind of in its infancy and but but people were really kind of struggling with the amount of data that they were getting from all of their different social media networks. So we built something that aggregated all the data together and then had some machine learning to figure out what, what you would actually be interested in, and so kind of like what they do today on social media, where they're they're just showing you kind of the, the things that are relevant to you. 

We failed miserably at that startup. I'm not trying to say that the technology was great, but the execution of getting investors and and getting and getting clients. We never really got there. So we, we, we self-funded that and after a couple of years we kind of wrapped up the show. Which brings me to my most interesting kind of experience, which is when, when we were finishing up that, that project and that that I often call it the epic failure, that was was that startup we were leveraging. 

I had a connection way back, all the way back 15 years earlier, with a gentleman from Katmandu, nepal. It started an outsourcing company in Katmandu and so we we had leveraged four people there to help us build our you know, epic failure of an application. That was great technically, but so at the end of that he came to me and said hey, you're, you're, you're startup failing. Why don't you come to me and become our chief technology officer? And so this was a bootstrapped company. I was one of the co-founders coming into that company and, you know, initially we were just continuing to do outsource development. We did outsource development mainly in the healthcare space because he had done a lot of US healthcare work in the past. 

So we built, you know, we built care management systems. We built analytics for, for individual clients. We we worked with a lot of data and, you know, basically over that period of time we were bringing on clients, building up our revenue and and actually getting to the point where we could then fund our own applications to be built. So, you know, about a year and a half in, we started development on a analytics platform for the healthcare industry. We were focused on on employers in the US space who were, who were basically paying the medical claims out of their own pocket self-insured employers. And you know, a large self-insured employer for a Fortune 100 company could be spending $4 billion a year in healthcare and so, not surprisingly, they want to know what, where that money's going and if they're getting good quality for their data. Yeah, so we would collect that data and we built out a really, really interesting cloud-based platform within Amazon AWS. So my partner and I, rob, we had started with Amazon AWS back in 2007. So very early on, very early adopters with them. But by the time we got around to the startup in 2011, 2012. We built out a patchy Hadoop distributed processing system within Amazon. We leveraged a technology called Elasticsearch and, through our development team, we iteratively built up this pretty significant platform that took in lots of data from lots of endpoints within the healthcare system and then delivered it to our clients. We had a lot of trials and tribulations along the way. You know, very early on we had we've made some technology decisions, we've used a technology called Apache HBase and we found ourselves developing technology just to make the queries work as opposed to the actual application. So we pulled that out of the tech stack and brought in Elasticsearch, which was you know, which is a document based search engine that allowed us to do analytics on the fly and, you know, basically do filtering and aggregation on the fly using their inverted indexes, and you know that document based search engine service really well over the years. It was all based on a rest. We built a REST API on top of that platform. We built a whole bunch of automation around taking data in. At our peak we were taking in 35,000 files a month from about 800 different entities or, you know, companies within the healthcare system. So we built that up. 

Again, we were 100% self-funded, bootstrapped, never took professional money, so we just continually used our services company to fund the development. Eventually, we did away with the services and moved strictly to just an application development system. But we were very scrappy, you know, did not pay for a lot of things. We built a lot of things, certainly had leverage because we did. We had a strong workforce in Kathmandu. At the height before I left, we had almost 700 employees in Kathmandu doing the work. 

So we continued to grow through 2017, 2018. We actually looked at selling at one point in 2018, decided it wasn't the right time and eventually decided in 2020 to sell the company for a really, really great exit to a company called Cedargate Technologies, and Cedargate was a larger healthcare company and they were really focused. They are really focused on a concept called value-based care, which, in the US, is transitioning our healthcare system from just like you pay for the bandages, you pay for the shot, you pay for the doctor, to just paying for healthcare overall on a monthly basis. And so we adapted the platform to use to do those analytics in addition to the other analytics. It took us about two years to do, but we then opened up huge markets. I don't know if I went way too deep for you, but that's a little bit of you know. 

0:10:48 - Mehmet
No, no, I was enjoying it, jeff. No, amazing, and actually you, you know, explaining it this way, a lot of questions came to my mind, Because you mentioned the ups and downs actually of having a startup. Right. So, from you know, being a C and this is part of being a serial entrepreneur, I think, like because you start many businesses sometimes you have this smooth start, you know everything is on your side and sometimes you have things not on your side. 

0:11:23 - Jeff
I would say so I think, even when it looks like it's smooth and easy yeah, there's always there's always something, always some bumps along the road. For sure, some have way bigger bumps than others, that is for sure. 

0:11:39 - Mehmet
Yeah, but what do you think you know is the? I would say you know something which is underrated that people doesn't put too much attention when they are starting something, but actually it's a skill or attribute that help to succeed. 

0:12:03 - Jeff
Yeah, so I mean certainly flexible. I mean what is it known? I don't know. I mean certainly flexibility is a very important attribute. Almost always you start in one direction and you end up, you know, kind of going back and forth and really, you know, for me, I'm a guy who really enjoys building products that people use and find useful, and so that journey for me is very, very important and along that way you kind of deviate and change paths and a lot of times that's driven by conversations you have and listening to the market, listening to potential clients, users. You know, when I I spend. 

I've spent quite a bit of time talking with other startups and entrepreneurs and often I end up with a question to them like who is your customer and do you have one yet? Because in my, in my model and how I end up building products and how I've done that for years, I always start with you can't build a product. My epic failure back really existed because we built something in a vacuum, without having a customer or someone who had a real pain point that needed to be solved. So we ended up building something that was great, that no one really wanted at the time, right? So so I always when I'm talking with other entrepreneurs, the question is do you have someone that you can identify that can really end up being your partner in building this? Because they're the person who's going to end up, you know, paying you for the application, for the use, and you can work together and have them help you, inform and maybe have fewer of those kind of deviations. 

But oftentimes and you see this all over the place people end up I've got this great idea, you know I'm going to help people figure out about allergies and restaurants or something like that, and it's like well, who's going to pay for that? And the question question comes back to that and that they're not. They're not really clear what the market is. So I think you know that's a roundabout way of saying. You know, listening is probably a very, very key ingredient in startups and listening to the folks, you know, identifying clients and then listening to them and having them really be partners in the development, I think is a big key. 

0:14:46 - Mehmet
Yeah, so to this point, like how, how you can make them partner in development. I know like maybe here you, you you mean you know getting feedbacks trying to check the quality of the product, right, can you elaborate a little bit on that, jeff? 

0:15:03 - Jeff
Yeah, I mean so as an example. When we built our analytics healthcare analytics software package, when we first started selling that product, we didn't have a product. We had an HTML mockup of what we thought the product was going to be. We were selling while we were starting development and we and we went out to our network. We knew folks who might have interest in that product. We'd identified potential clients and we said, hey, come on board, help us out. You can, you can help influence the application development. Here's what we're going to be building, and being very upfront about the fact that you know we don't have it yet. This is what we're building. 

And we got three or four very early clients to come on. They didn't pay us much. I think it's key that they do pay you something, because everyone needs a little bit of skin in that game, or? Or you know that then you're the least of their concerns. But so, from our perspective, you know, we just showcased an idea and with a mockup, and instead of going after investors, which is kind of what most folks end up doing when they start a company we went after clients with basically the same approach of here's our mock-up, here's our POC, and continually just upgrading what we were showing them, but really in a focused approach to looking for clients as opposed to investors, and it's just a different in my mind. It's different than how a lot of the entrepreneurs today approach or at least the ones that get a lot of press approach building products. 

0:16:58 - Mehmet
So you think and this is a debate that I always like to hear different appeal on it. So, between the school of bootstrapping the business, building it slowly yet healthy way, versus get some PR news, getting some series A seed, please whatever you want to call this I want to hear your appeal on that, jeff, because you've been doing this for the past 30 years. 

0:17:30 - Jeff
I've done it both ways. I've been involved and I've been part of startups where we had series A money come in. Money was not really a problem For me and then we had literally no one investing anything and very limited a couple of friends and family chipping in a little bit of money. And I think the two approaches are good in different scenarios, right For me. I don't enjoy the venture backed experience because I like to have control. I like to. 

I think that building quality products takes some patience and I don't think that professional investors necessarily they're not afforded the ability to give you necessarily the time to build that out. I do think there's a time and place for it. You get to a certain level where you just need to scale and you need more capital than you just can get away with. But every time I've gotten into a venture backed startup or company you end up spending an awful lot of time communicating with your investors. You build board decks, you have to get permission for things and for me, the guy who likes to build product, it's a very frustrating experience. I think with the right partner maybe it's possible For me, slow and steady wins the race and I really prefer that, but I certainly have lots of friends and I know a lot of great investors who've done some really amazing things. 

0:19:29 - Mehmet
It's not my cup of tea. Yeah, completely understood. And you know, the majority of the time when I speak to founders who prefer the bootstrap method, it's exactly for the same reason, because they say I don't want to give my neck to someone who doesn't understand the system. What I'm doing On the other side, as you said, it depends sometimes also on the stage you are in or on the kind of disruption that you are doing currently. Maybe you need this money because you are in kind of a deep tech technology or something similar, or you need large marketing. 

Exactly which makes sense. Now, you mentioned something which is interesting also, and this is it can be. Let me divide it into questions to be better. So first, you know about having large people to build the product with you. This is one thing plus. They are in Nepal, in Kathmandu. So how challenging is this? You know, when you start to scale and you scale it remotely like how hard it is and how you can overcome this. Yeah, I mean. 

0:20:51 - Jeff
So we started with about 10 people in Kathmandu, we ended up with just shy of 700. And we ended up having to build. So you know much like a lot of you know. Certainly in India and other countries Turnover is maybe a little higher than you get in some of the other countries. I think the brain drain, if you will, is real where people want to go abroad for further studies, that want to move to more developed countries and regions, and so you're constantly working through that already. 

So we ended up setting up a very, very sophisticated and I had a great partner in the Paul Promote Ride who helped put this system together. But we had relationships with six different universities. We had what we call the trainee program where new engineers could come in for six months. They wouldn't get paid a lot but they'd learn and we would teach them the ways of how we do development, how we do iterative releases, how we iteratively build products, and we would train them up and then if they were good at the end, then they've got to be a full-time employee. And so we built this system and over time really to handle both getting bigger but also staying ahead of 10, 15% turnover. 

That system worked out really well when we sold the company and we had 237 employees and the new company came in and said hey, we want to take this model because it's very cost effective and we want to move all of our development out of India and into Nepal because the economics made sense and we ended up adding 350 engineers in a 12-month period, which is when you only have 237, is a big task. 

So we were doing a lot of hiring, but all of the mechanisms that we put in place, the training programs, all of that really set us up for success in scaling quickly because we laid the foundation early. The other part of that is, from a CTO perspective, beyond the training, one of the things that I learned very early when building that application when you have turnover, when you've got new, we primarily leveraged younger folks coming in. We wanted to build an architect, the system, not just for the customer and their customer experience, but for reducing the amount of time it takes a new engineer to come on and be effective within the platform. So we simplified our code, we simplified our architecture, we made things more modular so that you could live within that one area, and that really enabled us to continue to grow quickly, and so, for me, keeping it simple. Stupid is the whole engineering mantra at some level, and we did that not just from the user interface and the application, but from the backend, product development and architecture. 

And those two things really helped us grow quickly. 

0:24:35 - Mehmet
Yeah, yeah, that's. You know. It's a good insight, and I think I had also another CTO on the show, another country, and you know the same thing came up. It's about putting the processes, I think, and having this systematic way. 

0:24:55 - Jeff
I have a very hard-coded process and, yes, yes, all of that is very key. 

0:25:01 - Mehmet
Now you know sometimes when I hear these terms, jeff, like it's music to my ear because I'm from technical background. So you were mentioning about trying to use this AWS, trying to use that and, you know, trying to scale it up and so on, and you mentioned Elasticsearch and so on. So, from a CTO perspective, right, like when you make the choice between trying to optimize something versus you say you know what, this will not work, let's build something from scratch. So what is this key moment that will push to take such decision. 

0:25:47 - Jeff
Yeah, I mean, it's a hard call, right, and so much of even taking a third party library and pulling it in, and whether that's a paid solution or you know, I'm a big, just open source guy generally, so I'm always. But anytime you go and you adopt an open source project or a commercial product, in some ways you're betting on that solution, because one of two things that's generally going to happen with that solution it's going to take off and become big and be continued to be refined and adopted and built out, or it's going to stagnate and you're going to be stuck with what you've got. So that's for me, that's a huge and I would say, by luck more than anything and maybe a little bit of research, we've been very successful with picking projects that continue to get built out. That being said, we have run into, you know, areas where we just clearly had a square peg and a round hole. The scaling was an issue, right, and so for me, I decided to make the change when we were spending more time trying to solve for this technology than we were actually building features and functions, and the day that happened, I started going out and looking for replacement. 

We were using HBase, which is a very good distributed columnar data store, but it did not do what we needed to do, which is have inverted indexes, allow for text searching and all of that, and we were ending up building like it was a big day when we could sort data by one column and that's basic dial tone functionality. But in HBase that didn't exist. So we had to go build functionality and I'm like, if we're really excited that we can sort data and we're an analytics company, we're in big trouble Because that should have been there long ago. So that was the day where I'm like, okay, I need to go and find something else. Now, luckily, we built the system and the platform, so we abstracted that data store, so we were able to pretty quickly just remove HBase and we brought in Elasticsearch. 

Again, though, I got lucky with Elasticsearch. This was 2011, 2012,. When we made the switch. Elasticsearch was not a big name technology like it is today and we got really lucky on that and it worked out really well. But that switch was a big deal. We put product development on hold for three or four months making the switch. But just for me, if you're spending more time trying to just deal with the technology, then you are building the product. That's kind of my tipping point. 

0:28:52 - Mehmet
I have to agree with you, and from your pure consultancy perspective. So the way I like to approach it is if you're doing something repetitively and you're not reaching the result that you aim to, that means you need to change the process itself. So you try to optimize it, you try to streamline it as much as possible, you get results, but it's not like 5%, 6%, it's not like this wow effect. So, yeah, 100% on that. Now, one of the things you mentioned that you are dealing with at some stage with the healthcare data. So it's the most sensitive data ever. So how do you approach this from a city-operspective when you have to deal with something which is sensitive? 

0:29:51 - Jeff
data. I mean security has to be the first and foremost thing in our mind, and we were no-transcript. We were in a very sensitive situation because we had healthcare data. It was identified, so we knew the person who was having the procedure done, we knew their diagnosis, we knew everything about that individual and we had millions and millions of Americans healthcare data in our warehouse, in our elastic search clusters, and so we took a very layered approach to security and really started with encryption being everywhere. If it's on a disc, it's encrypted. If it's in flight, it's encrypted. We also wanted our code to be secure. So we actually built out a training program for secure coding. We took bits and pieces from others, but having someone else's training for secure coding is never really a great solution, because you end up with things that really don't matter and you also end up with things that, wow, that really matters and it's specific to our area. So we built a very comprehensive secure coding program. So everyone coming in had to go through that. We had security tests that we ran before each release to validate that certain users could only see the data that they should be able to see. There's a checklist we ran through smoke test every single release. We ran through that. 

Obviously, the infrastructure security was paramount as well. So we segmented all of our networks so that the front end web servers were in their own network. If they ever became compromised, you really couldn't get to the middle layer. And if you could get to the middle layer then you had to get to the back end layer, and so a logical security network layout really helped us with that as well. So we minimized our risk. We were also taking raw data in 35,000 files a month. So in that regard and we took those through SFDP, which is secure but could easily get compromised as well. So we whitelisted IP addresses, did not have it open to the world. We also implemented automation so that if a file hit our SFDP server, it was only in that folder for about 15 minutes and then it's out into a more secure area. So all of that segmentation really helped as well. We were SOC2, type 2 compliance, so we had audit, continuous audit of all of our policies and procedures and processes going on all the time, with a SIM and a third party helping us with that, and we were high trust certified as well. So not only were we following our policies and procedures, but they met the high trust standard. 

None of that happened overnight, though. Right, we started with we're going to encrypt the data and we're going to write secure code and then built that up over time. You talk about healthcare data. We had a lot of concerns from clients and data vendors, data suppliers, about giving us that data with a 600 person offshore development team in Kathmandu, and so I spent a lot of my time working through with clients and vendors why that was okay, and we had our engineers not having access to any of the data. 

They were developing the system in a vacuum where they didn't have access to live data. And then we did have operational folks who did have access, but they were a small set, small number of people who had access. The data always resided within the United States, within one of the servers there, and we operated a wholly owned subsidiary, so our 600 plus employees over there were employees of the company. They have this wholly owned subsidiary. We're not going to third parties to bring in resources, and so we could go through all the background checks. We put everyone through US federal background checks as well as the Nepal background checks, and we had very strict controls around employees and who we're bringing on board. 

0:34:43 - Mehmet
Yeah, so these things for the folks who are not familiar. By the way, it's not for the United States, but it's the same everywhere Right, yeah, but it's like, because I think United States, especially when it comes to healthcare. 

It was one of the first countries to regulate this with something called HIPAA, which is the Healthcare Protection Act for a short. So this is important because you don't want this data to fall into the hands of the bad people, because they can use it. So, like, hats off, jeff, for all this, all what you try to do to secure and keep this data, you know the most resilient way. I would say yeah, now, thank you. You know we talked about a lot of things. So what are you seeing? You know, from a CTO perspective, everyone talks about AI. I'm aware of that, but I mean other than AI or maybe something blended with AI. 

What are you seeing major trends happening now as a CTO? 

0:35:55 - Jeff
I mean certainly AI, but I mean, and I think so, artificial intelligence. Machine learning is such a broad term, right, it's like saying I'm in the transportation industry and it's like, yes, but do you do boats or do you do airplanes? You know and for me I think you know one of the one of the real trends that's out there that one of the problems I think that really needs to be solved is making some of this technology approachable for for specific use cases and also making that application not have kind of the false positives that can come away, come out with machine learning. Ai is all about confidence levels. So, if I have 70% confidence that this is a proper output, should we be doing anything with that or not? And I think not AI and ML being very interesting, but well, it's certainly interesting, but the application of it and integrating it into real world use cases. 

I spent years with the healthcare data and we did machine learning work and at the end of the day, we had this saying that machine learning isn't what's for dinner, it's an ingredient, right, and too much of the world right now is focused on it, it being the meal and it's not, it's just another tool in our tool bag. 

I think dealing with large data sets has largely been solved, but doing that in a allowing for end users to manipulate that data at a large scale is still something that is is kind of not really a solve science. There's a lot of folks talking about doing it, but you end up oftentimes if you've got billions and billions of trillions petabytes of data and you wanna change how that data is represented, you don't have great solutions still today, and I think that's another area and everyone talks about machine learning and AI being a solution for that. I haven't seen that yet. I see interesting things being done, but it's always on a small scale and the output is always, if you contrive the data the right way coming in, it looks magical. If you don't, you end up with something that's not quite so magical. 

0:38:53 - Mehmet
Yeah, makes sense, jeff, from all the experience that you have. If someone is listening to us or watching us today and they want to embark on a entrepreneurship journey, you know from all these years of experience what do you advise? Maybe someone who's about to graduate from school, someone who want to leave the nine to five? Yeah, I mean. 

0:39:21 - Jeff
For me, the first thing to do is start talking to your network, the people that you know. You've got an idea, maybe you don't have an idea. Start talking to people, talk about them and listening. At the end of the day, it's way more about listening than actually what you're saying. Get people talking about what they do and how they do it, what the problems are within that. Find some pain points and go solve small pain points. Start small. Don't look for this mega solution. It's okay if there's just one thing that's problematic for someone. Solve that problem to start and find some folks who would be interested in paying you for solving that problem for them and start doing that right. 

A lot of people sit back and say, oh, I want to go do this and they just sit there and hem and haw about it, spend months and months and months, even years, researching their idea. Get just one person who's interested in solving that problem, who has it. Work with them, build it and just iterate on that. You cannot get to the moon in one shot. You've got to build all the component parts and if you do that over a longer period of time five to 10 years you'll be amazed at what you have at the end of that process, but the last thing you want to do is go back into a corner and spend a year and a half building something without having people look at it, bring it into the market and have people use it, because you're going to end up being no matter how good you are, you're going to end up being off-market some level. 

0:41:08 - Mehmet
Right, and this is why I always tell people. And I said I didn't start something myself as a startup, but I can see what's happening around me and the majority of the time the startup that failed because they were trying to solve a problem that doesn't exist, or maybe they were bringing something too early to the market. This is why it didn't work. And to your point, jeff, I think also having this, I would say perseverance to find that one is very key. Maybe it's like kind of funny, but even what I'm doing with the podcast, I said, look, I got to try my luck. If one guy listened to me, I got to continue. 

0:41:55 - Jeff
Why not right yeah? 

0:41:57 - Mehmet
Yeah, for me it was enough to have one I don't know who, because from the analytics I can see how many people are listening, but I don't know who are listening. I said I will watch and then if I see, like okay, people constantly coming by, that means I'm onto something. So I think startup is the same thing. So if you are onto something, people will come back. We'll talk to you. They will ask you can you do this, can you do that? I have this problem. So 100% of this point. Jeff, like really I enjoyed the conversation. Was there anything that you wished I had asked you? 

0:42:35 - Jeff
I think you hit kind of everything. Like I said, I've been spending a lot of time with entrepreneurs and helping them try to figure out how to truly bring products to market, and both from a technical and from a business perspective. And you've hit a lot all the questions that I would have thought you'd hit, oh great. 

0:42:57 - Mehmet
Thank you very much for this feedback, Jeff, and thank you for your time back being on the show with me today, and this is the way where people can find more about you, Jeff. 

0:43:09 - Jeff
Yeah, so I'm actually just starting a new company, because that's what I do and it's called MyTreeServicescom, and MyTree is Buddhist for friendship. So it's all about I started it with two friends two of my great friends and we're out looking for other friends to help out in the market. So we're MyTreeServicescom. We're really in the business of mentoring and helping startups, medium-sized companies who kind of do what we did by leveraging offshore resources, but also really mentoring and helping the startup entrepreneurs through the process and journey for bringing a product to market and learning from our experience, helping them out along the way and providing them the resources to get it done. That's good. Mytreeservicescom yes. 

0:44:11 - Mehmet
That's great, jeff. I would make sure that this will be in the show note and I'm very curious to see how this will grow in the future, also as well, and for the audience. Guys, if you have any question, any feedback about this episode or question to Jeff, pass them to me, and if you are also interested to be guests on the show, don't be shy. Reach out to me directly as well, and then we can do the arrangement. And I apologize for my sound today, guys, but I still wanted to do the shootings today. So thank you very much for listening or watching, and we'll meet again very soon. Thank you very much. Bye-bye. 

Transcribed by https://podium.page