Disrupting Technology in Healthcare with Chris Venturini

Transcript

Ledge: Our guest for this episode is Chris Venturini. Chris is a healthcare technologist in the venture technology space with a broad experience in platform development and domain-driven design.

In this wide range interview, we dive into Chris’s perspectives on disruptive healthcare technologies and then dial in on risk communication to domain-driven design in full software development life cycle.

Chris, how do you think about CICD with respect to the software development life cycle and the risks inherent in rapidly launching software?

Chris: Whenever I think about my approach to continuous integration and continuous delivery, it really comes down to software engineering leaders. They tend to always want to have the conversation around “What does faster delivery mean for my team and what do we have to do? I want to give features out to my customers quicker.”

It then usually boils down to “Oh, I have a build server built off of a TeamCity, Jenkins, Bamboo ─ pick your poison.” And they said, “Yes, I’ve got continuous integration and continuous delivery.”

To be honest, in my opinion, I think that’s a bit of a red herring. That really focuses on the end of the life cycle whenever you’re talking about continuous integration and continuous delivery. In my opinion, you really need to start at the beginning and flip the conversation and talk about the approach to the development life cycle starting from the very fundamentals.

It needs to really start with minimizing the risk even before a line of code is written. If we take monolithic apps as an example, one small code change and you have to deploy the entire platform. There’s a lot of surface area with that deployment.

And so, that’s why, typically, people go through these really long lifecycles of being able to spend months of developing and spend months of testing before they even deploy something. It’s because they’re not minimizing that risk.

Usually, it boils down into the next part of the conversation which is microservices. That’s the answer.

What do microservices even mean?

What you really need to do is you need to take a look at the roots of microservices diving into domain-driven design and bounded contexts. What those mean, in other words, is that the components need to be based off of a singular isolated business purpose and being able to say, “Hey, I have a service over here that only focuses on the accounts or this other service over here that actually focuses on the orders.”

Once you isolate those things and one component doesn’t need to know the inner workings of the other component, what you really have then is just some orchestration between those that are basically really quick questions, not lengthy conversations.

So one service is going to reach out to the other service and they’re going to say, “Hey, does the user exist?” And then, it’s going to say, “Yes.”

And then, the other one is going to say, “Hey, do they have the funds?” and the other one is going to say, “Yes, they have the funds.”

Once you actually minimize it that way, you’re going to be able to really isolate those risks. So as the development life cycle continues, then you can isolate those different components and also be able to deploy those very quickly and not have to worry about how much other things are going to be affected by that. It’s really just isolating that.

David: Absolutely! And DDD is huge right now because I think it really delves into the fact that microservices versus monolith and all these D’s are concepts that are really driven by organizational mandates and scale mandates.

It wasn’t built to solve a software problem. It was built to solve an organizational problem. I think that often gets missed. We get lost thinking that that was a software mandate and not an organizational mandate. I don’t know if you see things like that.

Chris: I have. I’ve done some small projects myself with some small startups and it really comes down to “Do you want to spend the time to be able to segregate out that code especially with a two-person team?”

In my opinion, I really don’t think that there’s a difference between building a monolithic app or building two small services. Start looking at the industry and look at some of these really open source quick development platforms like Python with Flask where you can quickly stand up a really quick microservice. Within minutes, you can really isolate that development where it’s easy on a two-person team as long as you focus on “Hey, what’s the right tool for the right job?”

David: Yes. I imagine there’s a move to that direction because we’re not realizing that DevOps is moving so far right into the development cycle.

You can’t be Full Stack without being a DevOps professional as well ─ at least, somewhat. You have to interact with these things. You need to think about containerization and orchestration. It’s not a world where we run under a metal anymore.

Chris: No. I know that you, people, always say that all problems can be solved in software, another layer of abstraction until there are too many abstractions; and then, you’re just insane.

But I think there’s something to be said about that where, really, as long as you can isolate the ease in which you’re able to do deployments and to be able to do the development process, it doesn’t matter if you are a two-person team or a fifty-person team. It’s really being able to be as quick as possible.

One thing I wanted to mention with continuous integration and continuous delivery is that risk is also minimized with the concept of the testing period being able to say, “I have a baseline of unit testing that I know that I’m confident that this component is going to work.”

Taking a step above that, you also have these service tests that I also can confirm that work, and then not have these UI tests that are also going to work.

