Welcome everyone to the scaling up a modern digital business to reach a million users topic by Sneha Prabhu, a marketing delivery partner at ThoughtWorks and Archana Ravi Kumar, lead engineer at BCG Digital Ventures. Without further ado, over to you Archana. Hi everyone, really nice to see everybody joining us today this afternoon to talk about scaling digital platforms.  Like mentioned I'm Archana I'm a lead engineer. I've been in the industry for around 12 years and I've had experience working in different technologies and different domains building platforms. Prior to working at DCG Digital Ventures. I used to work with Sneha at ThoughtWorks Technologies and what we're going to share today is our learnings and experiences while building a platform for a client of ThoughtWorks. Over to you Sneha. My name is Archana. My name is Sneha. I play the role of market delivery partner which essentially means that I support a lot of our clients based in Southeast Asia and Australia and ensure that we can deliver from ThoughtWorks India. And thank you all for joining us in like Archana said yet another zoom call where it feels like somebody's going on and on and we have no idea because none of your own video we don't know if you're able to understand us or have any reactions. So just feels like what we're saying is going to eat us so please do keep the chat and Q&A coming so that we know what you're thinking. So Archana and I are very lucky we've had the chance to work together on a lot of different projects. And we're here to talk to you today about scaling digital platforms, something that we've done a fair bit of in the last few years, and we have lots of takeaways from those experiences. And we worked in one such platform together, which is for an inshore tech company, which we refer to a lot today as our example. And Archana will set some context on this platform in just a little bit. Now the idea of modern digital businesses is not new and I'm sure you're all familiar with them. In my mind I think of all digital businesses as being one of two types they're either digital natives like Amazon that started as a digital first business they didn't move from an offline model to an online model they started off as a digital company. And then there's those businesses that have been in the industry for a long time they excel in their respective fields, and they likely have a lot of physical assets they have a physical presence and engagement with their customers. And because of the threat of being overtaken by the digital native disruptors, they need to urgently ensure that they move to a digital model in order to continue to survive. But wanting to survive may not be the only driver to turn to digital. In order to reach millions more users digital platform is often the right way to go which is why we're talking to you about scaling platforms today. Our example platform that we refer to a lot today is the one that we built for a digital first company, which was built to disrupt a very traditional business the insurance industry. And you all have heard of digital transformation I'm sure even maybe a little bit too much in our minds digital transformation is the journey that a company undertakes to transform a traditionally run business to a digital business. And the most common example of this which also I'm sure you've heard too many times is is Netflix. So they're a company that started out as a physical service and their service was to mail out physical videos to their customers. And the competition also offered very similar service. What Netflix did very cleverly was to rapidly move to a digital business model by leveraging you know technology in the form of streaming that was available to not just change the game entirely but to also reach millions more customers than they could before like you and me. And their biggest competitor blockbuster did not move fast enough and eventually they went out of business so every business today is either trying to survive or is urgently trying to scale so that they can capture a much larger segment of the market. Like I said we're going to be talking to you today about an inshote a platform that we built and we'll use this as an example to share our learnings and Ashna could you share a little bit about our example. Thanks Neha. So like Neha mentioned a lot of the premise for the stock is based on our experience working for an insurance startup in Singapore. And so they were a traditional insurance company like Neha mentioned so you know they started off by being a brokerage firm, but they also were like smart enough to understand the power of technology and to be able to leverage that to deliver a digital platform. So the business model when they started off was very simple. So they were providing group insurance to employees of different companies. They had been in the market for about three years. They had 600 to 700 companies on their portfolio like small medium enterprises also called SMEs on their portfolio. And they had about 7000 end users on the platform so it was a pretty good journey for them. So what they realized was that in order to provide a differentiator for themselves in the market and they wanted to kind of give the power of choice for insurance back to the customers. So you know they wanted to be able to allow so they noticed that in the market there were different types of users for insurance. So if it's someone who's just starting out their career and they are like super fit or they don't have any known health issues, then they might want to use their insurance money to be proactive about their health and not reactively cover it using insurance. So something like a gym subscription or a benefit package or healthy meal subscription was something that would be more useful to such a person. Whereas someone who had like a history of health issues or who had dependents to take care of would be more interested in a comprehensive insurance coverage. So they saw that there was this difference in how users approach insurance and there's obviously like a lot of money on the table when users don't use their package right. And so they wanted to build a platform that would give the power back to the users, but where they were they were still pretty much a brokerage firm with the digital platform so they did have a few issues on their plate. And so in their traditional brokerage model they were still going after the clients so they would you know do a lot of all the phone calls reach out to these SMEs to sell the platform to them. And each of these calls in addition to the sales cycle also had like a lot of operational overhead because you know the time taken to onboard an SME was also about four to six weeks because of how the platform was set up. And so they were facing quite high operational overhead and they understood that they had to kind of reduce this to be able to go faster and build this like vision they had of giving the choice back to the users. And another thing that they had which kind of differentiated them from the competitors at that point but which also put a constraint on how fast they can evolve was that they had a promise to deliver a bespoke product to each one of their customers. So you know, and clients could come in with different requirements and they had a platform, which was sort of geared to deliver on these requirements. For example, they built a generic platform with a lot of configurations that were stored in the database.  The SMEs brand or logo should be shown on the UI, which is pretty standard like white labeling requirements, they were able to meet those, but they were also able to even do like complex customization for business logic. So what should they use a land on or another example is, so when you join a company, you would get insurance coverage from the company right. But depending on when you join in the financial year your coverage would be prorated. And there would be some industry standard based on the geography of how the proration would work. But when a large SME was brought in they said that for their employees they wanted the coverage to be prorated on a half yearly basis, which was different from like the standard monthly proration that was in place. So then this had to be made like a configuration that was stored in the database, and you know so the logic changes and how the users interact with the application changes.  And because all the configurations were in the database, the UI took like a lot of time to render so it was actually poor customer experience also. And then the last thing that they had was that because of how their evolution had been they had traditionally been a company where business leads technology. So a lot of business requirements would get thrown at the engineering team and they would like scramble to build a product, which meant that the engineering team had like no breathing space to think about how to make the platform better how to like you know build for the future vision. And so some of the things like slow onboarding time four to six weeks was because you know like all these configurations had to be added you have to test them, make sure it doesn't break for anybody else. A lot of it was manual. And, and so it took like quite a long time to onboard these users. Sometimes they clients would say hey, how do we know what it would look like eventually. And so we had to like build a POC show it to them and you know make sure they were happy before they could be brought on board and so on. So they have they were facing quite a lot of problems but they really wanted to be a true digital disruptor in the market, which is kind of the time we came in. So we worked with them and then fast forward to like 11 months later, we had worked together to build like a new set of things. So where we ended up was we changed the business model and we launched a new model called a distribution model, which had reduced cost of sales and reduced operational cost. We will, Sneha will talk about this a little bit in detail in one of the upcoming slides but essentially we just changed the model so that we didn't have to go after these small medium enterprises anymore. But instead we could sell the platform to larger companies who would then take care of selling it downstream to small companies or to end users directly. So when I talk about distribution clients, these are large companies like banks like standard chartered or one of those companies who then became customers of the startup. Then they also kind of changed their mindset of being like a traditional brokerage firm and they started thinking and acting like a product company and we built a platform as a product. So it was a platform on the cloud and so we were pretty brutal about making sure that the requirements were unified they were not it was not a very generic product. There was still possibility of configuration but only things that made sense. And so we unified requirements as much as possible we reduced and kept the configuration to a minimum. We removed it from the database we made it like environment configuration so it was easier to like figure it out and the platform didn't like have poor performance because of configuration in the database. But in case a new user a new client came in and asked for like highly custom configuration we would not turn them away instead we just asked them to pay a premium for that configuration so that the effort justified the cost and so on. And finally, I think both tech and business they started like working hand in hand with each other they really understood like the power of collaboration. And business understood like the power of having tech on board right from the start so that you know we could work creatively on some of these problems like reducing the onboarding time. And for some of the smaller clients we started rolling out like a self service model where the clients can kind of choose what they wanted and it was automated till the end without the need for like manual configuration manual testing and so on. So it was a pretty interesting journey over the period of 11 months and I'll now pass over to Sneha to talk about how we started where we started how we ended up here and what our journey was like. So we worked on this platform for 11 months and we brought it to a point where it could rapidly scale to more than a million users. And we learned a lot from this journey, the overarching lesson for us that we took away from it is that this journey is never linear. There isn't a clear set of stages that we can call out right I have to go one after the other, but a lot of different things have to happen in parallel it just can't be sequential. And also a lot of this can't be templated, you know, I can't abstract our experience into a set of steps that you can follow in your context and expect the same results. It's dependent on the context of the industry that you're operating in the context of the organization you are today and the kind of organization you want to become and much more. So there is no silver bullet to making this work unfortunately. And so we're not going to try and share like a magical formula with you here today. What we do want to share though are some principles that we've taken away that we think are relevant in many different contexts. And so we thought that these principles are a little bit profound so from now onwards we start to use some profound images in our slides. Next one please. So we'll start with how we helped our client shifting focus to what users actually want. Now all of us, I'm sure have insurance providers, but we don't like to interact with them very much. We actually hope we won't have too many medical situations where we have to work with our insurance providers a lot of every hoping we don't have to work with them. So they're not a business that you want to keep engaging with. But that's not a great place to be if you're an insured tech business that wants to scale and wants to be an essential part of their users lives. So what we started to do was to shift the positioning of this business to shift the focus from being an insurance provider to being a company that helps users focus on their health and wellness instead. So we believe that this is something that users cared about a lot more. And so we started to build a platform out as a health product where users can go in and they can go through a health assessment through a fairly intelligent questionnaire and we give them a health score. And then we'd give them your tips and content to help them improve their health scores. The idea was that, you know, we gamify this enough that they'd want to keep coming back and checking if their score has gotten better. And this would also lead customers into the organization shop, which is the purchase flow, where users could buy health products or gym subscriptions or meal subscriptions or whatever it is that the app recommends based on their health score, which will help them improve it. And if despite all of this preventative care that they're taking of themselves, if they still need to use their insurance, they could still have their claims processed to the app. And so while they're at heart still in insurance company providing insurance that can be used for many different purposes, they ensure that they were putting the focus on preventative health care, proactively improving health, so that users are much more likely to engage continuously and would like to do so, rather than, you know, using it as something that they don't have an option to do. So that's, that's us trying to understand what the users actually want and being built and being able to build for them rather than what the business wants. Now let's imagine for a moment that you are the, I think we've skipped a slide. Let's imagine for a moment that you're the publisher of a newspaper, and you're distributing this newspaper yourself. You probably distribute to at the most maybe your neighborhood if you were doing it by yourself. And if you want to increase the reach of this newspaper, what you might do is then hire a bunch of delivery guys right. And that's exactly what we did with this insurance business. Instead of having to onboard each smaller medium sized business and sell the product to them. We created a new layer of consumers and I was referring to them earlier, these are the people that we called the distributors. And what we did was to create a platform that will help them distribute the product to multiple other customers. Now this customer, this distributor is generally somebody who's a very large organization, maybe a bank, maybe a telecom company, who already has a relationship with many smaller medium businesses and by, you know, that also a relationship with all of their employees. For example, I work at ThoughtWorks and we're, you know, we're 3000 people in India. And I, my salary account is with Standard Chartered because ThoughtWorks already has a relationship with Standard Chartered. So if this insurance company was trying to sell the ThoughtWorks, the sales cost would be really high because if you sell to multiple ThoughtWorks, and with each sale they get about 3000 users, I think that Standard Chartered gives them access to so many more organizations and as a result, so many more employees, tens of thousands more people through one sale. So the idea was really to leverage, you know, those relationships that we already had. And what's in it for a bank like Standard Chartered, you know, it's just that they could then use this application, you know, to white labeled, is branded with their organization's branding, so that they can now start to offer something else that they can cross sell along with salary accounts to a company like ThoughtWorks. They can now actually offer insurance as a product to the same customers that they already have previous relationships with. And so, you know, often when we think about expansion, we think about engaging a customer segment that we didn't previously engage. But rather than that, if we engage a customer layer whose reaches, you know, can multiply our own, it's often a much better move to make in order to scale. Next one, please, Archana. Something to keep in mind when we're talking about scaling the business is to note that, you know, until this point, the business has clearly done something right, right, if they're ready to scale now. They've, you know, they have had a good idea, they've validated that idea, they have a clear business model, they have a pretty good customer base. And that's why right now they primed for scale. And it's important to, you know, continue to keep the business running and to keep that customer base happy and unaffected by new changes that we're making. So it's important for the team that is focused on growth to not operate outside of this ecosystem, but to actually work with the business priorities, right. If the priorities to keep the lights on to keep these customers happy and to keep adding value to them, we've got to continue to do that and adapt that into our roadmap. And for the InsureTech business example, it was important for us to keep the business running and at the same time, acquire at least one such massive distributor, a standard chartered kind of distributor, so that we can validate the concept of the distribution business model before we start to invest more in it. So as a product team, this was something we had to keep in mind that there is going to be two sets of customers that we need to keep, one that we have to keep happy and unaffected and the other which where we're trying to validate a new idea. Next one, please, Archana. Very early in this project we started to put together a roadmap, but before it we started to create a lean value tree, starting with articulating a very clear vision for the platform. The leadership of this company, their vision was to be able to expand and influence employees to take control of their own health and in turn take care of their family's health and in turn improve the nation's health. So the founders long term vision was to ensure that Asians are able to prevent common health issues like heart disease and obesity just by enabling people to take control of their health and take preventative healthcare. We started from this vision because we thought it was a grand vision, it was a good one. And then we started to break this down into goals, which is what you do with the lean value tree. And we broke this down to goals that map to user segments, right? For us, the biggest target segment was the employees who will avail of the insurance services at the end of the day. But there's also different types of employees. So we had to understand different personas and do a bunch of research to really understand their needs and their behavior. And then we started to put down goals, right? Goals for those users, not our goals, not the business's goals, but the goals that those users have. For example, an employee's goal might be that they want to be aware of the status of their health, right? So that they can decide what they want to actually do to improve their lifestyle or what they want to maintain as is. So we put measures of success on each of these goals so that we can track whether, you know, what we're building is actually helping them make progress towards that goal. For example, you know, how often a user engages with the application to check their health score might be a measure that we keep in mind, right? We might also check if they're able to make positive changes every time they come back to the health score, has the health score changed positively? That might be a measure. Another example might be, are they able to make consistent changes to their health score, right? Is it moving in a positive direction, but is it also sustainable? So these were some measures of success we could put on that user's goals. And that helped us then come up with hypotheses. If we were to help, you know, this user get to a goal, what might we build in order to get them there, right? So an example of a hypothesis might be that, you know, we believe that allowing people to take a health assessment and see their health score will help them engage with the application more often. It's a very measurable thing. It's something that we can build a feature for and see if, you know, it actually works. And if it doesn't work, it's okay because we can backtrack very easily the delta of changes so small that we learn from this experience, we backtrack and we do the next thing, which is the next initiative. And so this way, you know, we're able to build a very dynamic roadmap, right? That's what the lean value tree helps us do, is to not have to set a roadmap in stone at the start of this journey and then follow it to the T, right? So there's a lot of things change along the way and you learn a lot about what users really want, right? So lean value tree structure helps us keep that vision intact, but also helps us be flexible on what we build in order to get there. And what's critical about that is then you're, you know, developing an experimental mindset, which is exactly what you want in order to make this so dynamic. Yeah, so when we start talking about experimentation, I think at that point it kind of becomes the owners of the engineering team to start thinking about what are the tools and frameworks that we need to put in place to enable our product team to run these experiments that Sneha was talking about to be able to have a roadmap that is so dynamic and is able to adapt and pivot as the users needs change and evolve, right? And so for that effect, what you're looking at here is a classic build, measure, learn cycle. So we did something very similar. Our whole platform was built and deployed on Azure, but all the cloud providers, major cloud providers like GCP, AWS and Azure have comparable features, so it doesn't matter. But we used Azure and then we started using Firebase Analytics to start tracking our user behavior and metrics. But again, there are comparable tools on each one of these platforms, there's other tools like segment and others, which you can also use to start tracking your user behavior and other product metrics. And by looking at this data, we started like being able to visualize how the users are interacting with the system and that gave us like immense learnings about what are the things that the users need to see more of. But in order to enable rapid experimentation, right, we needed to have a path of being able to release features very rapidly into production, but also very confidently. So we started using feature toggles, developers in the audience who have been working in the industry for a few years would definitely already know what feature toggles are. But they're just like a very simple mechanism that enables you to choose selectively what features to enable or disable on production. Traditionally, we've used these to, you know, if you're building a new page or a new feature, let's say, you could enable it on test environments, but you could turn it off on production. So until you're happy with what you built, you can choose to turn it off on production. And once it's ready and tested, you can enable it and users will start seeing it. So you could use something as simple as a feature toggle framework, which can also be, you know, just configuration in your code base or it could use a sophisticated framework like Firebase remote config or AWS app config.  But you could also extend it a little bit and use tools like LaunchDarkly or others, which help you do like roll out features to an experimental set of users, maybe like, you know, the users who are more savvy, who are more used to the platform to kind of get like early feedback on what you're doing and how it is fairing with users. So one example is that we found that when we started using the platform more than we started tracking user data, we realized that in the old platform users were traditionally using the platform just to file claims, which was on like the last day of the month, which was the deadline for claims and that is when there was like a lot of traffic on the platform. And that's when we saw like issues arise and you know, peak usage happen. And we also saw that some of the health features that Sneha was talking about, we could see like how users were using it and whether like the gamification helped and if that attracted more user traffic or not. Depending on that we could you know choose to find you not flow and get more users on board it. Once this was in place, we actually had to deal with the actual platform itself and there was this like small little problem of the existing platform not scaling fast enough. And so what you're seeing here is a comparison of like the before and after so they, the team, the startup team had started by building a monolith, and which was the right decision to make at that point right. So maybe before I go into details of the slide I should like put a giant disclaimer and microservices update, but I think the usage of microservices, they're not a silver bullet for all problems. And so the usage of microservices depends a lot on the maturity of the art to be able to deal with like the infrastructure requirements and CI CD requirements and also whether it's really like it has good ROI for the amount of work you're going to put into your platform and services right. But there is also a point in time in the life cycle of many startups I've seen where they are ready to scale the business is ready to scale and the platform is unable to scale. And that is usually a good indicator of at least having to break it down into smaller components that are more manageable. So for this company the problems that we were seeing firsthand was that like we had some anecdotal evidence that when 7000 users were onboarded and about like 80% or 90% of those users were trying to use the platform, it started to crash. And it's not really because the platform didn't crash because of the monolith, but because it was a monolith it was hard to understand what the problem was and fix it. And the other thing that we noticed firsthand was that developers were really scared to make changes in the platform because they didn't know if I change this line of code, I don't know what else will break and that was the state of their mind, right. So if you're at the verge of like a product vision that wants you to go faster and faster, but you are stuck with this platform that is making you really feel less confident about the changes you're making, then it is time to break it down. So we broke it down into a series of microservices. What you see on the right side here is the services that we had. You can see the contrast in the number of lines of code. So we went from like a million lines of code to services having like a few thousand lines of code, right. So we did retain like one insurance engine from the old monolith I'll talk about it later. But the rest of the services were pretty small, which meant that we could add features fast, we could make developers owners of each one of the servers so they knew what was happening. And the number of issues that we found on production drastically reduced. But even if there was an issue, and it didn't, it wasn't very hard to fix it like our recovery time was quite low. But this is an example of what we did by breaking down a monolith or microservice, but depending on the platform that you're working on, maybe your services are okay, maybe it is a front end that needs to be broken down maybe micro front end is the pattern that you need to go after. So it depends on what your problem at hand is. And so you should just take the context into consideration before deciding. So once we had like a platform of microservices we were going fast and we were able to experiment and launch new features. We really need to start thinking about what would we do in case there are any issues. And if you're having a platform that reaches a few thousand users and your reaction recovery times are pretty low, it's okay, maybe it's okay you can deal with it. If you're having a platform to reach a million users then you need to think about observability monitoring and recovery with a different lens. So it's a really good book called Accelerate which talks about like four key engineering metrics that one should look at and one of the metrics there is mean time to recover or failure rate, like recovery rate from failures right. So where they were when they started it was like, so we roll the developers would roll out a feature into production, and they'd go for a few months, we don't know who's using the feature whether it's being used or not if there's any feedback. Then suddenly the end users using the feature would find some bug maybe something's not working as expected or the systems crashing, and they would raise a bug report which wouldn't actually directly come to the developers it would go to the call center because they call up the call center. The call center folks but then reach out to the developers, then the developers had to debug the current weather problem was fix it and then release a fix to production. This is a big cycle. And then if you think about it one step more, and if you have a release process and you know you're set up to go live only once in three, four to six weeks, then no matter when the issues found it's going to take at least now three to four weeks to push the release fix out right. But in a platform that's rapidly evolving that's a no go so we actually double down and focused on some of the tools that will improve observability and traceability for us. So we started using Grafana tools like Grafana sentry to start looking at what are the issues happening. So at any point in time we could have a snapshot of how the systems behaving and also how the users are behaving. How many API calls are made, how are the users interacting with the system and so on, and we hadn't set up alerts but that was in our roadmap so you know if anything is going above or below threshold then we set up alerts so the engineers would get notified they can look at it immediately. We also focused a lot on traceability to make sure that because especially in a framework of microservices you need to be able to know which service has the problem and so traceability was very key and we double down on that also. We leveraged automated testing a lot. We made sure that our testing was very robust so we had all the components front end and back end components had about 90% test coverage at least. And then on top of that we had API tests on top of that we had some higher level integration tests. We also had automated UI tests which would test the automated UI tests were not exhaustive, but they would test like the critical path of the flow. So that we had at least confidence that the end user will be able to use our products without an issue like the flow that 90% of the users use, we tested to make sure that that was okay. So you know every comment that was made would go through this pipeline of tests if anything failed, then the build would fail, but everything passed, then that meant that that was a suitable build that we could potentially launch to production. One other thing we did was like from day one we set the path to production like we defined and dictated what the path to production would be, and we set a process so that we could release to production every day. A release to production every day is quite a lofty goal. Sometimes it's not even necessary, but we set this in place because we knew we wouldn't have features that go live every day but we knew that in case there are issues we need to have the confidence of a pretty robust pipeline that can push the fixes out. So by the end of 11 months we had a process and the tools in place so that we could actually push the changes to production every day, which kind of guaranteed to us that in case there is an issue we have a pretty good framework that will help us recover from the issue under a couple of hours. So now we'll switch tags a little bit and so we have a pretty good framework and you know everything is going as according to plan, but if I actually rewind a little bit and go back to like the start of the product setup product build, then we were talking about okay what is this platform that we want to build. There were a lot of interesting questions that came out you know, a lot of the questions were about okay. So the product was actually they had a presence the company they already had a presence in Singapore, they had a product in Singapore, China and Hong Kong, and they were looking at expanding to geographies in that region, like regional expansion right. So a lot of the questions that came out were like, how do we release to different geographies, can we take the same product and release it and launch it in Indonesia or Philippines. What do we do because data privacy data residency laws are different to these countries. What does that mean to our build. And then there were like some really crazy ideas about using different vendor integrations in different regions, like, for example, in China, I want to integrate with labs, so that they can directly upload test results to our platform, which brings like a whole different thing into focus right like we started to we had to think about like these are confidential health records how to maintain security privacy and what are vendor integrations like different geographies might have different types of integrations are these going to be via data dumps data things we don't know. And then they talked about can we make it an e-commerce platform can we start selling health products on this platform right. The ideas would stop coming and it was really great, because it was everybody was like really curious and really excited to see the extent this platform could grow into. Because as an engineering team this was also really interesting to know because some of this gave us an insight into where the product vision is headed. And we could actually plan to scale some of these ahead of time and some of these later in time. So for example, the different geographies question we actually had to take it into account right at the start because if you had to change a cloud provider nine months after we started building that's going to be a lot of money and effort. But some things like vendor integrations or e-commerce products we could actually say with confidence that you know that's actually just like building a new feature.  But it was actually really important for tech and product and business to be engaged in this conversation together so we could you know plan to scale in different phases in different speeds. Having said that, that kind of like led us to thinking about the right technology choices to use. So, you know, the monolith that I spoke about earlier that was built in .NET and there's a lot of bad rep for .NET but I like .NET and we decided to continue using .NET because existing developers they already was built in .NET we could use their help. We could actually salvage an insurance engine which was in .NET and reuse it repurpose it in the second part of the build. But we also were very clear that it should not like kill innovation or modern idea so we you know we pivoted a little bit we used .NET core so you know we could do like containers we could automate it and deploy it to cloud with very less hassle. We used containers because like I mentioned before we wanted to go to different geographies so instead of like a full dependency on Azure as a platform we use Kubernetes to reduce that dependency. But we also it also helped us have like very fast very scalable deployments and we used infrastructure as code so that we could automate at scale for a platform at scale. So depending on the context I think it's really important to choose the right technology that will help us scale at the right pace. Now that the right tools are in place and the right technologies are in place we then started thinking about what is the right sort of teams that we wanted to build and I'll hand over to Sneha to talk about that a little bit more. Thanks so you can do everything right friend you can have a great roadmap you can make all the right tech choices, but none of that will matter unless you've got the right team in place. And the way we split up the team was also geared for scale. Each team was completely cross functional so that they could be independent and every team had a very clear objective, which they were supposed to go after, which was mapped to a user goal from the lean value tree that I shared earlier. So we can split out for example a health team right and their objective was to make sure that users are frequently engaging with the app and checking out their health score. So the health team had complete autonomy to experiment with you know how they what they want to build and how they want to build it in order to get to that objective. And we measure the effectiveness by tracking the measures of success that we put against that goal in the lean value tree. And other team was responsible for shop which is the purchase flow, making sure they were recommending the right products and enabling customers to complete the flow well. And a third team was called the claims team whose job was to collect and process claims efficiently and integrate with you know third party claims adjudication services and processing time for the claims was their measure of success. And we had other personas that we had to build teams for which I've not mentioned so far employees were one set of users, but we also had other users in the form of you know HR admins right and an organization when a lot of people joined the company you want to make sure that those people are onboarded on to this insurance portal, or when they leave their, their off-boarded right. So we had to build a team that focused on the HR admins side of actions. Similarly, we had a customer support admin, which was another persona and the team building that portal was measured by how quickly it was possible to resolve a customer's like a query that was raised. We also made sure to keep our teams very reconfigurable so that if an objective changed and it will because the LVT was designed for you know a dynamic roadmap right so objectives can change. We have to be able to reorganize the teams very quickly and and you know still make them as effective right. So halfway through this through building this platform the inshottet company realized that we've been focusing so much on employees that we missed out on a very large customer segment which is these employees dependence were covered by the same policy. And so then they said we've got to build an app that dependents can use because there are some aspects of the flow that apply only to dependents it's a subset of the larger employees flow right the user flow. So what we did was very quickly spin up a team right we got two people from the health team two people from the claims team two people from the shop team. And because they already had context of what was built and so they could very quickly reuse the blocks of code that we could put together and create a dependent app and we created a dependent app in about six weeks because that context was already there that we could leverage. So in this way you know we were able to keep the teams very agile. And it helped a lot that you know we were also giving people ownership of objectives right so they could find the best way to get to those objectives as long as those objectives tied up to the larger vision that the company held. Next one please. Another way for an organization to scale is to hire the right capabilities at the right time. And as I said we shifted the focus from being, you know, for this business being insurance to being health tracking. So that prompted us to bring on people who had some experience in health care so at one point we even brought a doctor on. And because we were setting up a large scale and we knew we wanted to reach a million more users. We also hired infrastructure engineers right so that they can set up expandable info so that as in when we build the platform out and we reach more customers, the infrastructure can scale as well. And so we hired pragmatically and we also focused on speeding up their ramp up time so that they can hit the ground running and just putting up the monolith code base into smaller micro services is actually really useful not only for you know the reason for the reasons that I said but also for people to ramp up very quickly because they only had to get context of the code base, the micro service that they would be responsible for and not worry about you know trying to make sense of the whole large code base right. And so they could contribute very quickly after joining the team. And these measures are really important by taking these steps is quite important to expand the organization itself and be better placed to expand customer reach. So as soon as it was up, we were able to give ownership earlier on even to new hires, because they're able to ramp up very quickly have a very focused goal, and, you know, get get to quick wins very fast. And so next please everything we've talked about so far right we've talked about measuring capturing the right data measuring, you know how users are reacting and and adjusting you know our direction. So without having a roadmap that is experimental in nature so that we have you know an experimental mindset when we're when we're putting it together, and we're able to take some risks right we're able to take some bets and then backtrack if we're not if those don't pan out. We're talking about an operating model that that has to change so that we can reach exponentially more customers and the distribution model in this case was that operating model that we brought in. And part of it all is a strong engineering culture at building the right team, having clear objectives, but all of this cannot be done one at a time right these are all things that have to happen in parallel and like I said at the start. This journey is never going to be linear, you will never have a clear set of stages these things have to happen together and in tandem with each other. And that's, I think our most critical takeaway from the experiences that we've had, building multiple such platforms for scale. And with that, we wrap up today. Thank you all for listening we see there's a bunch of questions in the Q&A box. We've answered a few as we've gone but we, if we've got the time we can take some now or you can join us, I think in the Hangout. Jitain what do you think we should do. Yeah, so I think we have one minute so basically if you can answer a few portions from Q&A. Sure, sure. So you want to take the first one about the DBs. The DBs. I think I answered a few. So maybe I'll take the first one here. Critical challenges and how these were addressed during the transformation, I can cover a few Sneha you can go to. So I think there were lots of challenges in terms of like switching technology, you know, like we had questions from day one about should we use React and should we use TypeScript should we use JavaScript. And how do we carve out the microservices how do you make sure that the boundaries don't leak, you know, like how don't we how do we make sure that we add just the requisite amount of functionality into each service. But also, in addition to like all the technical challenges, we were also like, you know, grooming a pretty young team. And the client team and our team were coming together so there were quite a lot of like cultural differences and we had learned to work with each other and coexist in that ecosystem. So there were a lot of challenges that I think we overcame and Sneha anything that you would like to add. Yeah, I think in general, just as a cultural sort of thing, right, they were a company that was very business led, very domain led, and for them to think of the tech platform as the driver of their business to massive change of mindset itself. So I think that was hard to do, and we had to give them early feedback on that right show them results early so that they could see the power of that platform is able to unlock for them. Thanks Neha and thanks for sharing your experience with us today. These are really valuable, you know, session which I think people will be taking away. Thanks Neha and thanks very much. Thanks everyone for having us.


