John Bellone - Future of Personal Data Privacy in Healthcare & Creating a Positive Company Culture

(Adam at 00:00:01) Hello, my friends. You've probably heard my voice on the episode intros by now, and soon you'll be hearing a lot more of me. My name's Adam, and I'm the executive producer of the podcast. And I'm going to be hosting a lot of the episodes coming up along with some other very special guest hosts for the Modern CTO Summer Takeover. Today, we're talking to John, the CTO of SS&C Health, and we discuss how SS&C Health is enabling pharmacies to better serve their customers, the future of personal data privacy in healthcare, and creating a company culture where everyone feels comfortable openly sharing their thoughts and ideas.

(Adam at 00:00:40) All of this right here, right now on the Modern CTO podcast. Here we go.

(Intro Narrator at 00:00:46) This is the Modern CTO podcast.

(John at 00:00:57) Hi, Adam.

(Adam at 00:00:58) Hey, John. How's it going?

(John at 00:00:59) Good. How are you?

(Adam at 00:01:00) I'm doing great. Where are you calling in from? I forgot.

(John at 00:01:04) I'm calling in from Northern Virginia.

(Adam at 00:01:06) Cool. We're here in rainy Florida. Bradenton. It's about an hour south of Tampa.

(John at 00:01:15) I was actually there three days ago. For real? I was in Captiva Island.

(Adam at 00:01:20) Very cool. Awesome.

(John at 00:01:22) Yeah. Well, around that area. I don't know how far Bradenton is, but...

(Adam at 00:01:25) I'll say I've heard of the island name, so it's gotta be close. Right?

(John at 00:01:29) Sanibel, Captiva. Yeah.

(Adam at 00:01:30) Oh, okay. By Sanibel. I know where that is. Yeah.

(Adam at 00:01:34) Cool, man. I know we had a prep meeting a while ago.

(John at 00:01:37) A while ago. Yep.

(Adam at 00:01:38) An overview of what to expect, but yeah, this is the podcast. We're just hanging out, talking. Very casual. Is it cool if I just give you a little bit of my background before we get started?

(Adam at 00:01:50) Cool. So I've always been pretty interested in technology, though I don't think it was really in the cards for me to do a career as a developer. I started a competitive programming team back when I was in school and we traveled around the state of Florida doing that. We were terrible, man. We lost every competition.

(Adam at 00:02:10) And I was also somehow president of computer club, but I couldn't really make any of the stuff I tinkered with work, you know. But enough dipping my fingers into it to maintain interest though. But I ended up going to school for marketing and pursuing a career in audio. So about a year ago, there's a podcast production internship here at the Modern CTO podcast. And I took that because it was a really cool confluence of my interests.

(Adam at 00:02:44) And I started with a cohort of about five interns. I ended up being the only intern hired out of that, and so I started full time there. And Joel, the owner of the business, was super receptive to my ideas for improving the podcast and the business, so he promoted me to executive producer. And now I'm running the production team here and pretty much the podcast as a whole. And we're doing this cool Modern CTO Summer Takeover where I'm hosting most of the episodes. We're having some other guest hosts on potentially. And yeah, just as I'm moving into leadership roles in my career, I'm just super excited that I get to talk to awesome leaders like you and have this opportunity to learn.

(John at 00:03:31) Yeah. Should I give you a little bit of my background?

(Adam at 00:03:34) Absolutely. Let's hear it.

(John at 00:03:35) Yeah. So it's interesting that, you know, a lot of people who work in computers, at least there's some intersection with marketing. I went to school for business and computers. And while I was in university, I did a lot of research, but I also ran the university newspaper as editor in chief. So I have, you know, I have that eye for being able to build and maintain media and things like that. And I kind of started, cut my teeth on financial services. I lived out in the New York City area, and then worked out of a few different large financial services companies until I landed here at SS&C. My background's always really been in software architecture, building products, and operating large infrastructure. And, you know, I did that for a long time at Bloomberg LP in various different roles.

(John at 00:04:28) And joining SS&C, got to continue my career and have an awesome opportunity. I've had an awesome opportunity building out the product development team here at SS&C Health for about eighteen months now. It's been pretty awesome.

(Adam at 00:04:41) Very cool. What were you doing at Bloomberg?

(John at 00:04:44) At Bloomberg, I started off in equity derivatives. So kind of building out pricing services for users of the terminal platform. And then got a great opportunity to kind of move down to the Washington, D.C. area to start up a brand new team called Bloomberg Government, a web product focused on basically building government products around the government's legislation and news alerts and things like that for people who are kind of following all that—lobbyists and those kind of businesses. And then that's right around the point where the SRE fad kind of took over. DevOps took over kind of the industry. So I really started the first web operations team at Bloomberg, and that grew into a kind of a career of SRE infrastructure, building automation, and took me to kind of running and managing teams that built reusable infrastructure for all the services and products at Bloomberg to basically run on top of. So think internal private cloud, like at Amazon.

(Adam at 00:05:50) Interesting, man. That's crazy. So you're really on the leading edge of that whole movement pretty much.

(John at 00:05:56) I don't know if I'd call it the leading edge of the movement, but I definitely was involved very early on, and it's really kind of the curiosity, I think, that a lot of software developers have where you get a problem in front of you. And what actually got me the most interested in the DevOps movement was we had a whole bunch of Macintosh, you know, Apple computers that were new in the firm for developers to use. And we didn't have a great way to manage the software or manage the deployment of just the developer tools on that system. And that's the first moment that I was like, alright, well, we can automate this. We can make this a lot easier, and especially since, you know, it was something that drastically affected developer productivity.