And that just ups the level of confidence that whenever I deploy, I don’t have to worry about bringing down an entire system because I missed something. I should have continuous integration and continuous delivery really ─ or about quick feedback. I’m going to be able to write software, know that it’s going to work quickly, and then get it out into the user world and see if it actually is a viable solution, and then be able to revert it back if I find that it’s not.

David: You work in venture capital as a technologist. How do these things go together and what are some takeaways from your experience there?

Chris: I work in healthcare venture capitalists. The biggest thing that I tend to focus on especially from a technologist is we tend to ─ especially engineers and technologists and anybody versed in technology ─ gravitate towards shiny toys.

The problem with that is whenever you gravitate towards shiny toys, you tend to start with the technology instead of starting with the problem.

I’m going to use blockchain as an example. As we were talking earlier, everybody thinks that blockchain is going to solve all the problems of the world; and that really isn’t the case.

In twenty-five years or even less than that, probably in five to ten years, blockchain is going to be nothing more than a different stack of technology that people will be building off of. It’s going to be like a conversation we have today with “If you have a web platform, you don’t say ‘Hey, I’m using TCP/IP.’ You just say, ‘I’m building a web platform.’”

That’s really what I think with being able to go with something like blockchain; and all the venture capitalists are diving all over that.

You really have to take a step back and you have to say, “Okay, what is the problem that I’m really trying to solve? Is this going to be disruptive?”

And if it’s not going to be disruptive, walk away from it and then move on to something else.

David: You could probably spend hours talking to people about how blockchain could revolutionize “healthcare.” What are some areas where that’s actually true? What are you looking for out there that, in fact, is disruptive? What’s being missed in that?

You can’t just do the blockchain of X when nobody even wants to pay for X.

Chris: If you look at the blockchain landscape, everybody is always talking about identity or being able to ─ if you have smart contracts, you can start actioning things, absolutely. But it seems like for everybody ─ especially in the healthcare world ─ it’s always about being able to provide identity information.

But the interesting thing that I think about whenever I think about healthcare is that the government is really trying to push this concept of what I would call “data liquidity” or being able to have your information ─ as a patient ─ travel with you throughout the country, if you will.

That’s where I think blockchain can actually play a role because the government is basically saying, “Hey, you help your organizations. You need to start playing nice with each other and you need to start having data go back and forth.”

Well, that’s the perfect world where you don’t want to have a single authority where only one person holds the key to that identity. You can use blockchain there to be able to say that it’s a distributed identity and as long as it’s honored, then the data’s going to flow.

There are things that are going on in the government and the ONC. There’s a draft of a bill called the “TEFCA” or the “Trusted Exchange Framework and Common Agreement.”

They talk about this concept of data liquidity and being able to have this Utopian world of the United States where if I go from UPMC in one world over in Pennsylvania and then I move to California and I’m dealing with Kaizer, I can just have my data flow.

But that’s really where it comes down to. There’s not a central authority there where, then, blockchain makes perfect sense and it can be disruptive because, to be clear, nobody ─

Try to go between providers right now and it’s impossible because your data is not going to flow. That’s unfortunate because the majority of your health decisions that a doctor has to make is based off of the historic context of you as a person and you and your family. And if there are parts missing, then, they can be making potential deadly decisions based off of your health.

So that’s where some interesting things particularly around venture capitalist ─

It’s like, “Alright, if the government is heading this way, how do we force the rest of the industry to kind of move along?”

And that’s also kind of the weird thing about being in healthcare as well. Whenever you think of the government, you don’t think of the most technological savvy people because they’re usually behind the times. But the government is actually telling healthcare to get ahead of the times, and that’s almost oxymoronic, in a way, because that’s not a way that you would typically think that the government is going to push an industry.

You would think they would tell them to slow down instead of try to become faster.

David: On one side of the coin, there’s a mindset that “I must have people who work on my product to be my full-time engineers. I must have captive employees.”

In our area of the economy and the cohort of workers that we work with, we’re finding that people on the talent side are rebelling against that a little. And if they’re in a constrained labor market, there’s access to people that you can’t get as employees because they just simply don’t want to be full-time employees.

As someone who’s on the funding side, how do you think of “Where must I have a full-time employee?” versus “Where can I have a highly dependable freelance engineer?”?

