In this episode, we will answer the following questions:

01:32 mPulse and future products with NLP

06:42 convincing people to use your product without convincing

11:43 introducing tech products to people in healthcare 

17:03 presenting data in more meaningful ways as a primary focus

19:44 high-quality solution creation, a balance between innovations, staff hiring, and the other challenges in tech development

25:26 overcoming a shortage of engineers - how important the mission and purpose of a company to avoid it

29:38 if there is no role, we will create it for you

35:39 how mPulse chooses tasks and measures engineering teams’ productivity

45:12 Elon Musk statement discussion - must technical managers be technically excellent

51:41 how good the engineer should be at the leadership

54:48 Rapid Fire Round (3 questions)

 

Links:

Ram’s email: ram@mpulsemobile.com

Ram’s LinkedIn: https://www.linkedin.com/in/ram-prayaga-400aa51/

mPulse Mobile website: https://mpulsemobile.com/

 

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. The podcast is sponsored by Demigos, a company that develops IT solutions for healthcare startups and companies.

Ivan Dunskiy: I'm joined today by an honored guest Ram Prayaga. Ram is the outgoing CTO of mPulse Mobile - a company he helped found and built into a 250-person organization. In 2013, mPulse had a handful of clients.

And now they are an industry leader engaging over 100 million members. They closed three acquisitions and recently closed a large private equity investment. In his role, Ram has led the engineering product and compliance teams working with local and offshore teams. And he's proud of the positive impact, and company technology is having on millions of lives. Ram, thank you for joining. How are you today? 

Ram Prayaga: I'm doing well and thanks for having me and yeah. Looking forward to this conversation. 

[01:32] mPulse and future products with NLP

Ivan Dunskiy: Yeah. Could you please tell us about mPulse? And it seems that you achieved significant results and I'm curious to learn more about the company and its future products.

Ram Prayaga: Yeah, obviously that's something I'm very excited about. It's been an amazing journey for us. When we started this a while back, I think some of the main features, if you will, of the organization is really just one our technology served both in the platform space how can clients build things on top of our platform as well as building solutions.

So we took a step toward that. And more recently I've gone into more of the solution space. What I mean by that is our platform is primarily allowing clients to do health engagement, how do you reach members about their appointments. Reminding them to get their screenings, reminding them to go for exercise, check their weight, whatever the engagement may be that our clients wanted to use our platform to outreach about, we will support that.

Over time, we understood that based on some of the criteria, on some of the requirements of really true positive engagement where you're not just sending a message and hoping that you'll listen or read the message, you changed behavior.

And so we really evolved our interactive capabilities using NLP to say: Hey, what are people saying in response, when I tell them to go get the flu shot, are they saying that they're concerned about the cost or they're concerned about how far the flu shot clinic is, or things like that that may be coming back.

And then that interactive, they then said, okay, now that we understand, especially with chronic diseases and care situations that require not just an individual or a single outreach but more of a longer-term education, possibly behavior change. We started building tailoring. We built an engine that took not just the NLP results what did people say, which were responded to in real-time, but also said, okay, what's the profile moving? How are they, what behaviors are they engaging in, what are they not doing, and then what's the next best content. So we both have a recommendation engine for the content as well.

So those are the three sort of pillars, the delivery mechanism, the platform if you will get the word out via NLP, and the engagement engine that says: “Hey, let me talk to you in real-time so that you can use human natural language.” And then finally I would say the newest spin around for a little while, but the layer that's but I think is most innovative is the recommendation engine based on past behavior.

And I'm trying to get to that. We've also, as you mentioned, three acquisitions, one of them is investing in an IVR platform. So we have a very robust, we started out just being SMS, email, very focused on mobile. But recognizing, especially Medicare populations, landlines are significant and, and continue to be a group of the population that we have to reach.

And sometimes landlines are the best way. And so IVR allowed us not just with landlines, but also mobile of course, but to engage in interactive voice. So that's something we through we add it to the mix, so that acquisition. And then, most recently we had a learning platform that had an abundance of really good content, based on learning theory and really trying to educate the member by virtue of using expert videos, experts in the field, and various health topics and breaking it down into very basic terms for people like us who are not of the medical profession to understand and hopefully, educate ourselves and be more health literate.

That was in early 21, if I'm not mistaken times flying, losing track. And then it was late 2020 and then officially 21 that we acquired the company called the big now. And then in late 21 and closed in early 2022, we acquired a company called Health cloud, which was actually a competitor of ours.

And we really were quite respectful of what they did and they were making some good progress and excited to have them join. They too have sort of similar ideas around orchestration focused very heavily on the Medicaid and government programs in the general Medicaid space, which is a very important area I think. Especially as it pertains to making that impact, that mission that you mentioned. So we're very excited to have them join the team. And so, they're based out in San Mateo, the big nose in Minneapolis. So we've now not just become a company based in Los Angeles, but really a company that's now truly across the country with engineering teams and professionals across. 

And as you mentioned, we do work with organizations throughout the world. Now we started with Delhi and India, and now we have actually a team that's based primarily out of Belarus, but also in Ukraine. And a lot of those folks have moved out because of the recent situation there, but working with them we've worked a little bit with an organization in Uruguay briefly, but those are the main, the growth of the organization. It's yeah, it's quite a lot. It's been quite a story. 

[06:42] convincing people to use your product without convincing

