Reecha Mall: Navigating Complexity - Product Leadership in High-Growth Environments

This transcription of the podcast is AI-generated and may contain errors or inaccuracies.

Leszek

My name is Leszek and I will be talking with Reecha Mall about the challenges of scaling tech products in highly regulated environments, focusing on leadership and system complexity. So Reecha, can you give us a brief overview of your career journey so far and how you ended up leading product efforts as at Trellize?

Reecha Mall

Yeah, so I started as an engineer. I am a computer engineer by training. I have only done kind of tech product building but from different roles and lenses. So after going through my college I joined a tech consulting company in India. It was called Infosys. So they used to DO consulting for US company. I have 20 years of experience building tech products.

I started as a computer engineer. So I went to college to study computer engineering. It was around the time of the first Internet tech boom.

So 2000 crazy times. Intense, intense. As I was doing my engineering, the market crashed for the first time and so it was in middle of my engineering and, and. But again things resolved by the time I came out of college. I started with a tech consulting company who used to work for us Banking, insurance, health insurance, that sector. So my first project was working for a US healthcare company building software for them. And as I am, so this is my first job and I'm going through it.

And when you go through engineering school they teach you a different way of thinking and doing stuff and then when you do it it's completely different. And I have this way of life where I would be in a thing and I would actually look back at it as a third person to why is this different than what I was expecting? So in my first project what I noticed was that I had learned these laws, like Parkinson's laws work expands to take all the time what you have committed for software development. So estimates are almost always wrong and software. But then I'm working on this first project. It is for the, I think the third largest US healthcare company called Aetna. They are based out of Connecticut.

And my first project, I even now remember my team lead saying this is the date we have committed and this is the date we will be ready. And I'm like, how? Like how will that happen? We have so many moving parts. We have like more than 20 people working on it in different locations. How is that going to work out? And she's like, it just would.

So I didn't know at that time what was happening. And then after like 20 years of hindsight, I can say that there are some processes, some tools, some frameworks which work at scale. And some companies have figured it out, some groups have figured it out and most of the companies don't know what it is. And that is the difference between companies, people who can figure that out and implement it, and people who can't.

Leszek

What took you to where you are currently? Meaning leading the product.

Reecha Mall

So fast forward from my first project. I worked on US healthcare for around 10, 15 years. Moved to US in around 2009. Um, and I in two from 2010. I actually worked on implementing Obamacare. So taking it from reading the law to what is required for another healthcare company called Anthem, they are called Elevance Health Now. And that was the place where I started going from like building software into thinking through this is what needs to happen and what product can fill that business requirement or that regulation of Obamacare.

And I did it at scale actually. So when I was doing it, I was like a system analyst manager for two people in my team and we had to implement Obamacare for all of our Systems in like 14 months. So Obama gets elected on in November 2012. It was expected that he will not win and so Obamacare would not be implemented. So nobody had actually worked on thinking through what it needs, what needs to be done. And then from the next day of his election we started working and we had to make it available for the public on the 1st of January 2014. So less than 14 months and it was going to impact around at least 10 million customers, our current customers at that time.

So how do you build something for 10 million customers in less than 14 months and you have no plan? So that is my entry into real product management, product development and doing it.

Leszek

At scale again scale, limited resources and not lots of time seems like a real life challenge in the product world.

Reecha Mall

It was kind of life and death too. Because one of the statistics in US Healthcare is that if people don't get health insurance and they have a real life event, bad medical event, they don't survive 10 years. And it is now a decade of Obamacare. So if you think about all the people who got healthcare that year are now living, otherwise they probably would not have survived something catastrophic even happened.

Leszek

Mm. Can you share the story behind or actually how did you tackle this? Because I assume it you did succeed in building the software.

Speaker 3

Right.

Reecha Mall

