Growing Teams and Retaining Culture in Remote Health Care

Transcript

Introductions [00:16]

Shane Hastie: Hello everyone. Just to let you know, our online software development conference QCon Plus is back this November one to 12. You can expect curated learning on the topics that matter right now in software development. QCon Plus is a practical conference, laser focused on learning from the successes and failures of domain experts at early adopter companies. If you enjoy the conversations we have on this podcast, you'll get a lot out of Qcon Plus. To learn more about the conference, head to qcon.plus.

Good day folks. This is Shane Hastie, at the InfoQ Engineering Culture podcast. I'm sitting down across the miles today with Damon Lanphear, the Chief Technology Officer of 98point6, who are a healthcare organization. Damon, welcome. Thanks for taking the time to talk to us today.

Damon Lanphear: Thanks, my pleasure. It's great to be here talking with you.

Shane Hastie: Possibly a good starting point is why 98point6?

The Primary Healthcare Crisis [01:17]

Damon Lanphear: So first of all, for those who have the metrics system, 98.6 in the English system is the normal body temperature of the human being. And so we adopted that as a strong indicator to our audience that we're very much about healthcare and in particular primary healthcare. So in the United States, we've been dealing with what we call the primary healthcare crisis. And also sort of to qualify our term is when we're talking about primary healthcare, what we're talking about is the first line that one would interact with a healthcare system when you are needing medical attention. And this is going to be a doctor, that's going to be a generalist, that's very much concerned with anything and everything from episodic, acute conditions like respiratory infections and rashes and the like, to more complex conditions, or maybe even helping you to navigate a chronic condition.

And these doctors are going to be facilitating and acting as your center for anything and everything as you navigate the health system. Critical role. And unfortunately, as our health system in the United States has evolved, we've seen more and more movement of new doctors to specialization. And as a result of that, there's been a decrease in the population overall of primary care doctors. With that decrease in the availability of primary doctors, it becomes harder and harder to get a primary care doctor or doctor relationship. You often have to wait several weeks, in some cases months, to get in to see a new primary care doctor as a new patient, depending on your location in the United States. Costs go up as well. And with that decrease in access comes downstream impact for the health of the population at large. If people are having to make difficult trade offs between seeing that doctor for what maybe seems like an acute episodic condition, which may actually be indicative of something more complicated, you end up incurring both risk to the individual's safety over time, but also additional costs.

And as we look at that landscape, very early on in the company's history, we said, "well, there's an obvious opportunity here to apply what we learned about technology to bend the curve on the cost and availability of primary healthcare." We've seen this happen again and again. We're all familiar with the patterns that have happened in retail, retail delivery. With the big names. We all know globally there. With media, the delivery of media, where we've seen the application of technology to make it easier and lower cost to access a wider array of products and services. And with those understandings we thought, and we believed that we could, by partnering with doctors, apply in particular digital technologies that we all know well, working with mobile applications, text based interaction but also AI and machine learning to allow doctors to be able to deliver care to more people at a lower cost without compromising quality.

There's always that iron triangle as we might say, in technology when you're having to trade off time or somebody's convenience, quality, and access to feature set. You're going to have to give up one to get the other two and what we have proven to ourselves and proven to the market that we have been able to do is-through the application of artificial intelligence-allow our doctors to, without compromising quality of care, treat many more patients than they normally would in a brick and mortar setting. And in that lowering of costs, we then pass those savings on down to our patients, our customers, our partners, health systems, payers of healthcare, what are referred to as self-insured employers or employers that are providing health insurance to their employees. By delivering essentially fixed cost care.

So by way of comparison right now in the United States, if you were to go in and pay out of pocket for a primary care doctor, you're going to pay somewhere between $180 to $250 U.S. dollars per visit. When 98point6's model is on a direct to consumer basis, $30 for unlimited access for your first three months, $120 per year thereafter. Okay? So less than a single visit. And then each interaction is about a dollar. So much, much lower cost.

And so no longer do you have to make a trade off of, do I have to make time? Do I have to take time off of work? Do I have to think about a trade off between paying an electricity bill, paying rent and going and see that doctor. We are endeavoring to eliminate that trade off. And that's really the why behind 98point6.