Ivan Dunskiy: Yeah. I'm curious to learn more about the product. Specifically, you mentioned a recommendation and NLP. So I'm wondering, it's obvious that to build that you need to have much data. Maybe you can elaborate on distribution channels, what provided you access to many patients and how did you build your product in a way that the patients really used you?

So I think that is key because obviously recommendations and all those things happen next after you have some traction.

Ram Prayaga: Absolutely. No, that's a great point. I mean, you need to convince people to use your products.

And you don't want to convince them with very kind of exotic things, simple stuff. And that's really what we focused on. And that's what I meant by platform. It was basic, there wasn't any, there was no magic. There was no AI, per se. People, the clients knew, we were working with large enterprise clients as a small company, you had to deliver what they needed immediately.

You didn't want to tell them what they could use a year from that. It was: "Hey, you have a problem today. We can solve it." So it was very tactical. But our vision along the way was: "Hey, let's get them in. They need a problem solved today." Once we can solve their problem, then we can start exposing them to some of the roadmaps that we have. 

Ivan Dunskiy: So, you've started within the enterprise.

Ram Prayaga: Oh yeah. We're a B2B organization and consumers don't pay for it. So Kaiser Permanente, and Humana, they are the paying clients. We work with their members and their patients. But the member doesn't know whether it's impulse. They only know whether it's Kaiser Permanente.

The branding is all through our clients' branding. So we are behind the scenes from a client perspective. We are the engine behind it, we're literally behind the scenes, which I think, has been good. The other thing from a business model standpoint is they're the ones that control the money in the US market.

Consumers have to go through their insurance, getting individual members to start paying outside of what they're already doing. I think that that puts an undue burden. So working with the Medicaid plans, working with the insurance, commercial employer plans - that has been our strategy all along our investment came from. VCs that understood that market. We took a very healthcare-focused route throughout, how do we work with the system, and understand it. Our CEO came from Humana and led a large, very large business unit within, it was the CEO of that organization. Our CFO came from healthcare as well and from the finance side. So understanding both, how do you run a business within population health within a large insurance plan, how do you run the finances, what are the things that a CFO of such an organization would ask? What are the questions that would, they would want to be answered?

And so I came in actually not from healthcare. I was wanting to get into healthcare. I came in purely as a tech guy, wanting to apply my skills to healthcare. But that leadership that with Brian and Chris, this was I think, a big part of our success with just knowing how our clients think and what makes them more successful, helped us to say, here's the product that you need.

So I think it's really about, and then we've heard this a million times, so it's nothing profound, but it is important that it plays out really well, which is listen to your clients. Don't try and don't try and force them into something they're not ready for. Once you get their trust and their respect and you do provide value, then you can start innovating with them. Then you can start growing with them, building but to shove down innovation in someone, especially in healthcare, which is very risk-averse, there's a lot of stakes. And if you go too fast, I think you run the risk of losing your audience and losing their trust.

And I think our very measured and systematic approach allowed us to get that data that you're talking about to them and create more data-driven products. And some of the other things that we do data, in some cases, especially the recommendation engine is really making more of an expert system rather than a probabilistic system.

And the reason being clients can see: "Hey, why did you say that? Why'd you sent that message? Well, here are the rules that got triggered. Do you agree with those rules?" "Yes, I do." "Okay. So there you go. Now you agree with the decision, if you don't agree to the rules or we don't agree with the outcome, let's work out the rules and we can use data to inform how to improve those rules."

So those are handcrafted. So we are very particular to make sure that there's clear visibility for our clients to say that nothing that we did is sort of this black box magic. That to us was not the best way to convince our clients to use these higher-end products. And of course, we charge them more for it as well.

So, all the more reason to make sure that they are completely on board. 

[11:43] introducing tech products to people in healthcare

Ivan Dunskiy: Got it. And could you tell us, because part of our audience is healthcare, healthcare startups, and they just want to know and learn how they can apply their technology in real life, in the real world?

So what was the process of acquiring these payers and how did you introduce technology to them? Because I think that on that point, you didn't have much data and patients. What was the journey? How did you convince to use the technology?

Ram Prayaga: Yeah. So, everything starts with a little bit of luck, right?

So, we were fortunate to get Kaiser Permanente, which was one of the most innovative and well-respected organizations to sort of do a pilot with us. Obviously, that was incredibly successful. We dropped the no-show rate quite significantly. And that sort of opened the door a little bit.

We took that and again, what was the problem we saw. So you have specific problems here. People are canceling without telling you. People are not literally not showing up. And so for an organization like Kaiser, that is very, very optimized for making sure that their doctor's time is spent as well as possible.

And one cancellation is quite costly. So the ROI was very important. And that's what I was saying to you from an actual perspective. You can't just say: "Oh, we're going to make all those big, amazing decisions, differences in members' lives. And they're going to take care of the health."

Well, you gotta play that back in terms of dollars and cents. You gotta speak that language as well. Insurance companies, as payers particularly are, they're the risk managers. They are worried to manage the risk and they are in large part driven by numbers.

So I think, that absolutely is a significant part of the story. Here's how many dollars we can save by virtue of if you reach a hundred people, let's say 10% of them engage in that behavior today, and then 20 tomorrow, that's that 10% difference. But the extra 20 people will save you or gain you this much if it's new members. So I think those dollars make sense.

