In this episode, we will answer the following questions:

[01:12] software for home care companies to recruit and retain caregivers

[04:01] integrations, quick business adaptation and challenge overcomings

[07:21] how to transform customer requests into features

[14:08] in-house engineering team vs. third-party software development

[18:04] current obstacles in the development

[20:04] the story behind, features and development of sensor solution for the incontinent elderly tracks

[37:04] which kind of team brings better results in the startup stage

[42:51] how to become a good-skilled engineering manager

[43:41] Rapid Fire Round (3 questions)

 

Links:

Tim’s Linkedin: https://www.linkedin.com/in/timothyahong/?originalSubdomain=ca

Caribou website: https://www.caribou.care/

 

Listen to the episode on iTunes, SoundCloud, Spotify, YouTube, Google Podcasts and let us know what you think on the topic.

The mission of our podcast is to show the real-life challenges of implementing technology in healthcare and the podcast is sponsored by Demigos, a company that develops custom IT solutions for healthcare startups and companies.

My name is Ivan Dunskiy, your host as always, and today I'm joined by Tim Ahong. Tim is the CTO at Caribou. The company builds rewards and incentive programs for senior care companies. And previously, Tim was a co-founder of a company that was developing in continent sensors for nursing homes. And the company was acquired by Svenska Cellulosa Akti. If I pronounce it right. Also, Tim is an archery tag enthusiast. Tim, thank you for joining. How are you today?

Timothy Ahong: Hey, I'm good. Thanks, Ivan.

Ivan Dunskiy: Cool. So could you please tell us about your current company and which product services you create?

[01:12] software for home care companies to recruit and retain caregivers

Timothy Ahong: Sure. My current company is called Caribou and what we build is recruitment and retention software for home care agencies. So I guess the high-level problem we're trying to address is growing caregiver shortage in Canada and the US. This was a problem prior to COVID, but as a result of COVID, this problem has become even more severe where a lot of caregivers are leaving the industry. So we set out to build a company that would hopefully address that problem or at least, maybe, work on it a little bit.

And our focus right now is home care agencies which will hire caregivers that will go into the homes of individuals who need support, typically seniors, and offer various caregiving services. So we build software for home care companies that help them recruit caregivers and retain caregivers. This includes referral and incentive programs, and also change management systems. We help them set up those programs for their organizations.

Ivan Dunskiy: So with the help of your programs, home care companies can recruit more efficiently.

Timothy Ahong: They can recruit more efficiently and hopefully they can retain staff. We try to lean on referral-based recruitment. People are much more likely to stay at a company if they've been referred, or if they're working with people who they have an existing relationship with. We also work on long-term retention incentives, trying to help the home care agencies, at least give them a channel to appreciate their staff and show that they recognize, the impact that their staff are making and also give them a channel to give back to their staff in ways that are applicable to all of the local laws and union rules.

Ivan Dunskiy: And I assume you also have some loyalty programs you offer?

Timothy Ahong: Yes. A lot of our customers use our loyalty programs as well. 

Ivan Dunskiy: And what role does technology play in your company? 

Timothy Ahong: The technology that we build is primarily, it is a hundred percent software right now. And we'll build a couple of core components of software that for the most part have to be configured to the individual operations of the healthcare organization that we're working with. So we build systems that will integrate with their employee management software and their payroll processing. We'll build the actual incentive programs, which may involve pulling data from a number of other healthcare-related systems. 

One example which has become really popular in the US is electronic visit verification. Caregivers have to clock in and clock out a visit and then the home care agency can apply for funding and receive some funding from the government body and that's a bit of a change management process. 

So we'll hook into that system and create incentive programs around compliance. And then also we have a technology system that exposes the reward information to the actual employees and the caregivers. So they can go on, like you mentioned, like the loyalty program they can check their points, see what other incentives the agency is running as well.

[04:01] integrations, quick business adaptation and challenge overcomings

Ivan Dunskiy: I assume you have some challenges with different integrations, right?

Timothy Ahong: Yes. Integrations is a challenge. I would also say another challenge that, it's a bit unique. The challenge isn't necessarily, it's not like a technological R&D project. I wouldn't say we have a large amount of technology risk, but this business does have, a large amount of product risk. 

So our main challenge isn't overcoming a technical hurdle. It's mostly being able to adapt quickly to a changing market. Things change drastically at the start of the pandemic and are still changing as a result of the pandemic evolves and changes over time and its impact on home care has been quite substential. 

Our main challenge is trying to adapt really quickly. For example, this business pivoted about a year ago into this business area. And we've had fairly substantial changes. I would say maybe every four months, as a result of the pandemic. 

So on the technology side, the challenge has been mostly like trying to move quickly, but also remain flexible and anticipate what changes we may encounter in the future. So we don't end up with a large amount of technical debt. 