Shane Hastie: Really interesting. If I can delve a little bit deeper. What's the why for Damon?

Damon’s Background [05:19]

Damon Lanphear: The why for me is a long time technologist, I've been building, writing software since I was 17 years old, going back into the midst of time, more than 25 years now. And throughout all of that, there's always this sense of software eating the world. In your ability to build software, you can really accomplish a great deal. And there's so many obvious opportunities out there that are primarily in the domain of entertainment, maybe finance. But none of them quite for me, scratch the itch of how do we impact and help people in a way which I think is very personal, very intimate, very broad in its applicability. Not just limited to individuals who have access to money and everything that comes with it.

And for me, working in healthcare is a vehicle for doing that. And in particular, working in healthcare in this way. To be able to take a skillset in software and be able to apply it in a way that I think can change just about anybody's life. Because everybody needs healthcare. Everybody has to think about this financial trade offs, regardless to where you are in the economic spectrum. And to be able to do that as part of my work product, for me has been deeply impactful and deeply enriching. It keeps me engaged in a way that I think I have not yet been engaged up until my time here at 98point6.

Shane Hastie: In your CDO role at 98point6, one of the things obviously if we look back over the last year in a bit, huge impact I would imagine from the pandemic, how has 98point6 kept up?

Telehealth was very slow to start [06:44]

Damon Lanphear: Particularly in the U.S. prior to the pandemic, there was an emerging discussion on the role of telehealth. And there's definitely this understanding out there that there's been a first generation wave of telehealth, which is what we refer to as kind of analog telehealth, euphemistically. And that is to say telehealth that delivered over the telephone.

And as the industry is looking at well, that experiment and saying, "well, it's had moderate success, but not really the lift that we would've expected. What is the next wave going to look like?" And that's really the advancement as maybe as obvious as it might, might be to you and I talking here to technologists, listening to this podcast, that the wave of digitization of mobile apps would've impeded healthcare. It really hasn't. And I think the leaders out there in the healthcare space understood this, and were trying to find ways to advance digitization of delivery of healthcare without too many great answers out there, but they knew something needed to happen.

The pandemic accelerated digitally delivered healthcare [07:29]

Damon Lanphear: We were emerging as a company just as that thought process was beginning to pick up steam. And it really took the experience of the pandemic of everyone going of everyone, having this experience of having to ask yourself the question, "how do I use digital technologies to allow myself to continue to function well under a restrictive environment?" Having digitally delivered healthcare became this obvious choice and just accelerated that for us. And so it actually took what were maybe seeds of ideas in some of our partner companies and allow, allow them to blossom fairly quickly. And as a result of that acceleration, we've actually become to understand more than anything all of the ways in which primary healthcare is being added onto touchpoints in the health system, across the spectrum. So I'll give you some examples. I think the obvious touch point is going to be the health system, but invariably health systems are going to have you go out and get lab work done.

When you get lab work done, you need to have your lab results interpreted. So these lab companies now are asking themselves the question, "what can we do to help streamline that experience for our patients that are having labs done and delivering interpretation of results, even ordering labs in a way that adds convenience to the patient." And so, while that was sort of an inkling of idea, the pandemic really accelerated that as a possibility, and we're very much at the intersection there.

So as a consequence, we've grown rapidly. We've brought on a large cadre of engineers. About 50 engineers in the last six months. We're on track to hire close to 50 more before the end of the year to keep pace with all of this increasing demand for us. And at the same time, learning about this diversity of touchpoints of how primary care functions across the spectrum, from acute cases to chronic care management, to behavioral health and all the ways that technology needs to be built to support that. It's been, if any, in acceleration of a learning curve that was already established. It's really put wind in the sales in that respect.

Shane Hastie: Significant growth over a relatively short period of time. As the CTO, how do you keep that growth? One, where do you source people? And I'm obviously leading towards the conversation about remote versus locally based people. And also, how do you make sure that the why of the organization carries through as you grow so quickly?

Replace the whiteboard test with a take-home coding assignment [09:44]