Hi, I'm Chad. I'm from the internet aka Pittsburgh This is my first time in Raleigh or as I like to call it Red Hatville You know coming here to Raleigh driving in from the airport and Seeing Shadow Man peak from behind the other buildings was kind of like Seeing that Kid that you grew up with and is now a rock star You know you're like oh my gosh because I've been an open source a while right? So it's like we have we have our logos on the tops of buildings now I thought that was something that that real companies did but we are we're there we've arrived so I want to take a little bit of time to kind of celebrate how far we've come and then Second part we'll be talking a little bit about some of the problems that Still remain an open source and then in the third and final part talk about My company Gratipay, which is working on solving some of these problems So in 1998 Christine Peterson coined the term open source Later that year Microsoft freaked out. They said open source poses a long-term developer Mindshare threat to Microsoft. I Think they were right But here we are in 2016 and Microsoft's killing it right this picture on the right is Red Hat CEO with Microsoft's Corporate vice president of enterprise open source right 2016 we've come a long way in 18 years and So obviously there are companies like red hat that have figured out how to make open source sustainable But there are still big parts of the open source ecosystem that are not sustainable We still have what's called a free rider problem with us. So the free rider problem is So many of us use this software and we assume that somebody else is paying for it somehow But oftentimes that's not the case and if you remember heart bleed a couple years ago This sort of uncovered a really extreme example of this phenomenon Open SSL was basically supported by one developer who you know was working for well under you know normal salary and Over half of the worldwide web was dependent on this one developer right who was not really being compensated Properly for his work. So that's that's an example of the free rider problem The Ford Foundation put out a report This past year Nadia Eggball wrote this report called roads and bridges It's 150 pages long and it's all about this problem of the free rider problem in open source And she calls it digital infrastructure So open source has come a long way, but we still have this free rider problem with us So four years ago. I started a company called grad a pay Grad a pay is a startup that's working on this free rider problem We're trying to help companies pay for open source software Because really the end of the day. It's as simple as that somebody needs to pay for it Companies have the money. They're getting tremendous value to the software Some of them are giving I mean a lot of them are giving back in lots of ways, right?  This is okay We've come a long way.  There's also open collective is a newer one You know, so there's this handful of us that are working on this problem head on How do we help companies fund? open-source software and pay into open-source software and The four of us right now are pretty parallel in what we offer So it really comes from kind of a consumer crowdfunding model, right? We're an open-source project can come sign up on one of the platforms and then companies can come sign up and give on those platforms And that's kind of where we're all we're all kind of in that rut right now And we need to get beyond that so what we're working on a grad a pay is Trying to aggregate so that you know if I'm a developer I have a hundred packages up on npm. You know, I don't you know I want to You know, I want to sign up for all those packages it wants to receive money if I'm a but more importantly if I'm a company I don't use you know one two three open-source packages You know, I've got a thousand different open-source packages in my technology Stack in my inventory, you know, I want to be able to fund all those at once So you can see how there's a little bit of like a B2B difference there So grad a pay itself is open-source We're funded on our own platform and we would love to have you help us work on solving this problem. Thank you