Ivan Dunskiy: And these changes are there mostly related with change in regulations? 

Timothy Ahong: I wouldn't say it's not necessarily regulatory. I think there were some regulation changes that happened pre-pandemic. For example, electronic visit verification became necessary in the United States. 

There are some pandemic-related changes, for example, uploading vaccine status has is a requirement, which we've looked into. But the changes are more I would say the most substantial changes have been market dynamics. Home care in particular, is always this balancing act of having the right amount of clients. So the right amount of, let's just say, seniors who need care and the right amount of caregivers to deliver that care. And this is a balancing act that home care agencies have always had to manage. As a result of COVID, the balance has shifted heavily towards a deficiency in the number of caregivers available, and the best ways to recruit and retain caregivers has changed over time. So it's keeping an eye on those market dynamics and ensuring that we're always in the right place to deliver, to deliver value to the customers.

Ivan Dunskiy: And what is your way how you check these changes and how you keep your eye on them? 

Timothy Ahong: This, I guess, does relate to our product development process a little bit. Because we're software, we have the luxury of being able to have very short development cycles on like a future versus if this were a hardware business, this just wouldn't be possible. 

But because we are software, we try not to plan too far in advance. We'll keep it maybe one month or two months in advance. We try to keep quite a tight loop on input that we're hearing from the market. So that could be from customer success who's working with the home care agencies and also sales who's talking to new customers and ensuring that we have our ear to the ground on what problems they're facing what they're asking for or if anything, shifts on their end, in terms of like, let's just say there's some mark shift in market dynamics and I don't know, a new source of funding opens up for caregivers. That would be an opportunity that we would wanna react very quickly on to be able to help them, I don't know, collect or deliver that new funding model.

[07:21] how to transform customer requests into features

Ivan Dunskiy: Can you elaborate a little bit more on that? How specifically you get that feedback? Let's imagine we have sales for customer support, especially. So how do they gather that feedback? Do they have a backlog? How do they make priorities on that? How do they say to a product team what is important, and what is not? How does that happen?

Timothy Ahong: So, our customer success team does have regular touchpoints with the customers. And for the large ones they're meeting with them on a weekly or biweekly basis at least during the initial phases of the project and maybe it tapers off to monthly later on. And during those meetings, they'll try to get input on like what other challenges they're facing that they think we could contribute to. Or if they have any specific things that they would like if it's not just a problem for them, if they've already come up with a solution, they'll collect that input.

And then we do have essentially, it's like a channel for customer success and operations to communicate feedback to the product team. It's in the form of like periodic meetings where we'll collect that input and synthesize it into a series of features or product initiatives. Similarly, with sales, this one is a bit less, it's not as formally structured, but when sales are out there if they'll hear about, let's say a competitor with a new feature or when they're trying to close a deal and try to understand how we can solve the customer's problems. 

If there's a problem that has been raised that we can't currently solve, what we've been doing is we have someone from a product, usually myself, join the sales call and do a needs discovery with the customer before the deal is closed to determine if we can solve this problem. 

And if we were to develop a solution to this problem, would it be in line with our strategy, our company strategy. And if it is, then that gets rolled in as part of the as part of the sales process where we will actually start the development of that feature for that one customer, close the deal, roll it out with them. And then assuming we did our homework correctly, that product change or that feature would also be applicable to other customers. Does that answer the question? 

Ivan Dunskiy: Yes. So basically, you are making decisions on how to transform this request into features, right?

Timothy Ahong: Yes. 

Ivan Dunskiy: Got it. Do you think that is possible that somebody else from your team, for example, a product manager, can do that instead of you?

Timothy Ahong: And I think that's the goal. At least with the current market dynamic there are not a lot of competitors in the space, or the competitors that do exist, have prerequisites. It's like existing large players in the space who are building these types of incentive programs as an add-on to their existing features. 

So the way things are set up right now is a customer way to come up with a problem. And there's not a lot of good solutions out there. So, in this circumstance, I think, it is appropriate for product managers to be involved very early on in the sales cycle. And the customers are very willing to have someone work on this problem with them. So normally in a sales situation like this, I don't think the customers would be as willing to go through the needs discovery process. For example, before a deal has been but because these problems that are arising are very new and the market hasn't reacted to it. 

There's not a lot of competitors which is like if some dynamic shifted and then the problem has only existed for two weeks, it's quite reasonable that there would be no competitors and they have a high demand for a solution. They're definitely motivated to work on a solution with us. I think the goal in this current climate product managers could be involved in the sales cycle quite early on. 

Ivan Dunskiy: And maybe you can share your vision, how you can educate product managers to understand and capture and differentiate what is important, and what is not because as you a CTO, you understand both the worlds, technical and the customer worlds. So how can you educate product managers who can not see as good as you?