Chris: One of the most important things that I think as an individual in life, in general, is to be able to understand and to be able to say the words “I don’t know.” By saying the words “I don’t know,” you’re acknowledging the fact that you’re not an expert in some field.

So where it comes down to of having full-time employees versus reaching out to the experts, if you will, is you’re acknowledging the fact that you don’t know.

Unfortunately, in the tech industry, people don’t like to say “I don’t know.” They like to say “Well, I’m going to dig in and figure it out myself.”

So it’s a balance between having the domain knowledge of your employees along with saying “I don’t know.”

I am no expert in all blockchain technology. If we decide to start building a blockchain platform, I’m going to reach out and I’m going to say, “Okay, guys. We’ll use an expert in blockchain so, then, I can marry the domain knowledge that I have here with my employees and also to be able to leverage the knowledge of somebody who is out there doing that kind of stuff.”

By the way, especially in venture capitalists, we have the concept of fail fast. So if you’re going to come up with a product that you think might be viable and then three months down the road, it’s not, then, if you have somebody who is an expert in blockchain and you decide, “Okay, I’m not doing blockchain anymore” and he’s not an employee, you don’t have to worry about “Alright, how am I going to fit this blockchain specialists somewhere else in the organization?”

You can say, “Hey, guys, unfortunately, this isn’t going to be a really good fit. It’s not a viable solution. We’re going to throw you back in the pond for somebody else to catch you.”

David: What we’re seeing in the fluidity of demand for experts is that it does move and it moves in a fashion whereby ─ particularly in a constrained labor market ─ it takes you six months or more to even hire and bring on someone who is a Tier A professional in what they do and knows the domain knowledge and is interested in the consuming work in that way and to open up a possibility where a Tier A expert who has an appropriate résumé and who has the desire to work in a different fashion ─ that can be a strategic advantage.

Chris: Yes.

David: And I would imagine as a funder that it’s not a good idea in a fast moving disruptive kind of industry to take investor funds and sit on them and wait and burn calendar while, in fact, you’re trying to solve a labor issue that you don’t know if you’re going to have in a year.

Chris: Not even a year! In three months, I might have that labor issue. Especially in the organization I’m in ─ I work for a company called “UPMC” and we jokingly say that it stands for “You People Move Constantly.” And the joke in there is that we’re constantly moving from project to project and we’re just going, “That’s not viable. Let’s move on to the next thing to find that new viable solution.”

So to be able to quickly reach out and say, “Hey, I need an expert in blockchain; I need an expert in FHIR which is a new restful approach to being able to have data exchange; I need an expert in FHIR or machine learning which is an ever-growing field that is insane to try to keep up with.”

David: What does the ideal senior engineer technical expert look like? I have been gaining from the marketplace that our definition of a senior technical professional is migrating so quickly.

What is this unicorn? What’s the checklist that you know when you’re talking to that person?

Chris: For me, personally, whenever I’m looking for somebody who is in the industry, I do not ─ and I think this is the biggest mistake a lot of technologists do ─ focus on the particular technology needs of the project.

What I mean by that is if I’m building a product that’s going to be in Ruby, I am not going to look at a résumé and say, “Oh, they have zero Ruby experience. I’m not going to hire them.”

What I do is I look at key fundamental concepts that I think every good engineer has: unit testing; domain-driven design; solid principles ─ things that are common across the entire stack no matter if you’re in Python, Java, .NET.

Once you understand those fundamentals, you can move from platform to technology and then, hopefully, by knowing that information, you also have found somebody who’s passionate.

I’ve interviewed people who are caught in the corporate atmosphere and have been there for ten years. They don’t care about the latest technology. They’re not true technologists.

I want a true technologist. I want somebody who might not know Python but, at least, they have looked at it. Or maybe they don’t know what Docker is but they can, at least, speak to it. Maybe they don’t know what Ruby or any other platform, they can, at least, say, “Hey, you know what, I know what a unit test is; I know what red green refractor means; I know the approach; I know what a microservice is.”

That’s the true passion. That’s what I really want. Then, I take it a step further.

Recently, I read an article and the CEO of LinkedIn said this. He doesn’t look at coding as being the top skill that everybody needs. It’s the soft skills. It’s being able to acknowledge that fact that “I don’t know.”

By having the power of being able to say “I don’t know something,” it gives you the ability to actually understand that and to go out and reach out to those experts and to be able to say, “Hey, I’m going to find out all I can so I can know next time that I have this problem.”