(Adam at 00:06:38) That's super cool. Did any of that end up getting spun out?

(John at 00:06:42) Yeah. You know, what's interesting is it got spun out. It made me create a lot of relationships in and outside the company with fellow practitioners. And what really—it really was the jump start of, hey, we actually need this on a scale beyond just making developers more productive, but also making our operations of websites and applications more productive. And that's really internally with—I mean, with a whole bunch of other—as every organization goes through kind of that DevOps transformation around that time, that's how it started. And it starts like that, you know, in pockets of large organizations that all over the sector. And we really then spun it into, okay, we need this. We need this not only, you know, for two or three or four products, but we need this at the scale for the whole company.

(Adam at 00:07:31) That's really interesting. Yeah. I just asked that because given our demographic of people that listen, a lot of the companies that come on the podcast are developer tools. And so many of them—it's such a common story that they came out of an internal tool at a larger organization, and now they're their own thing. So, yeah, that's really cool.

(John at 00:07:55) I think what's, yeah, I think what's interesting about that is it's funny because all of those tools that kind of start internally and grow to a larger ecosystem, they're extremely, extremely useful to just building products and building, you know, great teams. And that was really at the heart of where I started in my career down that path. So, you know, I think most developers that kind of turn to the SRE role, that's really at the heart of their passion. Like, hey, I want to make my life and my cohorts and potentially people on the outside better and more efficient. And what's interesting is, yeah, that really, you know, it's very self-serving. But then it also says, well, you know, the self-serving part of this also means better business and better business outcomes. And that's kind of the natural progression, I think, for a lot of places.

(Adam at 00:08:47) Yeah. So it's huge ripple, butterfly effect, whatever you want to call it.

(John at 00:08:52) Yeah. It's pretty sweet.

(Adam at 00:08:54) So how did you get involved at SS&C? You weren't originally at SS&C Health. Right? You were at the main technology. Right?

(John at 00:09:03) Yeah. So I had an awesome opportunity to kind of join SS&C to lead kind of an internal automation team, a software infrastructure organization. And really, the idea there was an extension of what my career had been at that point for about seven years, making developers internally more successful and more proficient and using better tools. Right? All the things you just had mentioned, I'm sure a lot of the listeners build towards. Right? And what we wanted to do internally is we have a lot of investments in physical infrastructure and tooling and data centers. And it's like, great, we need to leverage this and make this more efficient internally, but also more efficient for our customers. So I came in and was able to, you know, spend a lot of time talking and listening to developers that just like me, you know, prior had frustrations and needed infrastructure, needed things fast, needed alarms, needed to be able to rely on these pieces. And started to slowly introduce things like source version control and managed databases.

(John at 00:10:06) And ultimately, we got to a point where we built an internal private cloud that allows developers to click a button, get a virtual machine, deploy applications, and get things like load balancers and other types of primitives that I think a lot of companies who use the public cloud take for granted because, you know, they get those every day with Amazon, Google, or Microsoft. And we were able to do this internally now on top of our own infrastructure, which was pretty sweet.

(Adam at 00:10:36) That is pretty sweet. So before we get into it, into it, can you give a brief overview of what SS&C Tech does for listeners that might not know?

(John at 00:10:47) Yeah. I mean, SS&C Tech is a large organization that primarily focuses around financial services. Right? We provide financial services to a lot of the organizations in the world that deal with, you know, offering either retirement solutions, tax and hedge funds. And a lot of the companies that are behind those things rely on our software and the ability for us to deliver our data and our services in a timely manner in order to deliver their members and their customers their own experiences.

(John at 00:11:17) And the health portion of the business is in a similar fashion. People rely on us to be able to deliver, you know, prescription and medical information about their day-to-day lives. And, you know, we operate platforms that make sure that when you go to the pharmacy, that you don't pay too much money, that you don't get the wrong types of drugs, that when you go to your doctor that your providers appropriately get paid and that you don't, out of pocket, pay too much money.

(Adam at 00:11:47) That's very cool. So how did you go from SS&C tech to SS&C Health?

(John at 00:11:54) It was a great, it was an interesting kind of transition. I started to, as I said, being a software developer and an architect for most of my career, I started to get involved internally with a whole bunch of different teams and organizations and businesses inside of SS&C. And as I started to dive more and talk to more of the developers and the business leaders, it just kind of naturally happened. I started to help solve problems and help come up with solutions in order to make our business and deliver our products a little bit faster for some customers. And one of the, you know, one of the kind of—I think the awesome things that we were able to do was use the agile methodologies for delivering software and basically go from a product inception directly to an MVP for a particular customer in about eight weeks, which was awesome.

(John at 00:12:45) And one of the cool things about that particular project, it really kind of opened everyone's eyes to, alright, well, listen, we can do some really, really cool and meaningful things for our customers, and it doesn't necessarily need to be on, you know, a quarterly or yearly release cadence.

(Adam at 00:13:00) Yeah. Are you able to share a specific example of what one of those projects was that you were able to roll out so quickly like that?

(John at 00:13:09) Yeah. I mean, that particular project actually dealt with our core pharmacy platform, and it allowed for us to take some metadata from, as you're at the point of sale. So when you're actually going and getting your information right before you sign to get your drugs from the pharmacy, we basically were able to take some of the information and ensure that if a pharmacy or an organization was trying to get fraudulent claims, that it would detect kind of if those claims were fraudulent. And think of things like basic measures of, you know, the number of prescriptions per user, number of prescriptions per pharmacy, if it's a certain type of prescriptions. And the key here was to make sure that you didn't have any particular users that were abusing the system and getting things like opioids.