Timothy Ahong: I think something that we have to be careful of is not offering just like consultancy services to solve a problem that is specific to this one healthcare organization. Because our fee structure isn't set up to do that. And honestly, they could go and hire some consulting firm to do that. It probably wouldn't be worth it unless the healthcare organization was very, very large. 

So I think, as a product manager who is focused on one area of the product or is focused on driving some success metric, would probably without any external input be the best person to solve that problem for that agency. But I think the one element of external input that a product manager might need outside of their team is determining whether or not a solution to a problem is in line with the company's strategy.

So that I think comes from, which is why it's important, that like I attend a number of these meetings with potential customers is to get an idea of where the market is going and what types of features would be on or off the roadmap.

And then, I guess, the advice to a product manager would be ensuring that they have access to that information when making a decision about which problems to solve, versus which problems to maybe say: “Hey, that's a little bit too far out of our wheelhouse, and perhaps there's a different partner who would be better at solving that problem than us.”

Ivan Dunskiy: So then turn on this plausible solution with you. 

Timothy Ahong: Ideally they wouldn't. I mean, we haven't reached a point where that's like a problem for us, but ideally, they would be able to make that decision on their own. But then there would be some type of feedback process for like confirmation after the fact. Because I wouldn't wanna be a blocker in the process of them deciding: "Okay, let's go and build it." Cause especially if this is pre-closing the deal. So ideally, they would have this framework, they'd have this structure to review either while the meeting's happening or right after the meeting to determine whether or not “Okay, this is on strategy. Here are the next steps. We're gonna go for it.” Versus having to have this checkpoint, that involves me as like a now critical path person on the process, which involves closing a deal. Ideally, they can make that decision independently. I wouldn't say I have a full solution for that, but I think that that's what I would wanna strive for.

Ivan Dunskiy: Understood. And could you tell us about your current engineering team?

[14:08] in-house engineering team vs. third-party software development 

Timothy Ahong: Sure. Our current engineering team is in-house. It is a fully remote in-house team, though. We have like two people in the Philippines, and then people spread out across Canada, which is pretty cool. We did start with a third-party app and backend development company, and around the time or shortly before we pivoted, we switched to an internal team. 

Ivan Dunskiy: Why did you make that decision?

Timothy Ahong: That decision was made mostly because I think, number one, the volume of development was ramping up, and number two, we realized that like how quickly we'd have to move to properly capitalize on this market opportunity. And when the product vision felt a little bit more secure in the sense that if we hired these individuals and built out the internal team, our path wouldn't change enough that that team would not be the right solution going forward. Whereas before, we weren't quite sure and the product vision kept changing. And it was like in a very iterative stage of the business once things settled, then we decided to make the switch to internal.

Ivan Dunskiy: And did it work well for you?

Timothy Ahong: It's worked well. I'm happy with it. I think a large part of that is because like our current engineering team is really great. We had some really strong references, and our lead engineers are amazing. Our first engineer hire is amazing, our designer was a referral. So it's been really good. But also I really liked our third-party software development company from before. Like I'd worked with them before which is why they were providing services to this company initially.

Ivan Dunskiy: Are they from Canada? 

Timothy Ahong: Yes. They're from Canada as well. Actually from Toronto specifically. The time when I worked with them prior to being co-located in the same city was important less important now. As a result of work remote probably. So I've been happy with the internal team decision. And I think like it based on where we are right now and the challenges we're facing, I think it does make sense for us to have an internal team, but also like, and perhaps this is maybe better suited for a different question, but I've been seeing like a lot of companies using third-party developers, and being quite successful with that. Mostly in response to like rising software engineer salaries. In Toronto, it's exploded. I think, obviously, in San Francisco it's been high for a while, but, other cities didn't experience the same salary increase until perhaps the last, I don't know, three years or so. I've seen a lot of companies be successful using third-party services for quite a while, actually.

Ivan Dunskiy: And how was the transition from the third party to internal? 

Timothy Ahong: It wasn't so hard, I think because the teams were relatively small, like it was initially, we had hired it was myself and one, our lead engineer. And then on the third-party side, I think they had maybe two individuals on the engineering team. So we were able to migrate relatively seamlessly where we ran both processes and parallel for a little bit. It was maybe like two sprints worth of development and then transitioned over to our internal process. 

And we did retain some of the resources from the third party, from the third party supplier for a little while, and ran them both in parallel. The transition was relatively smooth I think that it is a small team definitely made it easier. If it were a larger team what I probably would've wanted to do would be run both teams in parallel for a bit longer, and then slowly taper off the third-party team just to and then maintain maybe some of the people who had more experience with that code base, keep them on a retainer for a little bit and have them participate in perhaps like sprint and ticket planning and just be available if something happened, maybe they're doing PR reviews or something like that.