Damon Lanphear: That's a fantastic question. I think obviously with us making the decision part way through the pandemic and realizing that we could function as a remote organization at all, would function well, and maintain our culture. Once we sort of realized that we said, "well, it's kind of a foregone conclusion that we're going to be able to open up the gates and begin to proactively recruit remotely. And I think fortunately being able to recruit directly, do all inside recruiting, we don't work with any type of outsource recruiting or contract recruiting. It's all done with our internal talent team, of them going in establishing presence in markets all over the United States. And I think in short order here, we're going to be also recruiting in Canada, which is exciting for us as well. At the major tech hubs of Boston, Austin, Texas, the Bay Area, down in the Silicon triangle, down in the Carolinas.

And with that, we've been actually very quickly enhanced the geographic diversity of our team just by having all of our professionals that are engaged in recruiting talent, be able to establish presences in all those markets. I think one of the big things there of course is thinking about assessment of talent coming in the door. And I think a lot of the engineers that come in and interview with us are somewhat surprised at the emphasis that we place on behavioral interviewing. With typical technical interviews there's a lot of emphasis placed on the so called whiteboard tests. That's been replaced with, which we've done very early in the company's history, a take home assignment. Where we give the candidate time to work through a solution writing code as they would for a production system. That's submitted to our team, we assess that independent of the interview process and use it kind of as a preamble to the interview process.

And then in the context of the interview, have the candidate talk about their solution. That's about one and a half hours of context of the overall interview day. The balance of time, the balance of the remaining five to six hours is spent on behavioral interviewing. That's crucial, because you ask this question of like, "how do you ensure that the why is preserved?" And I think for us the why is encoded in our core values as a company. The company has a set of core values, of course. We are all familiar with that as a pattern out there in corporate America, corporations globally. And for us, the way we've internalized these, is we've selected core values that we believe that if they are lived out are going to result in alignment with our mission and therefore alignment with our business objectives and results in our business objective.

And so these are things that I'm sure you've heard elsewhere. Things like having bias for action, focusing on result delivery, focusing on applying data driven decision making, relentless improvement or continuous improvement principles, the like. All the familiar stuff. And then making sure that our candidates have experiences that speak to these core values. In other words, they've lived them before and they can talk to us about how they've lived them before. 

Onboarding new people effectively – communication, mentorship and buddying[12:10]

Damon Lanphear: As they come on board, then what happens is a number of things simultaneously. First there's an overall onboarding that the company is taking individuals through. Which is very much oriented around helping everyone understand the why of 98point6 as I've already talked to, but also how that's done in practice. Walking them through a demo of the product, getting their hands on it, making sure that they understand and have empathy with our patients, with our doctors. These constituents that we're serving.

Damon Lanphear: And then move them from companywide education on the why of 98point6 to the specifics of the technology organization. That's where mentorship plays a critical role. And partnering engineers with a buddy and having that buddy be there to not just to show that engineer around, helping them navigate our written artifacts, our code base, our processes and the like, but also to act as kind of a real time correction, if you will, on acclimating to a culture. Because inevitably, you're going to walk into a collaborative environment. Working in a document, in a meeting, engaging a code review where the rules of engagement you still have to learn.

And it helps a lot to have a trusted individual that can whisper in your ear, "oh, as you are contemplating making this comment in this code review, here are some of the things you might want to think about." But to have that real time feedback, or if you kind of cross the line, if you will, get bumped into that electric fence to have someone do that to you in a safe space and you understand and learn the ropes that way. And in a way that I believe is accelerated.

A useful metric: time to first commit [13:42]

Damon Lanphear: And so one of the metrics we track is a time to first commit. So someone gets onboarded, how long before they're committing code? And that's a proxy measure for a lot of different activities. Are they able to understand the code base? Are they actually receiving work in a timely fashion? Are they supported in doing their implementation and actually getting their code review accepted? Or this is a pull request accepted. And we've got that down to where it's almost within a sprint, and a sprint for us is about two weeks, which is phenomenal outcome. And it's really a consequence of putting effort, persistence, intentionality into the onboarding process. As opposed to say, which we used to do in our startup days, throw them in the deep end and say, okay, good luck. Let's see how it works out" and deliver that intentionality. Which I think we understood as we were driving, adding more and more people to the team faster.