(John at 00:13:55) And really, it wasn't meant to do anything more than protect people and protect the healthcare plans so that they could outreach to the particular pharmacies and let them know, hey, listen, we think you might have something that's happening here, and you should look into it.

(Adam at 00:14:10) That's super cool. All the stakeholders that come in to help out with huge problems like that. But then there's also the flip side of that problem where there's the people that—I mean, people I know have prescriptions that when they run out, they only have a three-day window that they can fill it in. And that's mainly because of trying to protect against the people that abuse the system and get too many drugs. But yeah, I don't know. That's just a big hard problem.

(Adam at 00:14:40) I think the way—yeah. And no, it is. And I think the way you can look at it like that is that before we had tools like what we built in place, that really your only way to prevent things like that is to have those hard time limits on when individuals could refill their prescriptions. Right?

(Adam at 00:14:57) Oh, so your tools are actually enabling extensions of those time limits.

(John at 00:15:01) Well, yeah. And what I would really say is that having tools that allow for these types of analytics and give the power of that in front of people, the decision makers, that they then can say, hey, listen, rather than have these hard limits on some medications, we can now start to use these tools to say, hey, identify specifically when and where this might be happening. So then you can start to assess, hey, maybe we can now actually pull the restrictions back a little. So the whole intent here is to have tools that give the ability for decision makers and healthcare plans to be able to make those types of decisions that affect members.

(Adam at 00:15:37) That's really cool. So it's like enabling them to treat it more on a case-by-case basis rather than just implementing a blanket solution.

(John at 00:15:46) Yeah. And I think once you start to get data—it's all about data.

(Adam at 00:15:50) Yeah.

(John at 00:15:50) The more data you get, you can now start to see outliers. And when you start to see outliers, instead of having that blanket solution, you can start to pinpoint on outliers and say, "Hey, listen, rather than the blanket solution of stopping a particular prescription, instead we can say, 'Hey, listen, we see an outlier where this is happening. We can go after that outlier, and then we could make a policy decision internally, and then maybe we can ease up a little bit here.'"

(Adam at 00:16:12) Very cool. So is that what most of your customers are, like pharmacies and customer-serving healthcare providers?

(John at 00:16:20) Yeah, very much so. I would say particularly pharmacies, but healthcare plans and medical plans, right? So if you were to look at it from a traditional financial services or even like a SaaS provider, we're really the glue that allows for these plans to be able to offer these platforms and tools on top of that information and those workflows. So on both the pharmacy and the medical side, we hold the data and we make sure that the rules and the configurations that the plans implement based on their policies and decisions for their members are adhered to. And when something goes wrong or when the data might come in incorrectly, we provide data solutions and analytics and tools on top of that as well to be able to identify those.

(Adam at 00:17:04) That's really cool. So what was your role like when you first joined the company? I remember when we first met a while ago, you said you were looking at code that was older than you. What was that like?

(John at 00:17:18) It's going to date myself a little bit. But, you know, one of the things I have to say, since I was really young, about nine years old, I've been writing software. And when you look at code that not only did you not write, but that is really old, it's almost always like this archaeological dig, right? You get in and you start to—I think of like the Jurassic Park scene where you're going through with the brush and slowly taking off the dirt, right?

(Adam at 00:17:46) Yeah, careful not to break anything.

(John at 00:17:49) Exactly. And then, but then once you step back, you're like, "Hey, listen, there are areas here that maybe they're broken. There are areas here that we're currently using." And it's not about the software being old necessarily or the software being not written in a modern programming language, but it's about making the pieces around it all fit together, right? And just like you would with a fossil, you sometimes, when you put the plaster around it and you eventually get it to a place where it's at the museum that you can—you might have to start to make little changes and fix things, and eventually you put it in front of people and they can see it, right? Enjoy it.

The first couple of days I was here, I was looking at software that definitely was aged, let's say, but still looks pretty good. The whole point is, can we take some of the modern practices of software development—continuous integration, automated testing, timeboxing delivery and release schedules—apply it to the existing software, and then take a look at the processes and say, "Hey, let's take components of the software, break it out, and start to make it more efficient." And that's really how I've approached every problem I've ever dealt with in large systems, because you always have to just break it down into smaller pieces and then look at each piece—is each piece as small as it can be—and then say, "Okay, can we fit these together slightly differently?"

(Adam at 00:19:05) Cool. So would you say you've done a lot of modernization since then?

(John at 00:19:09) Yeah, yeah, oh yeah, absolutely. I mean, I think modernization—it's one of those words that's like a buzzword.

(Adam at 00:19:15) Yeah.

(John at 00:19:16) But I think the interesting thing about modernization as a philosophy is that you're always changing, right? You're always making software or systems work better in the current environment they're running in. And that doesn't necessarily mean rewriting the whole software or completely taking a piece of software that's working perfectly fine and just for one reason or another completely changing it. What it does mean is making it look and feel better for the end user and look and feel potentially more efficient or maybe even a completely different user interface for that user. So most of what we do now is building solutions on top of our existing platform, removing pieces, making it more efficient, more modern. And then in an awesome opportunity, building a completely new product or platform that integrates with everything. And that's where you get the new greenfield type of projects.

(Adam at 00:20:09) Very cool. Has there been any challenges modernizing that are, because the company's so large and such a—I feel like monolith is the buzzword—but just a large immovable object, you know, the inertia of being an organization of your size? Has that been a challenge with the modernization?

(John at 00:20:31) It's definitely—I mean, there's always challenges with any type of transformation, right? And in particular, you kind of hit the nail on the head. With any large organization, there's always issues and inertia to move things. And to be fair, people look at things that are performing, that do what they do and do what it says on the box, and say, "Well, why do we need to change something that works?" Well, the answer is really because we want it to be better and to be able to solve problems that we haven't necessarily foreseen yet in the future, or maybe there's a particular solution that it doesn't do great. And in order to do that, we need to shift things and move things.