The other thing is frankly, the timing was perfect with the affordable care act coming into place. And some of the requirements around, especially programs, requiring organizations to really look out, not just, Hey, did you reduce your costs and investment back into, to patient populations on the provider side, reducing readmission rates and some of that accountability that came in really helped organizations like that. As I was saying, you need to engage with your members, you need to get them doing the things that you talk about and you put your marketing brochures about, but are they doing them? And so we provided this incredible source of feedback. Even something simple, like a health.com serving, health measured.

You don't want to get surprised and say: "Oh, I guess I didn't do well." You want to get ahead of that. And so things like that to engage members in this interactive, low cost, liquid manner, SMS being a core channel, we convinced a lot of our clients that say: "Hey, look, if it's low cost to start with, the value could be tremendous."

And we saw that time again. We were able to publish a couple of papers initially around our results, around Medicaid refills. And showed that by using these channels, we could drive some significant outcomes. And so those it's never one thing. It wasn't any magic bullet, but I think the other core to this is continuous agility, just don't launder into one thing and so, that's going to be it make a break.

If you approach it that way, my sense is that I'm not suggesting that people aren't successful that way. But we took a little bit more of an inclusive approach, a larger tent of things that we engaged in with our clients. And in that sense, really supporting them in more than one way. And we made the technology secondary to the value that we're providing.

If the value could be derived with less tech, we would be the first ones to suggest it. There is no reason to position something that was more complicated, more expensive if there wasn't the resulting value. So I think trying to be as transparent and as clear as we're after the outcomes.

So are you, let's use the best technology available. I think for a technologist that's, like I said, my colleagues on the leadership side, they were very focused on the value. So for me, sometimes I'd be very proud of our tech and wanted to put that first that was the only thing I cared about. But I think ultimately the real answer is what are you doing for your clients and your members and technology is one of those tools. It's not the only tool. And I think that's a very important consideration. It is a very powerful tool and it will ultimately be the only tool that you'll rely on. But it's a combination of understanding, listening, and learning the market healthcare expertise that we had, with the people that we hired. 

So I think I've answered your question in a very broad way, but you get the idea that it can take a lot.

[17:03] presenting data in more meaningful ways as a primary focus

Ivan Dunskiy: Yeah. Thank you. Let's talk about the present. Could you please share with us, what is your current primary focus in your work? 

Ram Prayaga: Yeah. As you mentioned, I'm switched into an executive advisor role recently, I get the benefit of picking a project that I really care about. And one of those is around data. You mentioned data. When we're engaging with over a hundred million people, you can imagine that's generating a lot of data and it's always been my understanding and what I read, but, and again, nothing too groundbreaking here that healthcare data has a tremendous amount of value if done right. 

And so my focus right now is on how we’re presenting data in more meaningful ways, immediate, and actionable. I think a lot of our clients are just inundated. They're collecting data all the time as well, but we frequently get into conversations with them where basic reporting becomes a challenge.

And you wonder why he's got the best technologies and the technology is advanced. Whether you want to use good old relational databases all the way to more exotic things. And yet they're struggling. And the answer is that it comes so fast. Often the value that you're driving becomes primary to the collateral product, which is the data.

And what I believe is, and this is the focus that I want to I'm working on with our data team is to say: “Hey, how can we first handle the problem of just providing access to our data for our clients. Working with us they can get value about their own members, and insights they can use.” That may have nothing to do with using our platform.

In some ways, it may have to do with how they engage separately and outside of our systems. That's okay. But we are collecting a lot of information, so things like our social determinants of health, how do we take that and give that back to our clients in a way that's more actionable. 

In the operative word, we keep collecting data.

There are lots of reports you can download, you can get beautiful graphs. And in fact, our current dashboard looks like a collection of dashboards. And at the end of it, like, what do I do? How, what am I supposed to get out of this? So my hope is that with this effort, we'll be able to sort of simplify that presentation and make it a little bit more accessible and more actionable for our clients and also our internal teams as well.

So that's a big project that I'm interested in and focused on right now. 

[19:44] high-quality solution creation, a balance between innovations, staff hiring, and the other challenges in technology development

Ivan Dunskiy: Cool. And, could you please share with us what is the main challenge in technology development? 

Ram Prayaga: That could be a very long conversation. But I mean, we, as an organization, like I said evolved.

We didn't just have this grand idea, on day one, and then build it as we wanted and release it to the world. We evolve, we learned, we adapted and that adaptation, sort of you see that in biological systems as well. There's some stuff, there's a legacy there. There's redundancy. There are some deprecated systems, if you will, that are just lingering around and causing you trouble.

And so there is that challenge. How do you build, and how do you innovate? How do you build with modern technology while you still have to grapple with what's already there? A good example is API. We built APIs that looked like what our clients needed at that time. Maybe they weren't the best of the breed.

In current terms, they serve the needs of clients. They were able to interact with us. They got the data in, they got the data from us. But now we look at that and say: "Wow, that's not built well or the architecture is not scalable, but we can just swap it out because our clients are saying: "Wait, I've built in it."

As we know in healthcare, once you put something in place, it's very hard to sort of unseating it. Good thing for us. Reasons stickiness once get into a client. However, I think both sides of our clients recognize that there's a better way of doing things. But the resources on both ends are required to make those changes.