I think it would've been a lengthier process if the team was larger, but because it was so small, it was relatively smooth.

[18:04] current obstacles in the development

Ivan Dunskiy: It sounds good. Sounds reasonable approach. And what are the current obstacles you face in the development?

Timothy Ahong: Yes, with this business, there's not a whole lot of challenges that I would say are where, the question is, can the technology do it, or we have to overcome some massive technical hurdle and it's gonna take like six months of R&D to do it. That's not our challenge right now. Our challenge is trying to stay on top of market trends, which means number one, keeping areas to the ground and keeping being very close to the customers and having an idea of what's happening in the market. 

And then being able to react very quickly to that and translate those insights into products or features. 

And the technology challenge is number one is, I guess it's at a high level is speed. Like that would be the main metric would be how quickly we can iterate and how quickly we can adapt. But with that comes, how do we avoid technical debt? And how do we avoid building products and features that the market doesn't need a month from now? So we have a large portion of the credit is from our lead engineer who does a really good job of managing technical debt, and also we've built a number of tools that allow us to experiment with features or products which is like propped up by like operations.

So it is manual on our end, but it looks like a fully formed, automated product to the customer and to the end users and allows us to run these experiments because things change so quickly. We can spin up one of these experiments and maybe it takes a little bit of development and a moderate amount of manual effort to set up. But allows test the feature really quickly. And then if it doesn't work, or if things change in that feature becomes not important one or two months from now, we can either decommission it or if it becomes important, then we can build a robust feature. I would say those are the two things that we're challenged with right now on the technology side.

[20:04] the story behind, features and development of sensor solution for the incontinent elderly tracks

Ivan Dunskiy: Cool. Let's talk about your previous company, so I assume that it was more technically difficult to build a product. If you can elaborate more on that experience and how you approached the development, how did you build the development team then?

Timothy Ahong: Yes. The previous company was called Sensassure and we were building a sensor for nursing homes so the sensor was designed to attach to an adult in continent product. Just a little bit of background in nursing homes in Canada and the US. I think just a slight majority of the residents of those nursing homes are incontinent. So they can't fully control when they go to the bathroom. And as a result, they have to wear a brief or an incontinence product or an adult diaper. 

And standard process in most of North America is to periodically check the briefs to see if they're wet. And if they're wet, they change the brief for a dry one. In some places it's supposed to be every two hours, which includes overnight and as you can imagine being woken up every two hours to have someone pull your pants down and check your brief would be very disruptive. So what we thought. What help is a sensor that could attach to the outside of the brief and determine if the brief was wet or not wet. And this would allow for two things. One is if the brief was dry then the caregivers don't have to wake people up every couple of hours. If the brief is dry you can perhaps just go in, check up on the resident, make sure they're okay, but you don't have to turn the lights on. You don't have to pull their pants down and check on the brief. So you can get to improved quality of sleep.

And the second value that we thought would come from the sensor is if an individual has been wet for a while, caregivers could decide to prioritize changing that individual, if someone is wet for maybe two hours or so, they would they would potentially have been changed earlier than that. So they wouldn't have to be exposed to moisture for such a long period of time which for results in improved skin quality. So the technology involved in this project I would say this project was definitely less focused on like changing market trends and was more focused on solving this problem of can we detect the presence of urine in a brief from the outside of the brief reliably. And that was like our big technical hurdle. The product involved a couple components, it had a sensor which attached to the brief. That sensor had to talk to we had these like wireless internet gateways that we installed in the nursing home, it had to talk to those wireless gateways, those wireless gateway sensor data to a server.

Ivan Dunskiy: Via Bluetooth? 

Timothy Ahong: No, we did use Bluetooth for some of the versions and then at one point we decided to use a technology called Laura. Which is a low-frequency, long-range communication protocol. I don't know how popular it is these days, but we had made that decision prior to the most recent version of Bluetooth the long-range Bluetooth. So had we been like working on the product a year or two later? We probably would've decided to use like the long-range version of Bluetooth, which came out halfway through one of our later development cycles. So it would've been great if that was available at the time, but maybe that's what they're using now on the project. I don't know if it would probably be the right decision just because it's so popular and so accessible. But yes, it was like an IoT device connected to a server. And then we also had a mobile app that the caregivers would use to determine the status of the briefs of the residents.

Ivan Dunskiy: And maybe you also had some web panel for facility administrators.

Timothy Ahong: We had an administrator dashboard that showed them high-level analytics and also it would escalate notifications to that platform. Usually in nursing homes, you would have the majority of staff, especially overnight are caregivers. They're going in, they're checking up on residents, but usually nursing homes will have at least one, nurse on staff at all times I think in Canada, they have to, who would be able to access the administrator dashboard. 

Ivan Dunskiy: And how do you approach the development of the device and the whole technology?

