Women Leaders at MongoDB: Why Kanika Khurana is Leading with Transparency

March is Women’s History Month. Our women leaders series highlights MongoDB women who are leading teams and empowering others to own their career development and build together.

Kanika Khurana, Technical Services Manager, shares how she leads with transparency, the importance of taking smart risks, and enabling team members to have the “courage to fall and rise again”.

Tell me a bit about your team.

I oversee the Cloud Technical Services team in India. Our team provides technical advice and support to MongoDB customers by acting as subject matter experts to clear blockers and recommend best practices, enabling customers to build next-generation applications.

What characteristics make a good leader?

I think that a good leader comes to know and value their employees' unique skills and abilities. They determine how to capitalize on their team’s strengths and tweak the environment to meet their larger goals. By taking the time to understand each employee, a great manager shows that they see their people for who they are.

Have you faced any challenges as a woman growing your career in leadership?

One of the criticisms I’ve faced over the years is that I’m an emotional thinker, which somehow hampers my decision-making. However, while I tend to be a more relationally-oriented decision maker, I’ve used this characteristic to help advance my career. Listening to and involving team members in essential conversations has enabled me to make more logical, reasonable, and healthier decisions.

What is the biggest lesson you’ve learned throughout your career?

The best leaders are transparent. They admit mistakes, ask for forgiveness, and make bad situations right. These “failures” aren’t signs of weakness but rather strengths. Mistakes are inevitable, and what we learn from them is what determines the course of our success. Trying to look perfect isn’t authentic, creates stress, and models unhealthy perfectionism. Through transparency, you build stronger relationships and an environment where a commitment to doing the right thing impacts the culture and the bottom line. The best thing you could do is to offer an Eden to your team, which allows them to grow and thrive, rather than creating an environment where the fear of making a mistake overtakes the courage to fall and rise again.

What’s your advice to other women looking to grow their careers as leaders?

I advise other women to be brave and take risks. Sticking to the safest option can be tempting, but you are unlikely to achieve growth and innovation if you’re not open to new steps or strategies. Of course, risks should be calculated, but carefully considering risks can progress your career. Be a little risky, take a leap, give it a try, speak up, and be kind but convicted in your effort to take a seat at the table.

Join us to make an impact on your career and the future of technology. Find open roles on our careers site today.

← Previous

Submit Your Nominations for the 2023 MongoDB Innovation Awards

Nominations are now open for the 2023 MongoDB Innovation Awards. These awards aim to celebrate and recognize organizations that dream big and are pioneering new ways to use data, expanding the limits of technology, and enhancing their businesses with MongoDB. We invite you to nominate an organization that is building something dynamic, interesting, or innovative with MongoDB. Submit Your Nomination Past recipients include 7-Eleven, American Airlines, Barclays, Bosch, Comcast, Epic Games, IBM, LinkedIn, Pioneera, and Sogei. Read more about last year’s winners here . This year, we’re excited to offer a robust prize package. Our 2023 winners will receive*: An Innovation Award trophy 10 passes (per organization) to a MongoDB.local event of your choosing Inclusion in the MongoDB Innovation Awards announcement materials and social media Digital badge to display all year long A customer feature story on MongoDB.com MongoDB Atlas credits A tailored MongoDB Day, designed to enable your technical team members to deliver solutions better and faster Submissions will be accepted through April 21, 2023 and winners will be notified by the MongoDB team by the end of May 2023 . Read more about each of the award categories below. Award categories Optimizing for Impact This will be awarded to an organization that realized tremendous business benefits by leveraging MongoDB, with an impact on its bottom line (time savings, cost savings, and/or reduction in operational complexity). Industry Transformation This will be awarded to a change-maker who moved their business to the next level and disrupted their industry by identifying new technologies, applying new skills, or increasing operational efficiency. Inspiring Innovation This will be awarded to an organization that is using MongoDB to make a better world possible. They are creatively expanding the limits of technology to solve societal, community, medical, or educational challenges. Building the Next Big Thing This will be awarded to a small- or medium- sized business that has been building its core offering/service on MongoDB Atlas from the beginning. They are leveraging MongoDB's data developer platform to build and scale some of the world's most innovative projects in data. * View terms and conditions We look forward to receiving your nominations!

March 20, 2023
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024