And so our challenge is sometimes how do you convince them to make that investment on their end and our end. So changing to modern technologies, even if we know what the answer is, isn't as simple as just building it. It is a little bit more of that budget and other things that have nothing to do with code. All right. 

Ivan Dunskiy: What is the biggest value, right. 

Ram Prayaga: Yes. Why not? I mean, it's working, just leave it. Yeah, but it's not going to scale. And so all of these conversations are. Clients are smart and they recognize it, but they also have similar constraints budgets are not just unlimited. So that's one.

The other is, I think there's a certain, and this because you're intimately aware of the resources, talent. And so when we, as an organization goes through something like the great resignation, the impact, our size is significant. When you lose, let's say, five engineers, who were doing very critical things, that knowledge.

Ivan Dunskiy: Or a crucial architect.

Ram Prayaga: Yes. 

And you suffer through that. You replaced them. Yes. But then the new person is now stuck with trying to figure out what to do next, but also what has happened and what those decisions are. So there's a lot of our time is spent these don't code problems necessarily.

These are about processes, management, and the marketplace. But as we were talking earlier, if you can get some of these things right, if you can motivate the team, if you can keep them excited about what they're doing those, and we had a lot of folks who may have left and now come back and have come back.

We call it the boomerangs because there are so many of them. And the ultimate goal here is from a retention standpoint, it's to say: “Hey, look, this you're making a huge difference. We compensate you for that. But also you need to want to do this. This is something that makes you happy and fulfills your need to go do good things.”

Nevertheless, the market is incredibly aggressive and competitive. It's hard to argue with some of the organizations that we're not directly competing with from a marketplace perspective, but from a talent. Absolutely. So that's another technology-related our engineering teams are always sort of paranoid, our engineering leaders like: “Okay, who do we need to make sure is engaged and happy.”

So I think that's, that's a big part of our, part of it. And just innovation in an industry that is risk-averse. How far do you go? How much are you willing to get ahead? Those are always difficult challenges. We invested in some technologies thinking, Hey, it's around the corner, give us six months.

It's going to hit the market hard, again things outside of our control. It's been two years and you're still not seeing it. I'm like, okay. So should we have invested in that? Could we have afforded to have done that? Given the resource constraints that we have, should we have invested in something else a little bit more tactical?

So those are, I think those questions will continue to ask any good organization. I think will always ask itself how much innovation is the right amount. Too little - you're going to get washed out. Too much - you're going to waste money. You’re going to have too much out there that you are frustrated that isn't getting sold.

And before you know it, technologies are being sold for the sake of being sold versus putting the value first. So I think, we want to strike that balance. And so I'd say, talent, some of the legacy and just striking the balance of how much innovation, how much risk do we want to take in terms of the future, those sort of things that are interesting challenges and probably never-ending.

Ivan Dunskiy: Yeah. Thank you for such a structured answer to a complex question. Sure.

[25:26] overcoming a shortage of engineers - how important the mission and purpose of a company to avoid it

You've already mentioned about challenges you have with talents. And could you please tell us how you deal with a challenge? I assume that with that growth, you have a shortage of engineers and like how we overcome it? What is your strategy and what is your proposition to candidates?

Ram Prayaga: Yeah. I know this sounds a little arrogant, but we are an industry that is actually doing good. So, healthcare is by all accounts about making positive differences in people's lives. Especially some of the programs and the clients that we have, we're incredibly proud of that work.

And so that's something we put up front. If you want to, if you're purpose-driven, you want to do good in the world, come talk to us. If you're just purely after making money or trying to just push your career, it could have been in anything regardless of the impact or negative impact that has on people - maybe you're not the best fit for us. So I think that is something we've had really, so you're telling me I could have gotten jobs in other organizations that we wouldn't call evil, but have a different perspective on what they do in the world. So I think that's important, our mission, our purpose. And then it is: "We're still a small company. By virtue of joining us, you get to make an impact."

And we are a very transparent organization. Small companies don't mean that things are transparent or inclusive. We very much pride ourselves on being very open. We have weekly meetings where we get on, the CEO comes in, and we have different departments present.

Our revenue numbers, and investments - we present our board decks to our employees. We have them and included them across the middle management and up on operations committee meetings. So they know how our numbers are. Part of it is just purely to make sure that the people who are doing the work are well-informed of what their colleagues are dealing with. And how they can help each other.

So that level of transparency is something that I think your employees will really encourage. When we've asked our new employees like: "Hey, what have you enjoyed about?" "Everyone's just supportive, collaborative. They just are very open." Everyone's super busy, but when I get time, they're incredibly supportive and I think that's something we pride ourselves on that, that inclusiveness in our culture and supportiveness.

And so what we do, even in the interviewing process, like people like me, if I'm on the call, I step away and say: "Ask the people that are on this call that that'd be the report to me, are your colleagues and peers and ask them what may be of interest to you?" I said I think that's another important thing.

And honestly, the challenge that we have from a tech perspective, if you're trying to get engineering talent, those are significant. We are dealing with high growth. We are dealing with very complicated data challenges, for instance. So you can run the gamut of technologies that you're interested in pursuing and learning and not just talking about in some kind of a theoretical sense, but actually putting them in place.

And one of the things that our tech team, they have a fair amount of freedom to experiment. There is no reason to do just proof of concept if you don't think there's some clear purpose. So I think we do proof concepts with a clear expectation that those will succeed, so you can start implementing.