So okay, how did I do it and why did I do it? That's two questions on that. So the first thing was if you think about all the people who are doing tech product, they're always thinking about how to modernize legacy systems. And if you're working in a big company, most of us who work in tech are Always thinking about what is the next frontier of that. So even before Obamacare implementation started, I was thinking about what does buying insurance and interacting with insurance looks like in this world of when we have iPhones and the App Store. So if you remember App store released in 2008, 2009, this is like two or three years after the whole mobile revolution which was happening. But most of the big companies at that time did not have a mobile app or even a way to navigate through your mobile phone.

So there were people who were buying stuff on Amazon on one click. But if they had to buy insurance, they would have to call a agent, set a appointment, the agent will fill out the form, you give consent, you need to figure out how to sign. DocuSign was not that popular. Like again this, all this in last 10 years have expanded so much. And at that time I was thinking how to bring that kind of thinking into stuff like banking and insurance on the legacy things. So what would that user experience look like? And so I had this whole big plan of what that kind of systems look like from a customer's perspective, just to give some data on that.

It used to take people two months to have that appointment with the agent and then to get their card which they can go and set up doctor's appointment. So two months from getting the quote of what it is going to cost you to buy.

Leszek

It's pretty long time.

Reecha Mall

Yeah, pretty long time. So and this is in the business that is called code to care. And then after you got your card, it will take like a lot of time for you to book a appointment with a doctor. So maybe if you buy insurance, it may be like 90 days to 100 days before you can even see a doctor. So I was actually trying to solve these two problems at the same time. What does a user centric experience looks like and what does contracting this time from 90 days to let's say a week, what would need to happen? So they asked in that paradigm, you're not doing things faster.

What you're doing is you're removing steps. This is the preamble to. When Obamacare got introduced, we took the opportunity to change how health insurance is bought and accessed. Not hundred percent, but some part of it. And then use that as like our leverage and you know, that bouncy thing to make a paradigm shift. So I would say it was right time, right place, right thinking. All of this luckily worked out that we were already thinking about this and now we had this unlimited budget.

Not unlimited time, not unlimited resources, but unlimited budget to make it happen. Some parts were good, some parts were very bad. So I give you an example and this is like the story of US politics even now. Actually, I don't know if we are seeing the debate or not, but they're still discussing Obamacare in the erections.

Leszek

I don't know, I mean I haven't seen, I just seen the commentary, commentaries and some comments and you know, highlights of the debate. I, you, you especially, I mean the recent one with Harrison.

Reecha Mall

Right. So what happened was it was such so many different disparate systems. So US government and federal government decided that they are going to create this whole portal healthcare.gov where people will come to buy Obamacare because states and Republican Democrats had different views on how they wanted to implement. So Republican states, I'm going to be honest, they didn't want to implement this not because they didn't like it or not. This was actually a plan built by Heritage foundation which was a Republican think tank. Mitt Romney actually implemented it in his states. Some pieces of it were implemented in Massachusetts, again by a Republican governor.

But when Obama wanted to implement it at federal level, politics got involved. And so even though the mechanics of the plan and what they wanted to build was the same thing, they didn't want to give credit to a Democrat to do it. So technically what happened is that okay, if states are not going to provide their own portal then people will think Obamacare is not working. So the government thought that okay, we will build a federal US level healthcare site. But in US the other thing is insurance is regulated at state, state. So the pricing of each plan, what it should cover needs to be decided at state level. And Obamacare is saying that we are going to create these new plans which will be decided at federal level.

So figuring out what needs to be decided at state level versus federal level, how these things will work became a technical challenge. Now the idea was that people come to a government site but behind the scene they are buying health insurance companies policy which are private companies. So these are not government regulated companies. All government is doing is that they're giving guideline on these are the plans you need to offer, these are the minimum benefits you need to offer. This is what we are saying the rates could be. So not the same rate but range of rates and you can decide based on that how you're going to price the product. So they gave minimum and maximum and then left it to the private companies to decide.

And from a user experience perspective the biggest technical challenge was how do you connect the government site to the back Ends of the private insurance company. And this is only for enrollment. How will we tell the customers that what plan did they buy? How would we know that who is buying which plan? So that we enroll them into our systems and we send them the card. So then they were like, okay, let's create another system system in the middle which will take the data from the government side and send it to the right systems in on the backend side. And there was no way to coordinate requirements because who is going to write requirements for these three different systems?