As many of those people were remote, having that be successful and not having the wheels go flying off the bus as the consequence of that, being intentional about this process, became more and more essential. And if you were to go and look at our written artifacts on that year, having established a working group, having that working group study what we're doing, what's working, what's not, and then apply the principles of continuous improvement to how we're onboarding to ultimately arrive at where we're at today. And I think as with anything at 98point6, it's never done. There's always this process of saying, "what can we do better? How do we go from a sprint to a week if we can? How do we increase employee satisfaction through that process?" Are the types of questions we're going to ask ourselves next.

Shane Hastie: You're in the healthcare environment, so the story I'm telling myself is heavy governance, lots of regulation. How do you move fast in that environment?

Regulation and governance as an accelerator not a hinderance [15:15]

Damon Lanphear: That's a fantastic question. So I think it helps to talk about the two sorts of regulation that we live under. One is concerned with privacy and security. So obviously you're dealing with highly sensitive information, not just personally identifiable information, but information that's regarding, you know, intimate aspects of one's health and say wellbeing that can have implications for your relationships, with people, with your job, you know, financial relationships with your insurer and so on and so forth. So for all the right reasons, the federal government in the United States has significant protections of both the security and privacy of healthcare data and mechanisms to ensure that entities are making good on their obligations under federal law and the obligations to the patient.

The other dimensions fall under the aegis of the Food and Drug Administration in the United States. And that's an area that we are moving into slowly over time, because what we're developing, which is really about the automation of the application of medicine will eventually be regarded by the FDA as a medical device of sorts. So a novel medical device. And in that setting, what ends up happening is you have to apply a software analog of best manufacturing processes that you would find in a place that might be designing and manufacturing pacemakers, or devices of resuscitation, or devices that might exist in a hospital setting.

And so all those best practices, as it turns out happen to be things that you need anyway for writing software. And I think if you come from a software company where you were maybe being a little loose goosey, so to speak in your application of best practice and maybe a little bit of a shock. But I think once best practices are codified, are promulgated throughout the organization, well understood and well practiced with the right management support, it can actually be an accelerator. Because what ends up happening is you, in your processes end up, I'm sure you've heard this phrase. I'm sure your audiences use this phrase of shifting left of considerations. You know, whether it be how you're going to test or what you're going to test, your security considerations, your design, trade offs. And being able to do that earlier on in your process means that doing it later on after you, you've invested more in your implementation time, perhaps running down the wrong path, having to unwind and push down a different path, you can actually receive backend benefits where the most expensive parts of the implementation process happen.

And so there's some counterintuitive thing that I think happens where inevitably these processes, whether it be for security and privacy considerations or, you know, best manufacturing processes, I'm kind of giving you air quotes around that for your audience, where it seems that that would be a hindrance. Those things are all designed to help you get ahead of the inevitable.

The inevitable security incident, the inevitable whoopsy around privacy, the inevitable quality issue with the software, right? That by doing these things upfront, you're saving yourself time later. And we've proven that time and time again, where we have very low defect rates, a fantastic track record on privacy, where we're not having to run fire drills out there in the public sphere with very sensitive data with our patients, most intimate concerns. And so we found that contradiction to hold very much true. But we didn't get there overnight, I think that's an important thing to understand. It comes from very early on in the company's history saying, this is how we're going to operate in this way, having a formal SDLC, documenting it, making sure that we're following it fairly religiously, helping people get over that reaction when they arrive of, "oh my gosh, there's all this formalization."

Once you get over that hump, it actually becomes a very liberating thing where our engineer's able to operate with a high degree of certainty that what the work that they're doing is correct work, is verifiably correct. So I think that's a counterintuitive thing that I would say to people out there thinking about working in the healthcare space, thinking about being software engineer in this space and not be afraid of it for that reason. But certainly, if a company's entering the space, making sure that they're putting the right structures in place, having solid technical program managers there who are able to translate these external requirements into actionable processes internally and then support them, is a critical ingredient in making that work. It's totally doable provided you have the right infrastructure in place.