So we gear things up in that sense. So we don't waste our energies, running random experiments that people don't have that personal investment and they want this to succeed to put their energy into it because we get behind it. So I think that ability to take some risks on the technology side and really learn and experiment and see that come into production, not just in some sort of theoretical thing.

As I said, I mentioned one where we built something way in advance and people got excited about it. That was a big bite of a lesson for us, like, what was our analysis? Where was it wrong that we sort of got it off by two years? We're there, but two years is a long time in our lifespan.

[29:38] if there is no role, we will create it for you

So that's, I think the other opportunity that we give our engineers, you get in there, you get to actually play with technology in production. And see it out there, not just in some theoretical experimental environment. So I think those are things that are very attractive to good talent.

Growth opportunity is absolutely huge. And because we're a small organization, you can show that there are always new roles and you're always expanding. And if you want to go to the management track, you can do that. If you want to go more on the technical, we have this started building roles specifically for that.

We found one individual actually joined us, a really sharp guy. And he thought to get ahead in his career, he had to be a manager. So he went into that and he didn't enjoy it. And he wasn't really good at it, but he was an amazing engineer. So I was like: “Hey, do you want to, so we built a roller.”

Switch back to an individual contributor role, but we knew his contributions were quite significant. He built some of the core technologies. And so we created this, principal engineer or our staff engineering model, again, borrowing from other organizations. So doing things like showing that you're not pigeon-holed, the only growth isn't to play politics, the growth is to do good work.

Ivan Dunskiy: If there is no role, we will create it for you.

Ram Prayaga: We'll create it, we'll figure it out. And I think, as we grow, we are getting better at processes being very clear about what the growth opportunities are. So those are things that I think internally are building our teams within the organization that we're using. The other is our partners outside and we know that we won't be experts in our Postgres.

So we hired the experts in Postgres who commit code to Postgres or RabbitMQ, or so. We bring in airflow, and we've hired an astronomer. So we are very keen at that level to say, we don't have to become the experts. We need to know who the experts are. And we've invested in these kinds of very specialized expert consultants that we can bring in as needed, put them on retainers, again, budgets being carefully managed.

And so when we need, when we have issues, or when we're making a new architectural change, we bring them in and say: “Hey, look at this, fresh perspectives objectively, what's the best way of doing this. So we've gained a lot from that.” And then third. And this is actually no particular order, they are equal.

Our partners are inside the org, our development partners. We look at them, not as just fog or just, sorry, just folks that are cheap there. In fact, in many cases, not cheap, they're, as, that's not what you use, but a couple of things that do make it, from a cost perspective, we can ramp up and ramp down.

So when we need to invest less inclined to invitations, we get a lot more clients at a given time. And sometimes there are cycles, right? We win budgets on the client-side, which may dictate when we close deals. And so all of a sudden we're stuck doing a bunch of implementations. All of a sudden our team's not going to keep up. We can then ramp up with our development partners. At the same time, if things go down, we can then very easily flex. So that's a huge advantage for us. 

The other is to really engage with them. Organizations that are outside us, see things differently. They are exposed to other problems that we aren't exposed to. 

That knowledge and that expertise is something that we've come to rely on. And there's, I don't think it's about taking what let's say that an organization did for another client. but it's more around the kind of thinking, the challenge of the questions. Hey, have you thought about these kinds of things a little bit more, and these are risks that you may have not considered that can become incredibly valuable.

But you have to treat them as partners. You have to treat them as your equals. And they are equally talented and competent, just maybe living a few thousand miles away, and in a different time zone. So, we have found when we hire people internally that they respect that relationship that we've built, that they value it and then they can harness it to everyone's benefit.

So, I'd say that's sort of how we do that. We are under-resourced and always will be. That's one of the things I'm very proud of, and I know some organizations play it differently. I can't speak to whether that's right or wrong. I like how we did it, which is when we hired someone, we went, we hired them to keep them.

And if they didn't perform, sure, they would be asked to leave. And if they left for their own reasons, of course, we tried to keep them and retention is a big part of our strategy, but we've never had a layoff because of budgets. We've never said, oh, we've overhired and oops, we can't afford to pay people.

What do we do? We were very careful. We felt like these were people's lives that we were investing in. And that was a commitment that we're making to each other. Especially as a small organization, there's a tendency when you get an investment to just go spend. We always looked not just the next day, but several days out.

And I think I give credit to our CFO and also our CEO to be very protective of people's sense of and what they've signed up for. Yeah. The security. And then like this, isn't just a job. This is a commitment that they're making and we have to reciprocate that commitment to them.

Of course, if they don't hold up their bargain, I mean, work's got to get done and if they're not doing it, then sure. We, unfortunately, had to do that. But never because of good people having to be let go for financial reasons. That is something we as an organization never had to do. And I think something's very proud of. 

[35:39] how mPulse chooses tasks and measures engineering teams' productivity

Ivan Dunskiy: Yeah. You mentioned that you work with partners. So I'm curious to learn more about your strategy, how you engage and how you choose tasks. You mentioned that all of them have like specific specialty. Do you offer them to do some kind of, part of a product or some product, or is this like specifically to do some job or a task associated with the skill set that other has?