Is it harder to do some things in a large organization than it would be if it was like a startup? Oh, absolutely. And I think that's because you have to remember, the software that we operate in particular at SS&C Health affects millions of people every day, in particular at some of the times when they're most vulnerable and the most needy, right? They're looking for healthcare. And it doesn't matter if it's drugs or medical or whatever. And I'm sure as anyone who's in the healthcare network understands, that's also some of the most frustrating things to deal with. So you want to be very cautious and careful when you do work on those things because you don't want to create pain for people. And I think that's really the most important thing here. But from an organization perspective, we always hit inertia. But I think technologists and business people, they sit down and we all move towards the common goal of making a better product.

(Adam at 00:22:02) Very cool. So what does the future look like at SS&C Health? What are some cool stuff you're working on now?

(John at 00:22:09) I think one of the coolest things we're working on now, beyond just modernization, is we built a brand new digital platform. And the first release of that happened recently, and we were able to take a new spin on being able to offer a single application that can be maintained and developed by one team but deployed to the web, Android, and iOS platforms without having to make major changes. And the way that this was built in a microservice and modern service-oriented way, we're now able to offer really interesting solutions that can integrate with not only our software that we've built, but also software that our customers leverage themselves internally in their own environments. And the cool thing about that application is it's really the first opportunity that we've had to cross both barriers of pharmacy and medical and have the ability for us to give a single solution that looks clean, is slick, sleek, it's brand new. And again, it shows really that you can build awesome solutions on top of things that are a little bit aged.

(Adam at 00:23:19) Yeah, absolutely. So you're doing some work with mobile then? And I heard iOS and Android in there.

(John at 00:23:25) Yeah. So it's a hybrid mobile application. It's built on Apache Cordova.

(Adam at 00:23:31) What's a hybrid mobile application?

(John at 00:23:33) Yeah. So a hybrid mobile application is an application really where you write the majority of the software logic in JavaScript. And then in the background, when it's actually doing the build, you either build it into a web application, an iOS application using native widgets, or inside of an Android application using native Android widgets. And the application logic itself, rather than having to write it three times, is able to basically write it once. You write a whole bunch of tests between all the platforms. And when you do your continuous integration and automated testing, you're basically launching small little instances of each of those platforms and you're running tests against the devices, right? So that when we, as software developers—ten years ago, we would have to have three teams maintaining all three of those applications. It's a lot of people. Not only that, it also means that features and functionality get released at different periods of time. So with this new approach, we're now able to release the same feature and functionality across all three platforms and maintain it with a single team.

(Adam at 00:24:34) That's really cool. Yeah, I remember five years ago, having an Android phone just meant you didn't get the same updates on apps.

(John at 00:24:43) Yeah, yeah. And, you know, what's interesting is there are still some things that are slightly different on all the platforms. But for the majority of applications, I'm sure everyone uses a social media application or uses their banking application, they pretty much operate the same on the web or any of the other mobile devices. And it's really about, "Okay, identify the features and functionalities you need and take advantage of maybe some of the other really cool bits that only work on one or the other." And for the most part, they all have the same things that our customers need.

(Adam at 00:25:16) Very cool. So when I'm thinking about doing mobile application development, specifically in healthcare, that sounds like it would be really challenging with the personal data involved, like on people's devices and all the regulations specific to healthcare and the challenges presented there. What's it like working through that?

(John at 00:25:36) You know, we're used to it by now, but I think coming from a perspective of maybe not being used to working with that data, you just take care with how you set up your services and your databases. And in some cases, like I had mentioned, you're now accessing customer information that may not even be within your own system. So you have to be sure you use things like transit layer security. You make sure that logins and things like that are appropriately identified per the user. So you use things like SSO, multi-factor authentication, all the things that most people are now starting to become common with.

But the nice thing about a mobile and a web application is that in both of those cases, that data is only kept very briefly on those devices, only while the person that's using it is actually viewing it. And that in of itself means a short-lived time that it can be on the device. And when you close the application, it's not going to pull more information until the next time you log into it. So you get a nice little circular, "Hey, log in, get my data, and then my data is gone." And by definition, it's a lot more secure. But then you take advantage of all the other things that most people are used to inside of their cloud environments where you isolate your systems and services that access it, and you do things like access controls and everything that most people are commonly used to now that they use public cloud environments.

(Adam at 00:27:03) So earlier you were talking about how you were able to build out a private cloud environment at SS&C. What are some of the advantages there of a private cloud environment versus running on a public cloud environment?

(John at 00:27:16) Yeah. I mean, there's definitely a cost advantage. If you're a large organization that either rents or owns their own facilities, right, then you can obviously buy hardware, commodity hardware, a lot cheaper and then get a lot more runway with it, right? So the best thing there is you can build hardware specific to the solution you're trying to solve. And I think for some of the large parts of SS&C that do things where you need things like very fast operations per second for disk, those are things that you can get much more performance out of than you would on a shared environment inside the public cloud because now it's dedicated hardware specifically for your purpose. So we really married the ability for us to have dedicated solutions for each of our businesses as needed with the ability to have self-service tools for our developers to allow them to get at those pieces of hardware fast.

(Adam at 00:28:11) Have you heard of a company called Groq, G-R-O-Q?

(John at 00:28:15) No, I haven't.

(Adam at 00:28:16) They came on the podcast recently. Their CEO, Jonathan Ross. And so they're a spinout from a Google X project.