Shane Hastie: The application of AI in your systems. Can we explore a little bit there? What are you doing with it? And how's it making an impact?

Using AI in patient interactions [19:13]

Damon Lanphear: Any conversation about artificial intelligence in my view needs to start with a definition of what the problem is you're trying to solve. You have to work backwards from that in all cases. A lot of times you hear conversations of AI focus on specific methods of modeling or predictive methods. Deep neural networks gets tossed around a lot. What those conversations tend to miss is the application, that is if you will, the secret sauce of understanding a space well enough to understand what is automatable and how one ought to go about automating it. Very early on in 98point6's is history, we asked ourself the question "well, would patients interact with doctors at all through a tech space medium? Would doctors be able to practice medicine at all through a tech space medium?

And so, we launched a beta. We launched it in our home state of Washington. We're headquartered in Seattle, Washington. And we offer primary healthcare for free through an app. We put it actually in the local free newspaper, come get free primary healthcare. It's text based, here's the app, here's where to download it. So and so forth. And what we learned very quickly was that there was a very phased interaction between the doctor and the patient. The doctors were applying from their clinical experience of taking you through the exercise of eliciting your findings, the medical findings, synthesizing that into a diagnosis and then communicating to the patient their conclusion, and then what the next steps are typically a care plan. And one of the linchpins that we saw very quickly is that a key observation, doctors start these visits out with an open-end question. What brings you here today?

Deliberately open ended because I think doctors understand that patients want to tell their own story and in doing so, they're going to share information that is both about and adjacent to that chief concern. And that adjacent information is as important as a core issue. And so for example, there may be someone that's experiencing GI, gastrointestinal issues. They may also talk about the fact they've been under stress at work. That relationship with stress to the GI is relevant to the doctor's diagnosis. The fact that the doctor gave the patient room to tell that story allowed that information to come to light. So, that basic understanding helped to frame this problem of how we begin to chip away at automating that act of gathering medical information from the patient. Which, we understand is taking up the lion's share of the time of the patient-doctor interaction. And so we set about the process of building an artificial intelligence that would elicit from the patient that story, and use that information to predict the questions that happen, that the doctor would ask.

How we did that. That's something we keep under wraps. We don't talk about that. But that's an example of free text input, predicting questions from our doctors. And one of the key challenges in there is that any type of artificial intelligence model relies on a high degree of agreement amongst the human beings that it's attempting to emulate. Simple example, if you're training the AI to understand the difference between a domestic cat and a tiger. You want to make sure that all these humans that are making that judgment all agree that for a given picture, which one is the cat, which one is a tiger. And as it turns out with doctors, they tend to all have varying opinions, which is why I think in a lot of cases, humans will seek multiple opinions from doctors. There's diversity of the information. They're getting diversity of how it's translated and diversity in medical practice. And navigating that diversity is actually one of the core challenges we had to overcome technologically.

Again, I'll have to stop there, but it kind of illustrates that as an AI task, what we're confronted with is I think, non-trivial and always work in progress. The rest of the medical interview, beyond that phase, we rely on expert systems. So, where AI is a learned approach, which is to say you're giving data, which are examples of humans making judgments, expert systems are really about translating expert knowledge in the case that of our doctor, to a digital format, to a computer program. And we've built technologies internally to facilitate that translation. So a lot of doctors actually do express themselves in a natural way that is ultimately executed as code in our system. And so what they're able to do now is model their decision making process explicitly in a WYSIWYG visual environment. And that actually adds up being part of our runtime, which is super exciting and allowing us to very rapidly advance the leading edge of our ability to apply that form of AI across our system.

