Building impactful tech is hard, especially when lives depend on it. I spent the early years of my time as tech founder/CTO of Current Health in the weeds thinking about our tech stack in terms of applications, electronics, data and algorithms. My objective then was turning the art of the possible, given our tight resources, into a product that people might want to buy. That was naïve optimism. The more I learnt about healthcare – the more I realised that success in health-tech is from thinking outside the code. I had to understand healthcare as an interacting system of people, organisations, incentives and risk where complexity and change create friction everywhere. My biggest learning curve was embracing this new perspective. In this talk I'll reflect on the journey I took - and draw on many stories about how we painfully learnt the hard way to not just survive when things got tough – but successfully scale up.
Thinking Outside The Code
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Wow. This is a lot more of people than I was expecting. It's fantastic to be back here at Turing this year. So we've been supporting Turing now, Julie, for four, five years. It feels like an era. So it's fantastic, Dan. Thank you so much for all coming.
Now I'm hoping everyone's here. There's another three talks in parallel. So I'm going to talk a little bit about some of the things we did at Current Health that really kind of helped us scale some of the impacts and success of what we did.
And a lot of people ask me about what is it we did that that kind of made us successful. That's a very long book of, well, errors, mistakes, things that broke. It was a bit of a disaster for a lot of the time.
But there are a few things that came out of that and hopefully there's some builders here that I can kind of inspire some of the engineering decisions and leadership that you you give and and help you figure out how to to do better, you know, with your own products and companies.
So firstly, who am I? My name is Stuart Whitey. I'm Co Founder and CTO at Current Health. I was CTO, stepped down late last year as we grew from a hundred and thirty to about a hundred and eighty people. At Current Health, we are really building one platform for delivering health care of all acuities, many disease pathways in the home worldwide.
Our main kind of business is really across Europe and the US. The US has been a huge growth area for us. And the story of the company was really that in twenty fifteen, I was finishing my PhD back then, so it was really a scrubby student.
I'm sure there's probably some students around today in that position trying to figure out what next, big companies, startups, start their own thing. And I was very much in that position. And I had the pleasure of meeting a Chris McCann, who has basically ruined my life ever since.
Don't tell him I said that. He'd probably say the same about me. But actually, we we kind of clicked and figured there were some interesting things we could do together. So back then, the world was a bit of an odd place. We kind of had no idea what we were doing.
We didn't really kind of have much of an idea other than trying to build a healthcare company, which seemed like a great idea. We had no money to do that. We thought, well, let's build a wearable because that seemed like a great idea and Fitbits were cool and and that was kind of how how things started.
So we were in bedrooms at that point. There was nothing. There was no money. There was kind of no investment. We were really trying to kind of figure out what this idea looked like. Cue kind of five years of toil and trouble, we've got some of our early team here.
Fantastic team from twenty seventeen, twenty sixteen, which is quite incredible. We obviously started building and then kind of headed into COVID with what was really a pattern of a system that we thought was a great idea, but we thought was going be ten years of building and growing.
And we put in place all these different ideas and built all these kind of bits, sold various things, kind of weren't sure where all this was going to fit together. And then COVID came along and it wasn't COVID that changed what we were doing, but really those ten years of delivering health care at home, which was really kind of a pivot from twenty seventeen, actually turned out that everything we built kind of suddenly solved a problem that everyone wants to solve very, very quickly.
And that was really the kind of context of this talk to how can you make decisions, build things that give you an opportunity that actually when the toothpaste is out the tube, you can start to bring all that together and and move very quickly and and find success and impact at scale.
So quick bit background about me in this talk is is starting twenty fifteen. My background was really as a PhD, so I was kind of straight out academic. Spent a lot of time building software and writing code, and a lot of my focus was about the art of the possible.
So my brain really thought about the world in terms of data algorithms, software engineering. What I hadn't really spent a lot of time thinking about was if you wanna build something in in a domain as complex as health care, how do you actually make decisions that give you a chance to build a product that's gonna be successful in that domain?
What is it that in a big enterprise like health care, need to start building for? What is it people expect from from what you're doing? And that was quite a big learning curve for me because this was all really quite new to me.
I realized that writing smart code was just not gonna be enough. What I need to do is figure out how do we make decisions, build chunks of code, parts of systems that really would have give us a chance to kind of figure out on the fly what we needed to do.
So a lot of engineers look to product management to do this for them. They they go to product manager, product manager goes, speaks to a customer and then back comes a set of requirements and hey, this is what we're going to build. The issue is a product manager can't really tell you how to build what it is you're looking to build.
It's up to you as an engineer to try and figure out how do we make decisions about how we structure code, how we hang together systems. And that really requires an understanding of the domain that's just so much beyond, you know, really a set of requirements that product manager can give you.
And so like above all else, I think the big thing I I want you to take from this talk today is that, you know, engineers you can build a real superpower by thinking outside of those the code that you work with day to day and think about what is the context of how this code is being used and how can you how can you do things, make decisions there that that really mean that you open up a whole host of opportunities.
That really is a superpower for an engineer to have that. So this is basically me in the early days. Actually, Tim probably argue is still me now as well, but let's not go there. So it was a really huge professional personal journey to to build current health.
And as I said, kinda I came from really being quite naive and knowing really not a whole lot about what I was doing. It was quite interesting to learn on the fly and burn, well, burn burn the team. Probably some bad memories there of us getting things wrong and trying to figure out how to solve it.
And I'd like to kind of reflect a little bit on that during this talk. Health care is hugely complex. Think probably everyone here has had some positive, negative experiences of health care. And there's a lot of things going on. Lots of people are working together to deliver really quite high risk complex things.
And that makes it quite interesting to build systems for. So people do ask us, was it that actually helped us be successful? How did this exit come about? What did we do that meant that we had something that was unique? And there's kind of a whole bunch of ingredients that came together.
And I think the first answer there might be some luck. There's definitely luck rather than judgment, but there's definitely some good decisions along the way as well. There's a lot of anecdotes from healthcare in terms of how all this comes together that are unique to healthcare.
But I think anyone here that's working on enterprise technology with big businesses and complex industries will probably see some similarities here. Above all else, you can kind of mention, if you can get ready for when the toothpaste is out the tube for us, COVID was a pivotal moment in the history of the company.
And it wasn't COVID itself because we knew it was going to burn out relatively quick, actually went for longer than we thought it was, was going to. But we at least were kind of three or four years ahead of our competitors when things like started changing quickly and everyone realized you can't keep on building hospitals anymore.
We have to deliver care for patients at home. That was where we were really quite ready for that. So the first thing I want to talk about when how do you make good decisions as an engineering as an engineer and engineering leader and build good products that give you an opportunity or a chance to actually scale that impact.
And the first thing here was a big kind of learning journey for me is that thinking about the world quite differently. So when I first started this, I I looked at the customer as being this person that here is this one person that's going to buy our products and they're going to be they're going to love our products and they're never going to look back and they're just going to use our products and it's going to be all great.
Two years in, I realized that wasn't actually the case. And healthcare professionals are really quite a difficult bunch to please. And it dawned on me that actually like a lot of what we're doing here is working with systems and in particular systems of systems.
So when you're building a product and making decisions in terms of how you're writing code, you need to be a bit mindful about your user interface that you're putting together, the web interface, the APIs that you're integrating into. These are all plugging into a system somewhere and you end up in this kind of whack a mole of you build something, it gets used here, it breaks something over here, it change something over there, and then these people over here get really upset by that.
And so what was really interesting for us is that we built systems that we thought were quite simple. And to our user, it really was quite simple. But what we didn't anticipate was that in health care, a lot of health care is flows and processes all lashed together.
So we put more people into the home being with care being delivered at home and there's not enough nurses to look after them. And the reason not enough nurses because there's no resources being dedicated into that. And that's kind of far beyond what our individual system provides for people.
But actually managing flow and data and I suppose we're supporting some of these things are all things that as engineers we can build systems that better plug in and configurable for that type of thing. So some of what emerges in those systems and the changes that happen there is actually there's a lot we can do as engineers to try and build software that works well around that.
What was actually really kind of interesting to me is that, bear in mind, like I came from a background where algorithms and data were all about. That was why I kind of lived and breathe and got up for every morning. But actually, more I work with the NHS, the more I realized, as I'm sure many people here are well aware, fax machines are still a really big thing in the NHS.
And it's unreal to think that people are still actually writing out a four forms, signing them off, faxing them, and then someone then writes that into a computer system downstream somewhere. And it's obvious that they just haven't integrated things. But for us as engineers, we can spend a lot of time, it's actually quite easy for us to do those types of integration projects.
In terms of the technology is simple, what's hard is figuring out how you connect those dots between those systems. And so actually, for the most part, people think about technology in terms of what is actually straightforward simple integration. The bar is actually quite low there.
Fancy tech often is not needed in those scenarios. And I'll come to this a little bit more on workflow. It's actually really kind of it's quite interesting that you can find a lot of value by doing quite straightforward simple things. And for for engineers, these are usually quite straightforward simple tasks actually can be a bit boring.
But if you can start building smart ways to kind of repeatedly do this, actually you can get a lot of value very quickly in some of these big environments. So it gets quite hard to manage some of these change projects. Our team will know like from having worked with NHS, it's really quite difficult to bring everyone together.
And there's just so many touch points here that when it comes to building interfaces, if you can start to expose what in our case, our system is plugging into four or five different organizations at once. If you can start to interchange information between these organizations and figure out what that looks like, then actually it's quite helpful because weirdly like things emerge from these systems in terms of people's decision making and their kind of their journey to adopting this technology actually arises from how they interact with the system both now and how they anticipate
this in the future. And that was really quite a journey of discovery for us that as a small startup, we turned up with this system, started making people use it. They hated us for it, but then they told us what they actually wanted and it helped us then figure out how we started delivering what they really did want.
So that brings me next to another area when thinking kind of beyond just writing code that that really was quite important. And and this has been a you know, what you're seeing here is is US healthcare, who's paying for what and where that paper is shuffling.
And that's actually the the the kind of summarized view of what this looks like. These enterprises are absolute beasts. And it's all about trying to kind of understand the motivations and and intentions of of what everyone here is trying to do and the incentives that emerge from this.
And it is really quite a a nightmare. The one thing that that really was quite painful for us at at Current Health, right from the very go and actually we've made some really good decisions around this. And if there's one thing that I would tell anyone here that's looking to build software, particularly enterprises is everyone says go and find out about the requirements of what your customer wants and that's great.
You can go and do that and they'll tell you the functionally, here's what we want a system that does X, Y and Z. What they won't tell you is the three hundred things that they wanted to do in a certain way behind the scenes.
So in terms of data privacy, data security, reliability and all these things are virtually impossible to retrofit in our system. Actually, Robert over there, you know how painful this is. Yeah. So as a startup, we move really quickly to build right code that did all these functional things.
And now as a larger company, everyone's actually treated as a mission critical system that needs to work, needs to be online and satisfy all these constraints and requirements. That's now where large teams of people are now having to rebuild, rewrite various parts of what we're doing to try and actually do this a heck of a lot better.
And it's got to be said, if you get this right early on and make good decisions early on, it's a hunting license for these bigger contracts. The bigger the customer, the more diligence they're to do, the more painful this will be. And so you really need to be thinking about ways to get on top of this.
And there's nothing better than having an engineer in those early conversations who can start thinking about what does this need to look like? What are the what is the norm in this industry? And that's been that's actually been one of the things that people ask me, how do we actually get through diligence and get a deal like we did done for the exit of Current Health?
And actually being on top of this was one of those things. Another area that's been really quite challenging for us is we spent a lot of time talking to these large organizations about why should they use our system and functionally is one area where they look.
The other area where they look is they need to understand what we're doing. And when it comes to SaaS, it is a black box to them, but they spend a lot of time trying to understand low level, what do we actually do in the cloud.
We say to people, we use AWS. The question that comes back from them is, well, how? Where's our data going? Like, what do we do with that? And so a lot of engineers focus on writing code and and engineering documentation. There's a real skill in stepping back from that and thinking about how do we message all of this stuff that we put together this complex system and in our case a platform of all these micro services and cloud infrastructure, how do we actually message some of this to a customer to
reassure them that they should actually use us. And so that kind of ability is really kind of valuable to scaling this up quite quickly. There's another thing that I actually had quite a few arguments with Chris, Co Founder at Current Health in the early days, because it sent me crazy, but I actually understood where he was coming from.
And we started out our journey with a plan to build a wearable. That was what we were doing. We were building a wearable and we were building wearable in hospital use. Now hospitals are just a nightmare to sell to, but that allowed us to develop the wearable.
What we realized is actually no one really want to buy just a wearable. What they wanted to buy was unsurprisingly a solution to manage health. The issue there was that healthcare is really complicated. The products to do this didn't really exist like one platform.
And the issue we had is we're a start up. We've got finite resources. We haven't got many people. We sure as hell haven't got much money. We can't keep on raising money. But everyone wants to buy from a single vendor and they want to bring all of this all this products needed to manage the whole workflow of healthcare at home in one place.
And the issue there is that as a startup, the number one thing you want to be doing is focusing on one problem solving it really, really well. It seems like a great idea and exactly what you should be doing. And that was my view on things.
Our customers didn't want to buy one thing from one person. I want multiple things from multiple, but they wanted to buy lots of things from one person, keep it really simple. So our poor engineering team got handed about three hundred requirements of lots of different things.
People got quite frustrated and we started building lots and lots and lots and lots of things. There were definitely some good decisions we made around partnering with people and to a point that works, but then it's actually quite difficult managing things like support and there's some complexity and challenges that arise from that.
But actually, weirdly, you'll see if you look back on the history of Snap forty, Snap forty was really about wearables. Current health was about a platform for healthcare. And if you look back on any of our decks and kind of messaging over time, you will see lots of changes.
And it wasn't like the healthcare, the home healthcare was kind of in twenty seventeen, twenty eighteen. But the big change was really around this, how do we turn our product from a device into a platform and that happened around twenty eighteen. And that was one of the things that really helped us be successful.
The final thing there is, one of the challenges we had and I think superpower for engineers is understanding the domain they're working in. Now, I have never been sick enough to spend time in a hospital and have to go and be managed and have my care managed at home.
So I've never had the experience personally of what our customers and the patients are having. That's a problem because I don't really understand this domain that well. I've experienced it through family, but the truth of the matter is, it's difficult to find people that truly know the product.
And that's really quite challenging. And our team will know from the early days, we threw them out actually to the US. We sent people out for kind of an exchange to spend time in hospital. I think that was quite a big moment for our team to experience that.
What has been interesting to me is we have a team member that has got a chronic condition and has spent many years in healthcare dealing with that. And his perspective is actually very, very different in terms of like how he looks at what we're doing and and why we're doing it.
And that's really been quite valuable and and I kinda always looking for ways to try and kinda throw engineers in the deep end and help them better understand what's going on. So that really brings us to complexity and this is the bugbear of everything.
This stuff keeps me awake late at night. So what you're seeing here is basically organizations that govern US healthcare. And it's actually only a small subset of them. Well, US healthcare is a bit of a mess at the best of times, but the NHS isn't much better.
Really, you know, what makes healthcare complex indeed, you know, most industries complex is there's just so many stakeholders, lots of systems working together and governance and then the legacy of kind of history of how this has all evolved over time. One of the things that actually served us quite well at Current Health in the early days is that we took a Microsoft's architecture, which back then felt like a really terrible thing to do because it was so much complexity for managing all these kind of dependencies and and how they all kind of hang
how they all hung together. But actually what it did is it forced us to think a little bit about how abstracted and modularized our code. So it was actually quite valuable that as we started to change a platform and hanging together all these partner services we were using, we were able to start plugging things in like quite cleanly, quite nicely.
And it wasn't until we hit about one hundred people that this approach actually started to serve us quite well. And if you can match and make decisions on your architecture that kind of work hand in hand with the domain you're in, actually quite helpful because it gives you some extensibility and flexibility to move quite quickly.
And that's one thing for sure when you're burning cash every single day as a startup, it really is is quite valuable. There were some interesting effects that we saw in in health care, and this is where understanding the domain is is kind of interesting.
So we always had this idea that, you know, what we do as a platform, we obviously have to take the data up. Our platform takes in all this patient data and we have to exchange it with the health care system. And they have all their systems, their databases, their electronic medical records that hold all that data.
Simple. We'll just plug it in and exchange it. And then I was in a call where it turns out there was a health care system that wasn't really a system. It was like a Frankenstein organization where they've merged like five health care systems together over time across vast geographical spaces, and it still got five separate databases.
So my theory about it being really simple that we just plug it in and away we go, job done, turns out wasn't so simple after all. And so that broke a lot of architecture because some assumptions have been made, but that wouldn't happen.
And it's it was really simply a case that we just didn't understand health care. And it turns out in the US in particular, this was a really common arrangement and we had to rethink a lot of architecture. And if there's one thing that strikes fear into engineers is redoing architecture at scale, it just becomes nightmarish.
So tech debt was a kind of perpetual problem of of what we did and still is today. If there's one thing I'll say to anyone that actually writing code right now, just put explicit versions on your your APIs because that burnt me so many times.
Implicitly versioning anything is just a disaster. Just don't go there because you're just six versions down the line, you just it becomes like a logical heads, you know, head **** is a nightmare. Just don't go there. So I mentioned a lot about building versus partnering and how you can kind of abstract some of that complexity.
We did have lots of partners that we worked with for various parts of our solution and a lot of them burnt us quite badly. At the end of the day, building it is good. Supporting it is typically a lot harder. We've been asking our engineers to be on call quite a lot and engineers rotate, which is great for them to get experience of healthcare, but is tough on engineers who are building at the same time.
It makes life really, really hard. It's, again, a few few frowns right now. It is tough. And, Kenny, yeah, thank you to our team for working **** ** that. With a mission critical system, it's it is tough. We spent a lot of time trying to manage configurability of our systems.
So because we've built a platform, everyone does things so different that we had to build in all of these feature flags and configurability. There is no doubt that that made things very difficult with test cases, test suites that were really not sufficient, really made things quite difficult in the early days and we are now still on a treadmill to try and catch up with that.
So that brings me then nicely to thinking about what is the risk? What does the risk landscape look like in the domain you're working in and in the code you're writing, what is the impact on that code? Now, it's unsurprising risk and liability really are everywhere in healthcare.
And it's really important, everyone figures out how to balance and manage that. Engineering, those decisions you make have a huge impact here. One of the interesting things in healthcare is that, certainly if you're working financial or or aviation, God help you as well, might space would be even madder.
There's going to be a ton of formal regulations and compliance. And we spent a lot of time embracing this. Actually, one of the reasons why we were able to to kind of go through the exit we did is because we'd always try to do things to the book.
A lot of healthcare startups do everything they can to avoid this. And I'm sure many of you have heard about Theranos, that was the amount of times people have asked me about that. It is an absolute, it's nightmarish to deal with this. It's really like small companies find it very hard to do this kind of stuff.
But if there's one thing I need to emphasize to you about regulations is it's not a tick box exercise. It's a methodology, a process of how you build. And if you can get that right from the get go, it will pay dividends down the line, although it makes it very hard to build quickly.
When it comes to building robust systems, I used to spend a lot of time like beating the drum all about how we build safeguards into our system. How do we actually how do we stop people doing silly things? How do we pick up bad things happening and do that proactively?
Things like guarding input and output seem obvious, but it's really easy to forget that when you're building code. A system kind of needs to be constrained in how it operates. And we had so many issues that arose that no one ever foresaw, issues with hardware, whether it be a problem with a sensor and a system would get into a weird state.
And if we didn't pick that up, that's a really bad thing because no one really knows it's happening. So that's why having good telemetry and really kind of focusing on like what is it, what is the envelope in which the system should be working.
And so that really when we were moving quite quickly to try and get code out and ship features, gave us an insurance policy to solve problems and actually have the visibility of those problems to solve them quickly. So brings me kind of nicely to automation is the big word that everyone talks about, certainly in health care that there's so much manual stuff being done.
There's an interesting effect there that a lot of this manual work being done, the reason it's being done is because of of liability that you can hand it over to an algorithm and that's great. Everyone wants to do that. The problem is who's responsible that if something goes wrong.
So for instance, for us generating alarms that a patient is sick is great. You do that at four in the morning when there's no one on call to deal with that or that that person is one person for one hundred patients and you generate lots of alarms, then who's going to respond to that alarm?
And who's liable if that alarm doesn't get looked at until eleven am in the morning, the next day on the next review? You have to think quite carefully about how this is going to how this is all going to kind of come together.
And it sounds obvious then, well, why don't we just put a human in the loop to review this and that's great, put humans in the loop, it will work great. The problem at the moment you put human in the loop is that, again, you've just transferred the liability to someone and well, a, there has to be a human there ready to do that.
You know, in the case of healthcare, that human is then, you know, really still doing like the purposes of the system provider, it's just telling them like, here's a patient that's sick. Well, they kinda they kinda know that already because they're already doing the checking because it's now an adjunctive use.
And so there's some quite interesting issues that play out there. And that brings me quite nicely then to thinking about what is the workflow in which the systems we build being used. So, for what it's worth I think workflow is the single biggest influence in success for certainly enterprise systems in healthcare.
A lot of people don't think about workflow. I don't know a single medical professional out there who thinks that the software systems they use today actually serves what they do well. I just don't, I have never met someone that says I love, I love using electronic medical records. It just doesn't exist.
So we realized that you know, bad workflow is just yields low commitment and really just out low success. And trying to get on top of those pain points is actually really, really quite challenging. We put a lot of telemetry in our products and we still kind of use lot of telemetry not as much as we need to and we should do and we're still on a bit of a journey there.
Consumer tech using telemetry to kind of understand user behaviors is really common. It's quite difficult doing this enterprise scale because everyone's different and people are using system in different ways. So it's, there's not some kind of homogenous flow through the product. But one thing we realized is that observing real behaviors through that telemetry is usually very different to the feedback you're gonna be getting from focus groups.
Everyone to your face will tell you how great it is or they're kind of figuring it out. But it's the ten people that don't wanna turn up to the focus group and don't wanna talk to you are the ones that actually got a symptomatic of a bigger problem that no one's actually really kind of liking how the system works.
And the number of people I saw, I watch people on one occasion look at our system and transcribe on a bit of paper, the numbers from our screen onto a bit of paper so they could then photocopy and file it into a drawer somewhere.
And I I just I could not believe that this was apparently a totally normal thing to do. I just was speechless. And actually that led to a feature where you could print like a report of the data which seems really obvious. But the bar is so low in a lot of enterprise systems that people just don't wanna engage and just kind of ignore it.
Actually, we were able to kind of figure out like this was a surprisingly point of value. Like beyond the whole amazing monitoring, incredible figuring out sick patients. It was this stuff that people thought was like value. And that was just to me like spending my early career working on all these algorithm patents and building devices and all the rest of it.
But actually what people really viewed as value was not all the really smart interesting stuff, but just this obvious bit that saved them thirty seconds of their day to write down stuff on a bit of paper. So another thing that we spent a lot of time looking at in those early days as well was how do we match different workflows.
A lot of organizations are going for a lot of change. And so trying to move quickly in terms of letting them get up and running your solution with your solution then take them through that journey was really quite important. And so that changes is really, oh we're on.
What's happening? We've moved around. So incentives, something's been switched around. So incentives really here, people do what they're paid to do and it's kind of reduced very much to that. That's in healthcare is quite obvious in US healthcare and much less obvious in UK healthcare.
Often the customer in healthcare is not the user. So who's buying it will be some kind of exec. The reality is patients and healthcare professionals are so far extracted away from that. That it's that they have no real power to influence that and that really is where feedback is quite difficult to achieve.
One of the biggest things we did at Current Health was building this flywheel of collecting data and trying to now unlock some of that data to prove the value of our solution. So bear in mind, you've got all these people that are using this solution.
People that are trying to decide how do we save money in healthcare. Trying to prove out that they're either saving money or making money somewhere along the line or reduces the data. So one of the things that we still spend a lot of time trying to do now is collecting more and more data across our system at scale.
And so having that data there ready to analyze is really quite important to prove out this evidence of why people should use your system. For us in the NHS, very good at small scale pilots turning something from a pilot into a much larger project.
Longer term is really quite challenging. So that's really the change piece that kind of comes up there. Building systems that are malleable in the face of like big in our case home healthcare. What we built in the early days, we had to transform into this bigger kind of platform for home care beyond just the wearable.
And so actually the micro services we built suddenly started coming into a world of their own. And of the things we found around that is good software requirements actually really hard to get. So trying to do something and then kind of iterate that is really quite important.
Because big organizations are so slow to move, standalone products operation is important. Everyone wants to integrate and have everything that kind of it's in our case our platform would send data to their systems and it would manage all the workflow for them. And that's where we want to be.
One of the problems we had is that's just so hard because it turns out they're so slow moving as well. So having a system that can run by itself and is independent in that respect is actually really quite helpful. So that brings me quite nicely to finish.
I can hear people are finishing up now. This is really like only scratching the surface of some of the things we did at Current Health that worked well for us. The reality is every industry is different and every product is different. Like how people are using it, workflows, those organizations, the risk, the incentives, the complexity, all these things stack up in really quite different ways.
So yeah, I urge you as kind of builders and engineers. Go beyond kind of product management telling you what to build. Be thinking about how do your decisions in terms of structuring code and architecture and documenting some of that. How does all that come together in a way that builds something that's got, you know, opportunity to scale and you know, have a legacy and impact and do something great long term.
Thank you. I'm conscious of time.