(John at 00:28:26) Okay.

(Adam at 00:28:26) And they make these chips that are just incredibly efficient specifically for AI processes. And they said their main use case right now is in financial services. And that just made me—when you're talking about being able to dedicate, run your own hardware to those processes—I don't know, I just think you should check them out.

(John at 00:28:48) Yeah, definitely. I mean, in the case, you probably see behind me, I have a little cryptocurrency rig that I built a while ago.

(Adam at 00:28:54) Oh, cool.

(John at 00:28:55) But in the same vein, those are very specific GPUs that were designed for doing high operations. And in this case, in a private cloud environment, you basically have the ability to now go deploy a whole set of those chips and then give access to only certain users that want to use it. And you can do interesting things a lot faster in some cases and mostly a lot cheaper. And yeah, I mean, the industry is going in interesting ways with a lot of companies now. Oxide is one of them where they're starting to offer these all-in-one solutions that are very purpose-built and live inside of a data center. So I think we're at a point where cloud has taken over for a lot of SaaS businesses, but there's still a lot of companies like SS&C that need really fast and flexible compute inside their own facilities.

(Adam at 00:29:46) Yeah. Would you guys have any use for quantum computing at SS&C yet?

(John at 00:29:51) I'm definitely not in the quantum computing sector, but I imagine if there was—there's probably cryptography types of problems that we're researching that definitely could use quantum computing to do those types of factoring and things. But I'm sure there's a use case. I'm probably not aware of it, though.

(Adam at 00:30:12) Yeah. No, it's just—it's crazy because I mean, I've always thought of that as such a futuristic, non-real technology, you know. But you can actually access quantum machines today through—I know Azure has an Azure Quantum arm that they've partnered with a couple companies that have built quantum machines. And you can just access them right in the programming language Q# and run stuff on quantum machines. Yeah, they built out, like, I think Microsoft built out an entire quantum development kit.

(John at 00:30:45) That's awesome.

(Adam at 00:30:46) Yeah. It's so crazy.

(John at 00:30:48) And Q# sounds like it probably fits into the .NET platform. So you have this interesting hybrid development environment, and you have the ability probably — I'm just guessing — to leverage all the tools and everything that comes along with developer productivity around that environment on top of a quantum computer, which is, you know, I think ten years ago, quantum computing, there's this thing, it's just another thing called this cloud that's not gonna be anything important.

(Adam at 00:31:18) Yeah, man. So talking about the future of healthcare, is there market pressure for people to have more access to their personal health data? Because I know that's something that comes up a lot. We were actually just talking to Tim Berners-Lee on the podcast, inventor of the web, because he's building a new platform.

(John at 00:31:38) Tim Berners-Lee, or?

(Adam at 00:31:40) It's called — he's working with a company called Inrupt, and they're building a platform called Solid where it allows you to keep all of your data in what they call a pod. And then you provide people access to your pod when they want it, rather than other outside entities providing you access to your data when you want it. It's a very decentralized approach. I don't know whether or not it's actually utilizing blockchain technology. I haven't gone that deep.

(Adam at 00:32:07) But it's really interesting, and I was just wondering what your thoughts are on utilizing decentralized, possibly blockchain resources for health data.

(John at 00:32:17) Yeah. So, I mean, the health interoperability solutions are actually quite early in their life cycle, right? So there's standards called FHIR, F-H-I-R, that basically define resources, primitives for different types of healthcare data, right?

(John at 00:32:34) And then on top of that, you have the ability to then log in to your provider and say, hey, you know, I want my healthcare information to be accessible to this application or this third-party service. And that gives you the ability to now at least federate some of your information. What's interesting in a blockchain situation, decentralized, it solves the problem of needing to make that information available to a massive amount of people and for it to be in an immutable state, right?

(John at 00:33:02) So that you can rely on the fact that the block hasn't been changed because all the blocks in front of it haven't been changed, right? The you still have the problem, though, of being able to first do it efficiently, look it up, index it, things like that. But I think it would be an interesting solution to be able to say, hey, listen, all of my information is on the blockchain. But you definitely need to have some security around that because, you know, the blockchain's available to every provider and potentially any third-party users. You wanna make sure that that data is at the very least opaque enough or encrypted so that you don't have an opportunity for a bad actor to come in and steal all your information.

(Adam at 00:33:46) Right. So let's talk about data privacy in healthcare, because I think it's a really interesting subject. Because we talk about your health data being private in such a sacred way that no one should be allowed to see it. But I want every doctor to see it if I'm unconscious and they're total strangers, you know. So I think the actual definition we're working off of is we just want people we don't want knowing not to know. You know, like health insurance providers and stuff. But that being said, I don't know.

(Adam at 00:34:20) I feel like the trend that regular data privacy has taken is that, I mean, if you wanna use an iPhone, if you wanna use any social media platform, you agree to give away your data. And those things can be pretty essential to operating. And I don't know if wearables become ubiquitous — and I think there's a lot of potential for them for catching early signs of diseases and whatnot.

(Adam at 00:34:47) And as they become more ubiquitous, do you think there's a threat of them having the same kind of wall in front of it that you have to agree that they get your data to use them?

(John at 00:35:00) Yeah. I definitely see there needs to be some way for the end user to at least control which types of data and which types of metadata that you can ascertain from a dataset can be published elsewhere, right? And I'll use the example of the Apple Watch because most wearables, people are familiar with that, right?