Ram Prayaga: A little bit of both, but primarily I would say it depends on. So we have different partners. In one situation, our partner knows a lot about the product, has this how was built the chunks of the product. And so it has a little bit of expertise. So in that situation, we're sort of doling out the tasks equally. Hey, you do this part, I'll do this part, this much code and we'll do each other's code review.

So, it's very collaborative. And again, we're separated by time and time zone and location, but now with zoom calls all the time that's less of a concern. So that's one model. So they're just literally part of the team. They happen to have a different employer who sends them the paycheck, but they're effectively working on the same product team. Part of the stand-ups, everything is. 

In other situations, again, based on like, especially the flex model for the implementation team where we said, Hey, you are working on a specific product or sorry, particular implementation. There, we have a project manager possibly coming from us who's doing client interfacing and then getting the requirements, Hey, get this done. Thank you so much. Great job. And then move on. And so again, the benefit of this is that we are able to do it on both fronts. In some cases, folks that work on these implementations, they gain knowledge of our product and our APIs and our platform.

And so then they say: “Hey, do you want to based on how good they are and sort of similar models that we use internally, as well as you start out in prod support, let's say you want to be a software engineer. Sure. If you're able to keep up and you do a good job and prove yourself, then we'll give you the coding assessment and you can be a software engineer.

So likewise the same model applies to our outsourcing partners. They can start with the implementations team, let's say, and if they like working with us and we like working with them and they want to stick around, then they can become part of the product team. And so we have very similar models of growth for them too. So there is a little bit of loyalty to the impulse team by virtue of that, it's not just "I just get to do this, and I don't like it."

And we have had one. So I want to go into product management as he was part of the QA team and grown through the ranks. Now he's a product manager. It's like, great. You can help us on that side too. Again, we do have that sort of, sense of partnership with them. They're part of our team.

Ultimately that's how you have to look at them. And so when we have concerns, so we, I called up the CEO of the organization, Hey, look, we're hammered with lots of requests. We can keep up. And our teams can't, we can't hire fast enough. Can you help? So they literally pull from other projects that were maybe in a little bit of downtime to "yeah. Let's help you out. And then scale up as a look. I don't, I don't know if it's going to last more than three months, is that okay? Like, yeah, we got you." And so that's when you have that kind of partnership, you can sort of flex and you do it very transparently. It's not a black box.

You don't, if they talk to us, they congratulate us on our successes and the same on their end. And so, I think that that's it. Therefore we can use all of these different models of engagement, right? It's not just one, one approach. 

Ivan Dunskiy: Yeah. I think that this type of relations bring satisfaction both to development partners and yourself. Ideas coming in and like, there is a feedback, positive feedback.

That is essential. Could you please tell us, how do you measure your engineering team's productivity, meaning both in-house teams and partners teams? What is your approach to doing that? If you do that.

Ram Prayaga: Yeah. We do, but I will say. So, when we were starting out and just getting the feature out anywhere, close to the deadline, it was a win, that's how you measure it. We've got that feature on our, we were able to successfully deliver on something in all ways it was, we always were, let's say we wanted it yesterday.

It was never something that we could sort of think ahead. And so playing catch up huge roadmap, all those feeling like we're behind. So it was just, getting a sense that we were able to deliver without burning each other out. I think that was our measure of success. It sounds very vague and broad.

We did start looking at a number of tickets, and ticket points. And per sprint, we have an ops committee meeting that actually looks at bugs to features. So we go into our JIRA, we export how many bugs did we deliver to how many features in that month? How many tickets do we have? How many blockers do we have? Any support tickets that we have? 

So we try and track all of these things and, and looked at it. And we also track our service level agreements and whether we meeting them, and our availability uptime. So we measure a lot of things, partly because we're in the healthcare space, but also just to kind of inform ourselves how are we doing.

However that said, and those are good numbers, I think, to give you a rough order of magnitude, like: “Oh man, taught, a lot of support tickets this one.” That feature didn't work out so well, or broad strokes. We're actually going through a very sort of rigorous sort of metrics, design exercise, and saying, what are the true metric?

What are the true KPIs that we want to go against? For example, when we were doing the point system, it was dependent on engineers putting invalid points. And sometimes it feels very bureaucratic and like, why am I doing that? But stupid. I can fix the bug in the time it took me to put in that point. You can have conversations all day long.

If you want the bug fixed, you let it go. We have invested in folks that are helping our engineering team and also leaders that invest a little bit on the process side as well, to make sure that this is part of what you do. It's like brushing your teeth you just do it. 

Ivan Dunskiy: There are some specific people or what?

Ram Prayaga: It goes, it comes and goes, you say: “Hey guys, let's put it in and like, they'll do it.”

And then the next month it's gone again. It's a little bit of like, oh God, like, oh, it's that time of the month again? It's a little bit of that. So we want to get it, we wanted to make sure that the metrics are incredibly powerful.

You didn't just collect data and then think "that's magical enough." No, you have to have a purpose with it. There's gotta be something that, what's the design. And so I think we want to dig a little bit deeper, which components are causing us the most grief. How are we investing in legacy versus you?

And what is technical debt costing us? And these are areas that are hard rooted to tease apart. Everyone gets frustrated by technical debt. No doubt. How big is it? How big is it to the point where we truly stop some innovation and refactor and fix these things, that's a heart?