So Deloitte was building the healthcare.gov site, the middleware. They were like some startups who came in and they were, they asked like they, they do request for proposal. So they filled in the request proposal, they won that thing. But they had never built health insurance systems. So they didn't realize the complexity to what is required. So one simple example is that I enroll myself, then I remember that I need to enroll my dependence as well. There is no transaction to add.

Everything is like a new transaction. And so we are getting these, all these applications, but we don't know if they are the same person making some change or different people making different applications. And so from a user perspective, they submitted their application, they made changes. From our perspective, we didn't get anything or we get too many applications and now they are complaining that they are not getting their health insurance card.

Leszek

I'm thinking about basically what were the success factors or what contributed to the end result that it actually eventually all worked out. Maybe not perfectly, but what were some principles, frameworks, how did you approach that or how did your teams approach that? So eventually it worked out right.

Reecha Mall

And I'm going to take us back to my first project, which I was saying that I learned about all these things. Parkinson's laws and software estimates are never right, but we still delivered on the right pace. So what was happening at that time, all these companies who have figured out scale, and by scale, I mean of scale of reach impact, how many customers they handle, how many transactions they handle, and also scale of doing the same thing for decades and centuries. So most of the health insurance companies in US have been in business for 100 years or more. So they have been doing this for a long time. And what they have figured out is you need to separate out what is complex and what is complicated. So I don't know if you know the difference between complex and complex.

I can actually.

Leszek

Yeah, please unpack it. Yeah, sure.

Reecha Mall

So complex systems are systems which are not deterministic. So they are interactions of forces within the system and you can predict them, but they can beat your prediction. So, like human body is a complex system. There are forces of entropy which is trying to break things apart, and then there are forces of equilibrium which are trying to keep things stable. So immune system is something like that. And if something external attacks has mechanism within itself, which will bring the system to homeostasis again and again.

Speaker 3

Right.

Reecha Mall

So that is why in complex systems, major changes don't happen abruptly. The system can adapt, or at least the living systems can adapt to. Sometimes maladaptively, sometimes realistically, but they can adapt with any external forces applied to them. Complicated systems, on the other hand, are deterministic, as in they have a set solution. They may be hard to understand and hard to explain, but they have straightforward solutions. So for example, internal combustion engine is a complicated system. So although there are forces of entropy in internal combustion engine as well.

But you know that if you're going to put this much gas for this capacity of engine, this is the speed which you can predictively get unless something major goes wrong with that thing. So those systems can be mapped into a mathematical equation and most of the times it will be right.

Speaker 3

Right.

Reecha Mall

So in a company, in a project, in a software code, how much is a complicated system versus complex system?

Speaker 3

Right.

Reecha Mall

And to scale anything and to deliver at scale, scale as much things you can separate out as complicated system and build processes around that, so that the complexity of the system, as in the human beings who are involved in that system, the political machine, the social, economic factor, even that changes. The complicated system keeps churning stuff out. Okay, and this is the difference between I would say startups and big organizations which have like banking systems and insurance systems, is startups have not figured out what their complicated systems are and built processes around it, irrespective of who is the person working on that thing. So they require heroic effort from individuals in the system to deliver something. And that hero can fail based on their own constraints or how the team around them is behaving. But in companies who scale, they figure out that these things will happen, like human beings will have their own things and team dynamics will change. But can we make all the important stuff complicated so that we can model out and deliver that?

So that is the framework and principle behind it. And what I would say is, and what we all can learn from, maybe we don't all like all the legacy systems and they don't innovate that well, but this is one thing they have done very well. They have separated out complexity and complicated systems and projects, and even Big projects like Obamacare which impact millions of people can be done irrespective of who you hire, what their skill set is like you just need basic level of input to the system and it will still work out in the end because a lot of processes have been put in place for that thing to work out.

Leszek