(John at 00:35:22) The Apple Watch now can do things like take your blood oxygen level, take your heart rate. I read the other day that they're working on a blood sugar indicator for a new version of the Apple Watch. And all those things together, I mean, at some point, we're gonna get to a place where you have so many different sensors on this device that if I just take one sample of that information, look at it, I probably don't know anything about you if it's anonymized. But if then I take the sample of the data over a year, I could probably start to figure out, you know, when you exercise, when you maybe have a disease. And in particular, if your heart's doing things, I could probably start — I definitely could ascertain, hey, you're in AFib now. That's actually one of the things the Apple Watch can give you today. So I see these wearables actually doing that because they're doing it now, doing it in the future for much more and much better things. Now I think the question we need to ask ourselves is not only how do we wanna provide the data, but also in the case that you gave earlier, if I'm unconscious, if I'm in a car wreck, if I'm in a situation where I can't make the decision to give you that data, there needs to be the ability for a first responder or a clinician to say, hey, listen, I need this information, but this person can't give it to me. And I don't know who can authorize that. And it's a level of trust that I think that we haven't necessarily seen yet with these devices.

(Adam at 00:36:46) And that's also really challenging because, yes, you want someone to be able to get that data when your life depends on it, but you can't really make a backdoor without making a backdoor for everyone.

(John at 00:37:01) True. And you also want, just like GDPR in the EU, you want the ability for that data to be deleted when they no longer need it, right? So, you know, if I go to the hospital because I have heart palpitations or, you know, I think I might have a heart attack and then it just turns out that, you know, I ate bad chili, I don't necessarily want the hospital to be able to have all that information. So, you know, it's a really silly example, but the point is that I should be able to have control over my data not only at the time that I accept that end user agreement, but the time that I get service and I eventually don't need service anymore.

(Adam at 00:37:43) Yeah. That makes sense. It's just the thing that doesn't make sense to me is the solution.

(John at 00:37:51) It's hard. It's hard. Listen, it's not easy. And I think one of the interesting things about the — as more and more wearables are ubiquitous and more and more companies start to add more sensors or add different applications on top of them, you start to say, okay, well, it's creating not only first-order data from the sensor, but then second and third order from the data that we ascertain on top of it, right? And one of the things I'd point to is actually over the pandemic, over the last eighteen or so months, where Apple and Google worked together to basically take, you know, your Bluetooth signals, do triangulation, and in an anonymous way that says, hey, we know by your phone that you've been next to someone who self-reported as COVID positive, right?

(John at 00:38:35) And now we can do things like anonymously alert you. Hey, you know, three days ago, you were next to this person who's COVID positive. Maybe you should go to the doctor and get a test. So you can do it in a secure, anonymous way, but then you're limited in some cases to what and what you can actually do with that information.

(Adam at 00:38:55) Right. Well, being in the healthcare industry, what was it like for you guys at SS&C Health through COVID? Was it kicked into high gear, or did things slow down like it did for everyone else?

(John at 00:39:08) No, I mean, I think from an operations, workplace operations perspective, like everyone, we immediately went to a place, an environment where we're quarantined and we're working from home. And as you can see, I'm still working from home. But from the perspective of our customers and the end users, you know, there's a whole bunch of things that we needed to do to be able to, from our platform, provide immediate relief and immediate changes to the ability for our customers to start to be in an environment where we don't want them to go outside and leverage their benefits.

(John at 00:39:42) And in the cases of, let's just say, prescription drugs, a lot of things that happened were things that were on a thirty-day refill. We said, hey, no, maybe we actually should give them more ahead of time so that they're not going to the — they're not going into their car, going to the pharmacy, standing in line three times over the next few months because we actually don't know how long the quarantine or the pandemic is gonna go on for. And that's one small example, but I think there's a lot of sectors and organizations that were affected in a similar way.

(Adam at 00:40:11) What was it like in — I mean, I'm sure as an executive at the company, you were in some pretty serious early conversations. I don't know, January 2020, hey, there's this thing in China that might become a huge world problem. What was that like? And then formulating the strategy on how to respond.

(John at 00:40:31) You know, we have a really, really excellent BCP program, business continuity, and this was identified quite early, you know, I would say. And it was something where, like a lot of things, you know, flu or other types of outbreaks, they get flagged, but they weren't necessarily pandemic level. And, you know, we brief all of our teams, not just health, but any team about these particular things around where you have offices and associates. At first, I would say it really didn't get to be where we felt it was gonna be a much different thing until probably the middle — like everyone else, in the middle to the end of February, where we started to get more and more information about onshore infection rates.

(John at 00:41:14) And, yeah, I mean, I'm sure like everyone in the world, we were worried about our families, about our coworkers, and we had to very quickly make business and operations decisions about how we're going to continue operating everything globally, where people, for the most part, aren't gonna be in the office. And we don't really know how long they might not be in the office for. So it was — I bring it back to business continuity because it's extremely important to be prepared for these types of things as an executive or even as a person who's a family member that might need to take care of others. Think about these types of things. Be prepared.

(John at 00:41:54) But actually executing that plan, it's stressful. And it's amazing. And I'm sure everyone has their stories, but it's amazing how quick things came together and how everyone just was able to get it done across the world, which is —

(Adam at 00:42:09) Yeah. Wild. Yeah. So, I mean, today, we're on the back end of it. Are you guys doing anything at SS&C Health to help with the vaccine rollout?

(John at 00:42:20) You know, we have our standard kind of changes to our platform to enable it to be easier for our healthcare providers to do programs that would make it easier for the rollout on both the pharmacy and the medical side. You know, I think some of the things that we're doing that makes it easier is really inwardly focused on our people and our associates and our people and their families, rather. And, you know, we're making it much more flexible for people to work. We're being very cautious even though, you know, in the United States, we're on the tail end. There are other areas in the world that are still suffering, and we're keeping to account, hey, listen, the policies and the procedures and really just the compassion that we've shown as an organization over the last, you know, eighteen months needs to continue. But we need to keep in mind that people also, they're humans, and they wanna be able to go back to normalcy and see each other and be able to work with their coworkers. So we're definitely taking that, you know, in stride like every organization, I'm sure, in the world.