Timothy Ahong: This was a very different process from our current business.  With that business we did some initial validation studies to confirm that were people willing to pay for this product specifically, were nursing homes willing to pay for this product and how much were they willing to pay? 

And our initial sensor was technically a lot simpler. It was just a conductive sensor that would go inside of the brief and detecting through conduction. The presence of urine is quite easy because for the most part, urine is not distilled water. So at it's conductive. We would have these disposable sensors that went on the inside of the brief and would detect when they were saturated. We did our very first validation pilot with this system which was very MVP. It worked, but also the technology hurdle was much lower, cause connectivity is was pretty reliable and then we found out that nursing homes were not willing to pay enough in order to justify the cost of a disposable sensor. 

So at that point, we realized either we have to come up with a way to drastically reduce the cost of the sensor, the cost per use of the sensor or this business is not gonna work. So the path we went down was to try to make the sensor reusable and the way to do that was to put the sensor on the outside. So the journey of this company, I guess, involved a back-and-forth series of iterations, where we would do like research and development type iterations on trying to build a better sensor that could remotely detect the presence of urine. And then once we got to a certain point where we felt that the sensor was gonna be good enough to add value, we would then build enough of a product around that sensor to run a clinical trial and test in a real nursing home and then assess is this accuracy good enough? Is the product usable? Is it durable? Can it be cleaned? What other issues are coming out of the clinical trial? And then we would take the results of that. 

Go back, do a series of R&D iterations on trying to solve some of these problems, improve accuracy, improve durability, make it easier to apply and remove from the brief and then go back into a clinical trial and we went back and forth between these two high-level challenges, like the product challenge, which I think exists with almost every business and then the technology R&D challenge, which was unique to this business.

Ivan Dunskiy: It's a really cool story. And could you tell about the market resource you made? How did you make it? Did you hire a specific company to do that? Or what was the approach?

Timothy Ahong: No, it was brute force. I did not participate in this, but I did see it happen. So at the time our CEO and our CPO went and this was like we were all fairly early on in our careers at this time, and we didn't have like established networks and senior care. So it was just like brute force, like cold calling at one point we set up this road trip and we met with, it had to have been at least like 20 different nursing homes throughout the US. And we went on this road trip and met with them, talked through their challenges around incontinence and pitched them on the idea to try and find nursing home who were interested and gauge interest in the market. A lot of cold calling to get that set up which is kudos to the CEO and CTO who set that up. That was huge for our business. And then once we had enough interested partners, we built a very rough MVP, we built the conductive.

Ivan Dunskiy: But wait, when you talked with them how did you validate they are willing to pay and how much?

Timothy Ahong: This was a balancing act. Initially we had to validate that this was a problem for them and usually like we would go in and we would ask them, like, what are some of your, your biggest operational challenges and common responses are incontinence management is like always at the top. Feeding is also up there. That was at the time which was way before COVID. 

I bet if we were to go around and ask them now, like staff shortages would probably be number one, but at the time, like incontinence management and feeding were like two big ones. So, then we would decide to focus on incontinence management and specifically what the challenges were and if they were in a place where they felt like incontinence management was a challenge, and they felt like maybe they were using too many briefs, maybe residents had poor sleep, quality families were complaining about residents being sit like residents, sitting in saturated briefs for a really long time. We went down that line of questioning to validate whether or not the problem existed, and then if that was the case, then we could pitch them on the solution and say: “Hey, here's what we're thinking of a solution. Would you be willing to pilot it? Would you be willing to pay for it?”

The problem that we encountered on the road trip and with our early validation was that nursing homes were unable to really determine how much they were willing to pay for it, because nothing like this existed before. And there were no like white papers, there was no research on how these results in cost savings actually result in improve skin quality. That's really hard to prove or improve sleep quality, which is even harder to prove, but there was no existing research, so it was really hard to actually get a number in those initial meetings. So in order to do that, we had to start running clinical trials to try to get, we will reduce incontinence associated dermatitis by, I don't know, 20% like, there was no way we were gonna get that, but we could get like, we can reduce the amount of time residents spent sitting in a saturated brief by 50% and we can reduce unnecessary sleep interruptions also by 50% and then we found that as a result.

Ivan Dunskiy: How did you come up with those numbers?

Timothy Ahong: That was from our clinical trials. We would do like a baseline and we would monitor passively and then we would in do an intervention and then observe the effects. We had to do that. And before we could even get willingness to pay which was very expensive, but we didn't really have any other options cause the data wasn't out there. So we had to make it.

Ivan Dunskiy: It's a way how to find, define the blue ocean. 

Timothy Ahong: And in a sense, we did get a little bit lucky cause it is possible that like there were a lot of things where it is possible that for example, a sensor couldn't be built that could detect urine inside the brief reliably. And it's possible that like, even if we could do that just from a workflow perspective, like that, it adds no value and we actually found like one example is originally the product was meant to be used 24/7 around the clock but we actually found that during the daytime, the product added no value because the caregivers had no time to change. 