Yeah, so. So my understanding is that your approach was basically to decompose the system and figure out which ones can be built in a complicated way and which. Maybe there are parts that were left to be complex still, but eventually that complexity might be reduced to being complicated rather than complex system. And probably not everything could be complicated as opposed to complex. The day one, I assume it was a process and this is one of the reasons why not everything work out perfectly. Did I get it right or.

Reecha Mall

Yeah, I mean it is mostly right. One thing which I have one caveat is that creativity and like the what a team will achieve will still be complex. So you cannot reduce it completely to complicated. And the goal should not be that we should reach complicated customs. The goal should be that ultimately it is going to be a complex system. An organization, a company, a product is going to be complex. But whatever is required for customers to have reliable experience, majority of that can be made complicated.

Leszek

Got it, got it. Since we have talked about, you know, building complex or complicated systems, the Obamacare, I want to talk or I want to dive into some of the challenges companies face as they grow. So from your experience, what are the most common reasons companies fail when they attempt to scale, particularly in tech sectors like fintech, hint for tech or in general.

Reecha Mall

Yeah. So one thing which they do is that they keep doing what made them successful. So initially when you're starting as a startup, you are revolting against the status quo. You have an opinion which is not the, which is not what everybody accepts.

Speaker 3

Right.

Reecha Mall

And that is why you have a startup, because you have a completely different opinion than what mainstream Main street believes it.

Speaker 3

Right.

Reecha Mall

And so in that place what you're doing is you are telling yourself like you are creating the self belief that I am right and I will through the force of sheer will and get all the like minded people together and prove the common wisdom wrong.

Speaker 3

Right.

Reecha Mall

So that is required, that is required to do the breakthrough in whatever opinion you have.

Speaker 3

Right.

Reecha Mall

What where they fail is when they reach a certain scale. Now the problem is not to prove people wrong, but the problem is to make this experience consistent for a bigger swath of people. And what it will require is creating a new status quo. And because they, if they are successful and they reach this point, their whole mental model is to revolt against status quo. And so they start revolting against their own success. And that is the first challenge a lot of founding teams I have seen making and they become their own impediments. So yeah, so that's the critical part.

And founders who grow from that are people who know that now this is the place where they need new level of growth. And the interesting thing about tech products, especially in Fintech or Insuretech, is that this is the time when regulatory bodies start monitoring them. Because if you're small, nobody is monitoring you. So now they have an external problem. They are already revolting against their own belief that they need to revolt against status quo. And so what they take as regulatory challenges to build a safe system as a thing, no, I need to revolt against that as well.

Speaker 3

Right.

Reecha Mall

So they don't want to introduce regulatory things into their software because they think these things are just slowing them down. But if you think from a customer perspective, and I'm going to ask you this question and tell me this. So you use probably a kind of credit card or bank account and something.

Speaker 3

Right?

Leszek

Sure.

Reecha Mall

None of us love our banks, big banks, but how many times have you gone and checked all your credit card statements to the penny? Like do you. Never, never. We have never done that. None of us like our banks, but we still trust them implicitly that they are doing that.

Speaker 3

Right? Right.

Reecha Mall

And that is what regulatory things help us with. They give that trust in the system that if something is wrong and you find that out six months later, the banks will change that for you.

Speaker 3

Right.

Reecha Mall

And because of that, the cognitive load from the user is gone. Okay. And this is why we need to comply with regulatory compliances and whatever the law is in the product, we are not doing it for the government, we are doing it for our user.

Speaker 3

Okay.

Reecha Mall

Trust us.

Speaker 3

Right.

Leszek

And yes, that's a nice way to put it. That's really nice to. Or way to think about it.

Speaker 3

Right.

Reecha Mall

And this, so this is the thing which most companies don't understand and at that time what they're thinking about is that just telling people that people are wrong and they have been able to prove people wrong because of their new idea, they can do it this time too. And that is most of the challenges across the board.

Leszek

So what's your advice? To actually scale things in a highly regulated environment and do that effectively.

Reecha Mall

So first thing is to not equate safely with slowly.

Speaker 3

Right.

Reecha Mall