(Adam at 00:43:26) Very cool. Would you like to talk about some leadership stuff?

(John at 00:43:31) Sure. Let's talk.

(Adam at 00:43:32) Cool, man. So what are you learning right now as a leader at your company?

(John at 00:43:38) You know, right now, I'd say as a leader at my company, I'm learning how to be a much better listener, right? And I know that's kind of a canned answer that a lot of people give, but I don't — you know, I've never been in a situation where it hurts more to listen and hear all aspects of a problem. You get, you know, you have to be able to make a decision. You have to get to a point where you can make a decision.

(John at 00:44:05) But I think in a situation I'm thinking of right now, you know, there are problems where you're solving a technical problem. And when you're an engineer, you look at all the data points and you look at, you know, how do APIs work together? How do these frameworks work? Maybe we make a technical decision. But in reality, if you step back as a leader and you say, well, is it a technical problem? Maybe there's a solution that is more practical. Changing how a workflow works or changing if a piece of data or a process happens in — in our case, you know, if we have to print something physically and mail it to someone, right? You know, these are things where, you know, a lot of companies, they don't need to do that. Well, we actually need to make sure that not only do we need to print things and mail them, but we have to make sure that the things that we print are actually legible.

(John at 00:44:51) And these are things where you have to think through as the end user. And as a technology leader, I'm learning every day about listening to people and their problems and being able to turn around and say, well, if I was in their shoes, I understand frustration, but what are some out-of-the-box ways to think about things? And I think it's not just engineering. It's engineering's the easy part.

(Adam at 00:45:16) Yep. People's the hard part.

(John at 00:45:18) People's always the hard part.

(Adam at 00:45:21) So talking about how important it is to listen and hear all sides of the problem, how do you create a culture at your company where people from all sides of the problem are comfortable sharing so that you can get a full, nuanced perspective?

(John at 00:45:36) Yeah. I mean, that's not always easy. And it's not always easy for a lot of different reasons. For smaller companies, it's much more direct. You can say, hey, you know, email the CTO or email the CEO or use, you know, text or Teams or whatever collaboration software you're using. For larger parts of your organization, you need to start to — I think you need to start to be very forceful about saying, hey, take some time away. Think about how you need to, as an organization, be better. And in the cases that, you know, I think a lot about, making sure that people who don't necessarily always have opportunity to be a leader or in a situation where they can take a project or a problem and run with it.

(John at 00:46:26) Put them in front of others that do and let them hear collaboration and give them the opportunity to be in the seat and at least listen. And then slowly start to say, "Hey, listen. Are you interested in trying out or being the point person on this?" And I think being patient and being in a situation where you are given that opportunity allows people to kind of make their own decision if they actually want to step up and be in a situation they weren't normally given the opportunity to do.

(Adam at 00:46:58) Speaking of engineers that are going to take on more management responsibilities, what's one piece of advice you'd give to that individual contributor that's looking to step into a management role?

(John at 00:47:11) Never be the person who is the reason why software doesn't get deployed. And, you know, I've been writing software since I was nine years old. And, you know, of course it's not building applications, but it's in my personal blood. It's in my culture. Like, I love it. I live and breathe it. But when you're a leader of people, you know, and you rely on other people, they need to get the work done. You can't be the reason why they can't do their job. What your job as an engineering leader, a manager, team lead, whatever the word is, is to basically be their advocate and move away all obstacles so that they can be the most efficient at the job they need to do. And at the end of the day, if you are in a situation where you're blessed to be able to write a little bit of software, make sure it's not the thing that's going to break and wake up an SRE or engineer at 3:00 in the morning because they're not going to be happy, and they have a right not to be happy.

(Adam at 00:48:12) Yeah. That makes sense. I know that's like a common question that gets asked of, like, how much code should a CTO be writing?

(John at 00:48:20) Yeah. I don't write enough. I don't write any code now, but I do get the opportunity occasionally to sit down, do code reviews. And I'll carve some time out and say, "Hey, listen. There's this new thing that, you know, protobuf or gRPC in Go that I want to scratch that itch." And I do a little thing and I show people, "Hey, listen. This is what I built." And everyone's like, "Yeah, John. That's cool. But we have to do it." But as a CTO at a large company, I think it's important to get your hands involved in at least some of what your teams are working on, especially when you start to talk about things like developer experience. Because your developers are the people who are building the products along with the business to be able to make your customers a better experience. Right? And if they are not productive or they can't get their job done, then you're doing something wrong. And in order for you to know that, you need to at least have a little bit of hands on keyboard. But, you know, you probably aren't going to get to do it as much as you want.

(Adam at 00:49:25) Yeah. That's the eternal struggle.

(John at 00:49:27) It is.

(Adam at 00:49:28) So how do you keep your developers, like, with a finger on the pulse of—because they're sitting there developing code all day. How do you make sure they still have a finger on the pulse of the customer need?