And if we can truly get those numbers, that again, And I don't mean to say this, but there is a good trust between the non-technical side of the house to ours. So we go to them and say, Hey, we want to clean up our text app and they'll say sure. If that's what you think is right. So it's really just internal engineering since as we are convinced that that is the best use of our time? Or do we need to put in place additional features to keep up from a product perspective? So working with product and the engineering side and getting some of those metrics to say, where is the best investment- that's what we're actually engaging in right now.

And then tracking ourselves even the other ultimate thing is we build that's great. It gets out there, hopefully, bug-free. One of the things we get less feedback around is how well is it fitting into the marketplace. How well is it selling? What's the business impact of that particular feature to our clients, to our account teams, to be able to upsell, or to our clients to use us more. That feedback is something we'd like to incorporate much more, much more organized. Right now it's more anecdotal.

So we get it, we have our meetings, but we want to sort of put a little bit more data to that, and put some numbers against it. So, yeah. And it's about maturing and being able to say "we did it this way. That's great. When you're a teenager, now you need to grow up and be an adult and things get a little bit more rigorous and more streamlined.

So that's the process that we're currently in. So it's good, it's a good question. I feel like the question could be answered better in a couple of months. 

Ivan Dunskiy: Yeah. Well, we can have another one in a couple of months. I'd love to because, unfortunately, we do not have so much time, but I have a lot of questions.

[45:12] Elon Musk statement discussion - must technical managers be technically excellent

I have another one for you. So, probably you've heard about this tweet of Elon Musk that he stated that in his mind technical managers must be technically excellent. So what are your thoughts about that? 

Ram Prayaga: Great question. Oh, I've been thinking about that as well. 

Ivan Dunskiy: Let me also add to it, because to my mind that is quite contradicting because when you are an excellent coder maybe you don't have these communication skills and maybe you don't have the desire to have them. Or otherwise, if you are a manager without technical skills, you don't necessarily understand all the aspects and I would put it ROI on some decisions.

So you should have some technical awareness, but on what level? That's really a question. 

Ram Prayaga: Yeah. I mean, I think it's a bit of the organizational size. I think we've gotten to an organizational size where writing code as a CTO, for instance, is just not sustainable. You can do it maybe once for a proof of concept or as an experimental idea.

But definitely not production code. And in fact, my engineers refuse in this, it's like a known thing. I refuse to put my code into anything, there's like: “Oh, that's great. Thanks for showing us. Great, good idea, Ram. I got this.” I think it's about having enough technical, I think it's exactly what you said.

It's an understanding if you don't know who you're hiring for. You're relying on other people to do the work. And it's not machines that build the code and not yet at least, it's humans. So we have to evaluate, and if you don't have enough technical chops if you haven't been there done that. Are you hiring the right people to then rely on to do the work?

So I think like a technical manager, you're one of the primary responsibilities is to hire the right talent, and retain that talent. And if you can't mentor them, and if you don't have the technical depth to be able to mentor them in a way that's meaningful, I think that is maybe what Elon Musk is referring to.

However, I do not believe the technology needs to get into the code and start committing. I think it's about knowing the attributes and characteristics of good versus bad quality, versus what would be called not excellent. That comes with experience, that comes with having done it.

You can't just read it in a book and say, "Yep, I think I know what I need for my engineers." You must have learned some of that the hard way. You must've made some of those mistakes. So you prevent others or it can detect it when you see it. But there comes up. You mentioned when we had our engineer, who I, what was it exactly case in point to your point, Ivan, he was a very good engineer.

He was not a good manager. And he continues to be a very good engineer. But I believe he's not a good manager and he doesn't want to be. And I think there are, and I've seen really good managers whose technical skills are, let's say a little stale at this point. It's been a little while since they've really worth it, work them, but they're very good at picking up talent, investing in talent, and continuing to retain. That I think makes for a great technical manager. 

Ivan Dunskiy: How do these people, this good manager, as you think of them, how do they deal with that problem of related skills and decisions? 

Ram Prayaga: I think it comes down to curiosity. I think they're willing to engage in those conversations and able to have to empower the team, to have the conversations with them.

I do worry a little bit about the manager who says: "Look, I set up the meeting, and let me know what happens, right? Tell me what the action items are and I'll follow up." Those technical managers I worry a little bit more about. I think those are the ones that Elon Musk is talking about. Those are the folks that sort of being like their job is truly just management and forget the tech part of it.

Ivan Dunskiy: Give me a report. 

Ram Prayaga: Give me a report. Things are going well. How are you guys doing? Any blockers? Okay, good. Yes. I mean, there's value in that. There's good for organizations and especially for the business to hear that things are well, but for the team to feel like they're with you. I think being in those meetings, have voicing opinions, even if they're wrong, willing to state some opinions and hopefully educated opinions.

Let the team beat you up, be humble enough to say, "yeah, that was a dumb idea." That I think is how you stay connected and you pay attention to who in the room is willing to risk and do these things. And if you've assigned your leaders, the tech leads, or whatever, and if they are contributing in that way, then I think you understand they're adding value.

If they sort of step aside and not engage, not get committed, not get enthusiastic about where things are headed and shift that accountability to other people, then I think one worries a little bit. So it doesn't mean that they have to talk the loudest. It just means that they have to be engaged and accountable the most.