Giving them information about who was, which residents were sitting in wet briefs and which residents were sitting in drive briefs didn't impact their decision to actually change the briefs like the existing workflow couldn't make use of that information. So we eventually then just decided that the product will only be used during the nighttime because that's the only time it adds value. So it was also possible that that was the case around the clock and the product would add no value and we had to go. At the time, we didn't anticipate these risks, but I think these risks did exist and we had to go in and like run the trials and figure it out like despite those risks potentially existing. I think it was a combination, we did get a bit lucky a couple times there. 

Ivan Dunskiy: Yes, luck is definitely a factor in all the entrepreneurial journey. 

Timothy Ahong: For sure.

 Ivan Dunskiy: So how did you develop the device?

Timothy Ahong: So, the device we went through, was maybe four product iterations, and yes, it was a very multidisciplinary team. We had electronics engineering. We had industrial design, mechanical engineering firm. 

Ivan Dunskiy: They were part of the founding team?

Timothy Ahong: No. So the founding team was just CEO, CPO and myself CTO and internal team. We did hire a verification engineer who did like product verification and also helped out with R&D and then we also had a medical device consultant who had experience building similar sensors to the sensor that we ended up using for this product. He wasn't full-time internal. He was a third-party, external consultant, but he was with us for the entire journey and then other than that, it was all external, engineering resources. Electrical engineer, firmware mechanical, industrial design app development, server development.

Ivan Dunskiy: This whole, they were all like different vendors.

Timothy Ahong: It was all different vendors as well. We did get some quotes from like a turnkey development shop that did everything, and I think the way that we wanted to do development didn't really fit with the way that a lot of these turnkey shops do development, where I think that. Typical like customer profile is someone who has an idea of the product that they want and has a relatively high degree of validation. And they're gonna build you a really good polished finished product. That's gonna be good, you could transition it to manufacturing. If your clinicals go well, you can get all your certifications which is not what we needed at that time. 

We needed to be a little bit scrappy. We needed something that was gonna meet the minimum requirements for like safety and functionality so that we could actually run the trial in a safe way and get good data out of it, but we didn't need any more than that. So that's why we opted to go with a mix of individual contractors and third-party contractors. And yes, I will say one thing though, to note which is important because normally that, like, just as I'm saying it sounds like a nightmare. It's putting a lot of burden on the internal team to manage all of these different vendors. Which it is.

So I will put a caveat yet, and maybe that's not the right approach for most businesses because it's so much work. But something that was unique about this situation is a lot of the engineers that we hired had worked before together at various companies. So we'd gotten a lot of referrals to construct this team. And the electronics engineer had worked with the mechanical engineer, who worked the firmware engineer. They'd all worked together at companies in the past. And then they had split off and created their own companies, which with their own individual specializations, so they had an existing working relationship. They knew where responsibility boundaries were. So that definitely made management a lot easier. Without that preexisting dynamic I don't know if it would've been the right choice, to be honest.

Ivan Dunskiy: So you've got one referral, and then they referred you to other folks. 

Timothy Ahong: Like who have you worked with before? Who's like, so this person let's say the electronics engineers. Who have you worked with before? Who does mechanical? And then who have you worked before? Who does firmware? Who is good and stuff like that. And then we assembled the team.

Ivan Dunskiy: That was luck as well, right? 

Timothy Ahong: For sure, cause that could have gone poorly. It was a lot of internal overhead to manage, I think multiple third party multiple third parties, but it could have been easily like five times as much work if they hadn't worked together before, they hadn't had that existing relationship.

Ivan Dunskiy: Time and money, though, as well.

Timothy Ahong: Yes.

Ivan Dunskiy: Cool, and did you also switch to the internal team when you built that product?

Timothy Ahong: We did not. That product stayed external for until we sold the company and even after selling. 

Ivan Dunskiy: You did the company for two years.

Timothy Ahong: Two years prior to selling it and yes, the team remained external the whole time. And I think that for that business, it was the right decision. We had this because we had this awkward back and forth between R&D cycles building an MVP, running a clinical trial and then processing the feedback we had. 

Periods of time, where we needed a lot of engineering support and periods of time where we didn't need much engineering support and using external services allowed us to scale our engineering team up and down, based on our needs. I think it was probably about maybe a third of the time we were in clinical trials and didn't require much engineering support and it saved us a lot of cost being able to have that flexibility. That was one thing. 

And another thing is because the areas of expertise were so diverse I don't think we necessarily needed to hire, let's say like an expert full-time, but by using a third-party software development company, they could bring in someone on their team who had IOT experience for maybe 15 hours and then the rest of the development could be maybe a junior developer or someone who's more cost-effective. So we were able to benefit from that because we did have such diverse requirements on the technical side. And for those two reasons, I think it was the right. It was definitely the right decision to go with external for the majority of the technical area.