(John at 00:49:42) Yeah. I mean, that's hard. So one of the things we've been extremely successful at in different newer projects has been involving, in kind of agile fashion, involving our developers directly with our customers. Right? So they sit down and they actually talk to the customers. And to the point earlier about leadership, it's not me. It's not one of my directs talking to the customer. It's the developers and the people writing the code. And they create the relationships. They get to see how customers are using their software. They get to hear the feedback. And not only does it create a better product, but it creates a better, cohesive relationship with our customers. And that's how we built the digital project. It was extremely successful. It's been one of the best products we've built in a long time. And I think by our developers being able to be engaged, now they get an opportunity to have a different scratch, a different aspect of not just writing code. They actually now get to understand requirements gathering, how to test appropriately, some of the problems that they may cause by a small change. And these are things where, you know, you might not necessarily have an appreciation for when you're writing the code, a small change on an application. But if you see a person using it on a regular basis, you'll have a better idea of what might cause a problem.

(Adam at 00:51:02) That makes sense. Yeah. That's super smart. It seems so simple, but I feel like a lot of companies aren't doing that—having their developers interface directly with customers.

(John at 00:51:12) Yeah. I mean, sometimes it's not possible. Right? And not so much that it's not physically possible, but it's maybe not possible because what you're working on isn't easily—a customer can't easily look at it and say, "Hey. Yeah. This affects it one way or the other." But I think there's always opportunities where you can put people in front of, in the seat, and say, "Hey. How do you use this software?" And then in the background, you have someone who's an architect that writes—says, "Hey. This hits this, this, this, and this." And then maybe you don't have the direct interaction of talking to the end user. Like, "Hey. I click on this little button. It sends a gRPC call to Kong, to Kubernetes, to a Postgres database. And then, you know, hey, if the query is cached, maybe it hits memcache." But then the person, the architect, would say, "Hey, listen. This one call here is so slow. Then we need to do a little bit of caching here." And at least then you get an idea of how everything flows through the system. And I think what's interesting now about Zoom, we're using it today, you could do things like recording, and now you can archive them and have people watch them. So it's much more of a—when back in the old days, we used to call it a user experience lab where people would come in and sit down and start to use your product. You have cameras all over them and, almost like a candid camera, see how they use it, see how they get frustrated. Well, now you can kind of record some of that stuff. It's a little bit easier.

(Adam at 00:52:36) Yeah. I was going to say it's like, I was going to mention that working remotely probably made that developer-customer connection much easier just because everyone's so used to it.

(John at 00:52:48) I do think so. And I think not only is everyone used to it, but there used to be a stigma in a lot of sectors about people that didn't necessarily go and be able to sit down with customers not being the point contact to a customer. Right? And I think now, one of the positive things about the pandemic is that, as far as I've been aware, every organization has no problems now with saying, "Hey. You know what? Let's get on a video conference and talk this through." And you see the person, you can interact with them. It's not the same thing as sitting across from them, but it's much better than sending an email or being on the phone and not being able to at least observe.

(Adam at 00:53:26) Yeah. Oh, yeah, man. Miles ahead of email, one touch a day. It's like, "Hey, this doesn't work." And then the next day, "Oh, sorry. Does it work yet?"

(John at 00:53:35) Especially with time zones. Right?

(Adam at 00:53:37) Yeah.

(John at 00:53:37) Yeah. I mean, you know, you might send an email in the morning and then the person that's getting in and then you don't get it back till the next day. At least with video, you can set a specific time, log in, get immediate feedback, and then go and solve the problem.

(Adam at 00:53:48) Absolutely. So I just got a couple more questions for you, John.

(John at 00:53:51) Yeah. Absolutely.

(Adam at 00:53:52) So how do you approach failure within your teams and, like, really try to implement the learning from it?

(John at 00:54:00) Yeah. I think being able to kind of continuously step back and look at failure, successes and failures, is important in building software, building systems and products. Because, you know, a lot of people look at failure and they say, "Oh, you know, you did something wrong, slap your hand, and don't do it again." Well, from an operations culture coming from building infrastructure in my career, I look at failure as, "Oh, that's an interesting problem. I didn't think of that. Like, why did that happen?" And, you know, that's how I even approach some of the problems that we have day to day building products. You know, "Hey. We didn't think of this. Why didn't we think of this?" And eventually, you know, you go down the who, what, where, when, why, and then you keep asking a lot of whys. Like, "Well, why didn't we think of this? What happened here? Maybe when we do a certain sequence of events, this happens." And I think what's interesting is when in my career, when I started getting heavily into DevOps and building virtual machines and getting to understand how when you configure certain things different ways, they behave differently. You start to think more about the, "Oh, wow. Okay. That's a bug. It's a problem. It's a failure, but I can learn something from it." And you can apply the same thing to product development. It's just you got to be a lot more careful because you don't want to spend three months building a feature and then find out, "Oh, we didn't listen to our customer at all." That's a much different problem, and we've had those problems too. And those kind of problems, I think, are solved with, you know, having more of what we talked about, you know, getting your developers in front of customers and listening to feedback.

(Adam at 00:55:38) That makes a lot of sense. It's like a difficult balance to strike.

(John at 00:55:42) It is. It is.

(Adam at 00:55:44) Cool. So what is, like, the one piece of advice that you would give yourself when you're stepping into your first managing people role?

(John at 00:55:54) That's an interesting one. So the first advice, I think I'd give to someone—and I talked about listening, but I also talk about don't be afraid to make a mistake because, you know, everyone makes mistakes. We're human. But one of the things that I think a lot of new leaders are afraid of is not making a decision because they're worried about making the mistake. Back to the failure part of the conversation. You know, you can't be afraid of failure. You can't be afraid of making a mistake. But if you don't make a decision, you're not only not going to get things done, but you're not going to make mistakes or nothing's going to happen. So I think it's much better to listen to all aspects of your team, the product, the business operations. Make a decision. Even if it's the decision that's incorrect, you shouldn't be afraid of it because you're going to learn something from it, and the team and the business are going to grow because of it.

(Intro Narrator at 00:56:53) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you would like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.