And so I think for a manager it's like identifying those people that are willing to sort of speak up. When I say speak up, take responsibility for some of the decisions. But in order for that to happen as a leader, I think it's important to sort of engaging in the conversations as much as possible. As an equal. You have to ensure the team feels confident and can say that your idea's stupid.

I've definitely experienced that more than once. And maybe my ideas were incredibly stupid, but the point is when you're in that room in a technical conversation, you're all equal. And that allows I think for someone like me to evaluate who's engaging in what way. Who's deflecting ownership.

Who's willing to take some of that ownership and accountability. Those are things that I'm looking for so that I can manage the team a little bit. Yeah. 

Ivan Dunskiy: You mean it from the engineer and team who could take responsibility? 

Ram Prayaga: Yeah. So those are the things that at my level, I need folks that are on the field willing to sort of taking charge and push through.

There isn't, I think a single path to the right solution. There are multiple parts there, so.

[51:41] how good the engineer should be at the leadership

Ivan Dunskiy: Let me ask you further. So, but if they don't, if they don't take this responsibility, what do you do? Is it a kind of marker for you that you need to hire another person or replace them, or you just should, like, I don't know, make a conversation with them that "I expect you to have that responsibility," or what is?

Ram Prayaga: I think that feedback is important.

I think if there's an expectation that says there's a tech lead and they're either letting the product managers sort of just tell them what needs to be done and product managers essentially becoming the tech lead, which has happened or kind of happen. Or they defer to folks that would be considered by everyone as too junior to make those kinds of decisions and offloading. That feedback has to be given to the tech leads.

And look, if you're doing it because you want to empower that junior individual, are you supporting them enough? And so, it's never a judgment based on that one interaction. It is a conversation. In one case I've had a situation where the individual again, having heard from others “great, good talent, smart, does a great job.” I spoke to them and they basically said: “Look, I'm more introverted. I don't feel comfortable sort of speaking up in these kinds of group settings. I like to think about things and then come back.” And I said: “That's great. Then what I need is some form of communication to the rest of the organization or to the team that you are taking the lead.”

So it could be through email or it could be more prepared, but you need to demonstrate that. And in his case, it was just that, he was a little shy about showing leadership. And so I think you have to be sensitive to that. I think that's perfectly fine. You don't want everyone to be next to written and talking and talking.

So it's not about just talking, but it's about communicating and communication can happen outside. And I think that's where the feedback may be. It's like: “Hey, if that's an issue, if the other is more, I don't get to make any decisions. No one who cares there may be a sense of lack of empowerment.” “Hey, is that because you don't think we trust you, I'd like to think that those folks and genuinely it is true. That they got there because of good work.”

But yes, there are situations they feel overwhelmed. They genuinely feel like, wow, this is too complicated. I can't keep up with the team. And in those unfortunate situations where we try and find something, that's a different path or in some cases, this isn't the best organization for them.

And that could be a very positive conversation. We are one of many organizations, right. So, and the market's great, so it's not the worst thing to happen. And we've seen others succeed really well as we.

So, I think it is, it is definitely a follow-up conversation. But, again, I do less of it now and in my role, because our organization has grown so much, but that's what we are looking for our leadership to do.

[54:48] Rapid Fire Round (3 questions)

Ivan Dunskiy: Yeah. Cool. Unfortunately, we are coming to the interview and just to end this, I have kind of more personal questions. We call this exercise Rapid Fire Round, or we'll ask you several questions. What is the latest movie that impressed you the most? 

Ram Prayaga: Oh gosh. The latest movie, I dunno, I'm blanking on this. I've seen some really good movies of late, but one of my favorites, which is a little old is Arrival. But that's such, it's such a long time ago. I've seen other good ones. I just, right now I'm blanking. 

Ivan Dunskiy: Do you have a hobby? 

Ram Prayaga: Well, I don't know if it's a hobby, but I have a passion for soccer. I love to chase a ball and do that. And yeah, that's what keeps me out there. 

Ivan Dunskiy: And what is your favorite book? 

Ram Prayaga: It's crazy. But my favorite book, almost my Bible is The Hitchhiker's Guide to the Galaxy by Douglas Adams. So yeah, it's stupid, crazy fun fiction.

Ivan Dunskiy: And what advice could you give to your 20 years old self?

Ram Prayaga: I think just be willing to learn, be open. Always, always be humble and if you haven't figured it out and you won't figure it out, that's the beauty of it. So I mean, sometimes, we want to get there fast. I have to get there before everyone else.

Those things, they all work out in the end. Whether you get there first or second, it's important to be there and be open to it.

Ivan Dunskiy: Great. I think that's a perfect way to end this interview. Thank you for sharing the insights. Both from the product development, standpoint, as well as how the company can evolve from the technical and product perspective. And just enjoyed how we talked about the technical culture and dealing with engineers.

So I think that our conversation could be interesting both for early-stage startups as well as for a company that grows. Thank you, Ram. Before we finish. What is the best way to get in touch with you? If somebody wants to.

Ram Prayaga: Thank you. Great questions.

My email address is perfectly good, so I'm also on LinkedIn obviously. So I think those, maybe you can put that out there. So I checked both, quite all the, my email sometimes gets a little full as everyones. But I do check it and LinkedIn is just a great place, so. Thanks, Ivan. Take care. Stay safe.

Ivan Dunskiy: Yeah. Thank you, Ram. Thank you to all of our listeners and we'll catch up in the next episodes.

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.