[37:04] which kind of team brings better results in the startup stage

Ivan Dunskiy: Cool. And it seems that you have two options for how startups can organize their teams with internal team and third-party vendors. So what is your vision in what ways should startups choose an internal way or a third-party way?

Timothy Ahong: I think I can think of a couple of examples from like my previous business censure. I think something that was important to keep internal was the R&D like a large portion of the value of our company. When we sold it was the IP portfolio that we developed and most of the R&D was being completed by myself, our verification engineer who was full-time and our medical device consultant, who was external, but he had a retainer and was with us the whole time. 

So I think that was important to keep internal because if that was controlled by another business, it would've been, I think, difficult for us to really like add value. Post-acquisition when we're really fleshing out that IP portfolio. So I would say that is probably important to keep internal on the external side, a couple of I could see like justifications for going external. A big one would be, yes. If you anticipate fluctuating demands, which could be because you have a long clinical trial cycle or you have a long validation cycle, like in a hardware business. But also, I've been seeing this happen more frequently now is like, if a company is very early stage in trying to experiment with different product offerings and trying to like iterate really quickly to find product market fit I could totally see an external partner making sense in that circumstance. And a lot of people were turning to that, like as a result of software development, salaries becoming really high at least in Toronto, where you can go with an external shop, do your iteration really quickly, and then it allows you to adapt, I think, faster than if you had hired internal employees, because it's possible that the expertise that you need changes and once you've built a team, it's difficult to change your area of expertise.

Ivan Dunskiy: It's not, and you can, what you have.

Timothy Ahong: Yes, and I guess you could restructure your whole team or if your company's growing, you can just like grow in the direction you need to go, but you also face a lot of conflict, trying to make that decision. Because you're geared up for one thing. It's really hard to deviate from that path. 

But if you have a third party with an understanding that things might change. And they have a whole bunch of, areas of expertise internally. It allows you to shift around and be really flexible to where the product needs to go. So I think if you anticipate that and you're gonna be iterating really quickly, I could totally see that being like the preferred option. It also allows you toget started a little bit faster. If you perhaps, maybe a full-time, maybe you don't need a full-time engineer. You can go third-party start really small. It's not even a full-time person, maybe it's 20 hours a week or something for your initial validation and then build from there and in the early stages of a company if you're having discovery calls with the customer and then you wanna test something out and then maybe it doesn't work and then you put it on pause and you come back and test something else out. Once you have another customer, the speed, the difference of like a couple weeks or even one week, I think makes a big difference if you're trying to iterate really quickly. And if you have a third party on deck, you can spin up and spin down. I think a bit faster than trying to hire, hire a full time which commits you to a path, a little. 

Ivan Dunskiy: And what tips can you give to product companies who want to hire a third-party engineering team?

Timothy Ahong: For myself, I think something that's been very important is hiring a team with aligned values in my industry, at least in senior care. Senior care technology isn't the most popular for startups and it's typically like a relatively underfunded industry, I would say. So I find that the people working in this industry tend to have reasons why they wanna be in this industry. There's something motivating about being in this industry for them, and I think that was huge for us. For both businesses.

Ivan Dunskiy: And you have to have some internal motivation to work specifically in that.

Timothy Ahong: And I think there are two reasons why that's important. Number one is for me - I find that more motivating and I know that a number of people on my teams have found that motivating, which is when they're working with someone who's also mission driven that could the supplies for internal employees and third parties.

And number two, especially when managing. When we were in that scenario where we had all these different third-party companies, and trying to manage all of them, at some point you're gonna have conflicts between individuals and someone's gonna say: “Hey, it's this person messed up this thing and that's why it's not working”, and then that person says: “Hey, this person messed up this thing and that's why it's not working, and when people are all aligned for the same mission, it's really easy to bring everyone back to like a central goal.” 

Like you have a common place, you can come back to and say: “Hey, this is the goal we're trying to incontinence associated dermatitis or something and it's not about pointing fingers”. It's about what the solutions are from where we are right now to where we need to be it just made those types of discussions, really easy to have one, that everyone has that common ground.

Ivan Dunskiy: So your role as product owner to get everybody together to follow one direction, one mission rather than concentrate on some internal conflicts.

Timothy Ahong: And it was really helpful ensuring that or when everyone had the same common motivation, it made that job much easier.

[42:51] how to become a good-skilled engineering manager

Ivan Dunskiy: And we are coming to the end of the interview. And my last question would be in this series. What advice can you give to those who want to become a good skilled engineer manager? 

Timothy Ahong: I think something that's always been really important for me. I was thrown into that role as a result of the first company Sensassure and something that was very important was having a good mentor. 