Like when somebody sees to scale something with regulatory and Compliance Things Incorporated, they think it will Slow them down. And that is not the way to think about this. The way to think about this is from a user's perspective. All the things which you are doing for regulation, how can you think as a user value and deliver that for the user quickly? The same cadence which you deliver any other value to the user.

Speaker 3

Right.

Reecha Mall

So that is the first mindset change which needs to happen within the squad, in the team leadership. When you are doing compliance things, you are not doing it for the government, you are doing it for the user. Put it in user value terms and do it as fast as you can.

Speaker 3

Right.

Reecha Mall

So first is my first advice is that remove when you hear safely, don't translate that as slowly in your mind. It is not the same thing.

Okay, got it. Second thing is most of these laws have been in place for decades and they have been. People have created frameworks around them. Do not reinvent the wheel. Figure out who has done it well and copy. And so you will be able to do it fast and do it quickly. And the other thing is that even then you are at that place of scale where you only need to show to the authorities that you are doing it.

Your intent is right.

Speaker 3

Right.

Reecha Mall

So that is good enough in that space that you are thinking of it as customer value, you are figuring out what is the best way to do it, who has done it outside of you, and then you're just copying that thing. That is good enough for most regulatory bodies. So again, don't gold plate that as well. Like when we do that for any other feature, like perfection is not needed at that time.

8020 rule applies here too. Okay. Once you do that and then now you are, you have also created a moat around yourself because other companies are not going to do that. So they are not going to catch up to you. So not only have you, because another thing which I think about in terms of product strategy is everything which you are doing has an opportunity cost. As in you are not doing any other things which you could have done. So whatever thing you are doing, it should create a moat for something like it's not just adding that value, but also that other people will not be able to do it because they think safely means slowly.

And they think that if they have to do some regulatory compliance thing, they need to do 100% of it, not 80, 20.

Speaker 3

Right.

Reecha Mall

And so now what we have done is that we have taken the complex thing, we have filtered down to a complicated thing and you can now scale to that next level and then you apply the same principle again to the next level.

Leszek

Got it. One thing that actually came to my mind is that there is an overlap between customer value or client value and the moat. The overlap is huge. And I think you also like to your point about, you know, that it's actually building a moat. That's at least my takeaway from this as well. I'd like to talk about one thing which is in your opinion, why are large companies, particularly those on Nasdaq, avoiding the fintech and intratech space or basically or not exploiting those spaces to their full potential? What are they missing out on and why?

Reecha Mall

So one thing, and this is again my theory, but I like a lot of theory backed by a lot of data, is that most of the tech products which we have built in last 20 years are all about distribution as in scaling for adoption or growth. So if you think about what are the top five companies, Facebook, Google, they have made the thing which was available to a small group of people, now available to everybody. So most of the innovation which has happened in last 20 years has happened on distribution front. So they apply the same model on fintech as well. We built the layer of distribution so UI layers for fintech, hard UI layer for move paying money, peer to peer payments and all. They are not going to the next layer of where the real thing happens. And so that, that is the first reason why they are not exploiting because their mental model is distribution at scale is technology advancement which makes sense in terms of communications tools like social media and LinkedIn and all that doesn't make sense in terms of Fintech or Insuretech because in fintech and Insuretech the transaction and the usage of the product values is more than the distribution of the product.

Because there is another concept in product in terms of are you growing the pie or are you capturing the pie? So for example Uber, the Uber taxis grew the pie as in I wasn't taking taxis for 10 minutes thing and now I'm taking it. But that is not the model for UberEats. I can only eat three times a day. They can't make me eat more than three times a day.

Speaker 3

Right.

Reecha Mall

So there is like a upper limit for Uber eats product. Even though their model is exactly the same, there is a limit of growth they can handle. What they can do is create efficiencies in the system to capture more value. So your product model is different in both. It took them a lot of time to figure that thing out. And that is the difference between communication products and which are essentially distribution and network model product versus Fintech and insuretech product. Because fintech and insuretech products, a person can have maximum two or three bank accounts.