And what we're doing over time is slowly chipping away at those phases that I illustrated before. The gathering of medical findings, the delivery of the diagnosis, the delivery of the care plan through a combination of learn methods and expert systems. And I think more importantly, and this is one of the exciting things about what we're doing is those individuals whose work that we're modeling, they're our employees and they're working in tandem in a hybrid human computer model with the AIs that they're training. And so it's something that on ongoing basis, they're able to critique it, give input to it in real time and drive our continuous improvement cycles in that way. Which is a hugely valuable part of our overall platform, the development of our overall platform. Not just in the AI front, but also in the development of the software that we use to support the doctors, sort of the mainline software that supports our doctors through the calls with the user interface with patients. Which is an uncommon premise, I think for doctors, whereas I think a lot of doctors would be operating in a health system, for example.

And I think we all by now have had that experience with going into the doctor visit. You're sitting down in the examination room. The doctor is typing away on a computer, the software that's running in the back end there, the software that the doctor doesn't control and they'll complain about it to the end of time. At 98point6, we're building that software alongside them. So they can complain about it, but we prefer to think about is giving feedback. Then we can act on that feedback as quickly as we can to relentlessly improve. And so in that we think as much about the problem of AI as it is really about building a human computer hybrid to facilitate the efficiency of our doctors. To allow them to practice medicine at a higher scale at the top of their license through the application of technology.

Shane Hastie: Interesting stuff. So one piece of advice for the person climbing the technical career ladder. You're the CTO sort of got pretty high up there. Somebody who wants to emulate that.

Technical leadership is more about influencing than directing [25:03]

Damon Lanphear: I think the first question you have to ask yourself, any technologist ask themselves is, do I want to manage or not? There's definitely different categories of Chief Technology Officers out there, Vice Presidents of Engineering. Some Chief Technology Officers function as purely architects, lead architects in a given company. They may not actually have any direct reports. And that's a track of, maybe like a super senior individual contributor track. A track that I followed was really one about management. And I think speaking, I can actually talk about both tracks and sort of my guidance on both speaking first on the management track. I think that there is this understanding that you need to adapt and model over time of essentially letting go of your direct agency as a software engineer. You're accustomed to solving problems purely through your knowledge of the code base, your ability to write software.

And it's tempting to essentially act as a genius with a thousand helpers. Of essentially directing the action according to how you want it to be executed. As opposed to thinking more about how do I, one, get the right people into the right positions, ensure they're trained to do the work, ensure that they have the right problems in front of them and have the right framework for making trade offs. That becomes your sandbox. The world in which you are now engineering. And as you step up the layers, you're doing the same thing, but at higher scales. Instead of talking about individual contributors in that problem set, you're now talking about managers of managers. But it's the same problem. And you really are thinking in terms of "how do I build a machine” - tnot running the risk of industrializing human beings.  I don't mean to, to express it quite that way, but you are essentially building a machine, which means you're having mechanisms and processes to deliver an effect of ideas come in and high-quality software comes out.

How do the individuals that I'm hiring, putting in place need to be directed in order to deliver that effect? And that's the engineering thought process that you're engaged in at that level. Allowing yourself to delegate without abdication becomes the skillset and understanding how to right size that.

On the technical track. There's always that challenge of as you rise it through the ranks, and I've gone down this path as well, where you end up trying to influence a large team of engineers as that architect, as that principal engineer. And one of the things I coach our principal engineers on is really about relationship building. And your influence is much predicated on your ability to have empathy with the people that you're influencing. So if you can come with that technical solution, that technical solution had better taken to account the needs of the audience that you're serving.

You coming to them, trying to cram a solution down their throat without an understanding of, true understanding the problem space, of how the engineers are impacted, how the end user is impacted, is largely going to fall in deaf ears. And building those relationships, building that trust takes as much time as the actual design itself. And as much a human consideration that plays into the success of your work as the design of the technology that you're working with.

So two separate little pieces of advice and two separate tracks for climbing the ladder.

Shane Hastie: Damon, thank you very much indeed. If people want to continue the conversation, where do they find you?

Damon Lanphear: Easiest ways on Twitter. I'm Damon_Lanphear on Twitter. So D A M O N underscore L A N P H E A R.

Shane Hastie: Wonderful. Thanks for taking the time to talk to us today.

Damon Lanphear: My pleasure. This is fun.

Mentioned

• 98point6
• Damon on Twitter and LinkedIn