Our medical device consultant ensured that we took all the right steps and our decision process was the right decision process, and that I was doing the right things to manage this team. I think that's number one is having a mentor who has the skills but is also there to support you through the process, which I would say the single most important thing from my journey.

[43:41] Rapid Fire Round (3 questions)

Ivan Dunskiy: And I would like to end this interview as always with the light exercise called rapid fire round. I will ask you several questions and you can give answers whatever you come up with.

Timothy Ahong: All right. Sure. 

Ivan Dunskiy: So what is the latest movie that impressed you the most? 

Timothy Ahong: The latest movie, I watched this short, it's a series of short films called “Love, death and robots.” And then there's this one short film called “Jabbar” which it really impressed me. I've never seen anything like this. It is a little bit uncomfortable to watch and it is like you don't wanna watch it with children but it was they combined like 3D animation and motion capture and also I think some 2D animation created like a really unique, visual experience. It's short film. It's like five minutes long.

Ivan Dunskiy: I saw that as well so yes, the most impression few was in visual effects, right?

Timothy Ahong: And the storytelling, I felt like the storytelling was really good and they had like the dancers, I don't know if it was motion capture or how they did it, but the dancing just seemed like really realistic. It was also looked like it was 3D animated. I like that one. 

Ivan Dunskiy: As far as I remember, that was without any words. 

Timothy Ahong: Yes, no words. 

Ivan Dunskiy: What is the location that impressed you the most? 

Timothy Ahong: Location. Somewhere that I've been recently. 

So I don't know if this is 100%. It was public transit in Japan. So, I mean, I live in Toronto and we have a public transit system but what I found in the public transit system in Japan was like, when I was riding the train there, it felt like everyone on the train was working together to make the public transit run smoothly. Whereas in Toronto, it's like every person for themselves. People are rushing to get off rushing to get in. Whereas in Japan, I was on this train and it was like before the train stopped, people had taken their bags over the overhead storage and they were ready to go. And as soon as the doors opened, people waiting to come on, were off to the sides. People in the train like got out and the people waiting to come in got in, it was super quick. It was super efficient. It was just like…

Ivan Dunskiy: One organism.

Timothy Ahong: Exactly. It's like everyone was operating on the same wavelength and like working together and it actually felt good. Like you're a part of this team, like making the public transit run smoothly. And then I come back to Toronto and it's like everyone is rushing. People are charging, trying to get into the doors. It's not as fun.

Ivan Dunskiy: It's quite odd for an individualistic society, right? 

Timothy Ahong: Yes. 

Ivan Dunskiy: And what is one piece of advice you can, you would give to your 20-year-old self?

Timothy Ahong: This one is hard because it's something I don't regret, but I would never want to experience again, which was with my first business. I think, a lot of entrepreneurs probably struggle with this is like I really associated my self-worth with the business. I think it's like a common entrepreneur problem. And I wasn't happy for a large portion of that journey. I think I've overcome that, and I've learned to do a better job of separating things but yes, I wasn't happy. So I would say that that would probably be something that I would tell my past self, but also, I don't regret it because I think I grew a lot through that experience and I've partially become who I am today as a result of having gone through that. So it'd be something around that, I think. 

Ivan Dunskiy: So do you mean that to keep that balance that the business is a separate entity. That is not you, right?

Timothy Ahong: I think some degree of like association with self-worth is always gonna happen with a business like that. It takes up so much of your time. Just naturally that'll happen. But having at least a diverse set of interests and areas where I am spending time and spending focus. So it's not a hundred percent business. You have other things that can occupy your mind and other things that can occupy your focus other than the business. Cause for me, it was like a singular focus, which was not very good for my mental health. 

Ivan Dunskiy: Understood. Thank you for sharing, Tim. A lot of insights about building development teams and sharing your diverse experience of how you did it. Thank you for sharing so much with us. Before we finish, what is the best way to get in touch with you if somebody will want?

Timothy Ahong: I guess you could message me on LinkedIn. If anyone has any questions about anything, if there's any that they think I could help. You could find me on LinkedIn that I guess you could search my name, Timothy Ahong. I don't think there's any other Timothy Ahong on LinkedIn.

Ivan Dunskiy: I think I'm confident that that would recognize you. Thank you, Tim. Thank you, listeners. And we will catch up in next episodes.

Timothy Ahong: All right. Thanks Ivan.

Who is behind the HealthTech Beat podcast

We are a team of IT professionals who like sharing technical knowledge with healthcare industry people.

At Demigos, we generate ideas on how to improve product performance, design, and positioning based on our experience building complex health tech solutions.

Check our blog with articles on the related topics, and our cases in healthtech. Also, connect the podcast host and the CEO of Demigos Ivan Dunskiy on Linkedin.