They're not going to have hundreds of bank accounts, but they're going to do hundreds of transactions. You can make the things which are happening on cash happen on credit or online transactions more frequently. So that is a mental model which is missing how to increase the usage of something in terms of creating value and incremental value and habitual value versus just capturing attention and distribution. And so there are companies who have figured that out that they need to try that. But then the third layer of complexity is that you need to now work with legacy companies to figure out how the foundational rails work. So for example, in fintech, in money movement, even today the ultimate money movement happens as a mainframe file which gets submitted three times a day. And most of the western world uses this thing in India and I think even Africa that new API driven models are coming in.

But I see that a lot of tech companies are not interested in working with the governments to revamp that system. And it is becoming more and more like rather than collaboration, it is becoming like it's a conflict. And until that they figure out that they need to work together with these legacy companies to revamp the Swift model or that like how money movement really happens, it is just going to be a distribution gain and not at the layers of that change.

Leszek

Got it. I mean these mental models are fascinating. Thank you for sharing those. But I'd like to change the topic a bit and talk about building and scaling teams, especially in high growth environment. What are your strategies here specifically? Balancing growth and with maintaining high performance. It's not an easy task.

Reecha Mall

One thing about the team is that leadership is very important in this. And I think for any company which is around 50 to 200 employees, that three layers from the CEO to the C suite and that whether it is the SOAP or VP layer, the three layers, they need to be the. They need to be leading. Like real leading as in I don't want to hear I have got your back. Like if you are leaders, you need to have fronts of your team, not their backs.

Speaker 3

Right?

Reecha Mall

Because what is the commonality in teams like that? These are driven people who joined your mission because they believed in you.

Speaker 3

Right.

Reecha Mall

If you are in a small startup, who is joining that company and working overtime growing that company? It is not people in their 40s and 50s who have families to take care of. It is young, hungry people who want to learn, who want to grow, who want to have an impact on the world and you need to channel that energy.

You don't need to be a damn. Like there is a mentor model which I use is how can I be a channel then? Rather than dam, rather than telling them that no, do not fail or you can try anything as long as we don't fail.

Speaker 3

Right?

Reecha Mall

That is one of the things which a lot of leaders do. You're free to do everything as long as it is reversible. Door. How would they know what is a reverse one way door or two way door? As a leader you need to explain that, what it means for them. So I'm going to give a small example. If you are a leader of a team and each time somebody comes up with an opinion which is contradictory to you, that person either is assigned to something which is irrelevant or slowly phased out of the organization.

Even though you tell the organization that honesty and transparency and speaking truth to the power is our culture. But if people are observing that is not how you're behaving, that will become the culture, right? So all that to say is leadership is very important. By leadership I mean you need to be leading from the front, you need to be learning from the front, you need to be growing from the front. You need to tell people whatever principles you're setting, what is an example of that? So when I hear this thing a lot in terms of all these CEOs have their frameworks, right? Like Amazon has this bar raiser or one way door and two way doors, but they don't explain what that means.

So in some organization just voicing a contrary opinion is like a one way door. Like once you have said this, you are not going to be phased out of the organization. And in some organization, like even in Uber where you can actually write do something which is illegal and it is still two way door, like you are still safe, right? And people see that in the behavior of leaders and impute what it means. They don't impute what it means just by. By what you are telling them. So if you're really interested in scaling your organization, your actions should follow your words.

Leszek

Walk the talk.

Reecha Mall

Walk the talk. Yeah. And so if you want people to learn, you need to show how you are learning. And learning means you are failing. So if you are not failing, you are perfect. You are telling everybody that they are not allowed to be calm. Learning or failing.

Leszek

100% agree. Richa, thank you very much for today's conversation. It was very interesting to get your insights. Thank you for sharing your time and your wisdom and the mental models. Thank you very much. It was a pleasure.

Reecha Mall

Thank you.

Speaker 3

Better Tech Leadership Powered by Brain Hub. Follow les Schick on LinkedIn and subscribe to the Better Tech Leadership newsletter.

Reecha Mall

SA SA.

‍