From Enterprise Account Executive to Regional Director: How Lucile Tournier Has Accelerated Her Career with MongoDB France

Lucile Tournier joined MongoDB France as an Enterprise Account Executive in 2020. From learning new technology to becoming a new mom and taking on a leadership role, Lucile has had an incredible journey over the past two years. In this article, I talk with Lucile to learn more about her experience on the Enterprise Sales team in France and how she has grown her career to become a Regional Director at MongoDB.

Click here to read this blog post in French.

Jackie Denner: Hi, Lucile. Thank you for sharing a bit about your career journey. How did you come to join MongoDB, and why were you interested in the company?

Lucile Tournier: MongoDB is my first experience working in the software industry. My previous roles were with French services companies, where I had very different experiences in terms of sales cycles, corporate culture (MongoDB being an American company), and even technicality (databases — the only stack I had never discussed).

I was certainly in my comfort zone in my previous positions. I said to myself, “If I am looking for a new challenge, why not try the software industry? Is it for me? Is it possible to switch from a services company to a software vendor?” I decided to contact Alexandre Esculier, Regional VP of France for MongoDB (at the time Regional Director) who experienced such a shift. Who better than him to answer my questions? After many discussions with him and other members of the MongoDB team in France, I was convinced and decided to go through the recruitment process.

You might wonder why I chose MongoDB in particular. Three years ago, I co-founded a market finance startup within a services company. It was an exciting experience, in a fast lane, and full of challenges and great successes. I liked the “speed boat” aspect (fast and adaptable) within an established company. For my next chapter, I wanted to join a company that was fast-paced and innovative. I really found the best of both worlds at MongoDB: An established company with clear processes and disruptive technology, all while having a startup spirit with hypergrowth and agility. I made the right decision.

JD: Tell me a bit about your experience in the Enterprise Account Executive role.

LT: Like a roller coaster. Throughout six months of intensive onboarding, I was able to quickly go into the field alongside very valuable teams: My manager, Solutions Architects, Customer Success, and Partner teams (to name a few). I started to improve my skills, sign my first contracts with major accounts who trusted me (just like my management), open up new territories, and expand existing ones.

I learned a lot about the technology, the sales process (based on MEDDIC, co-built by John McMahon, who is a member of the MongoDB board), and especially about myself thanks to a feedback culture that is at the very heart of MongoDB. Learning about yourself is not so easy. It requires being able to question yourself every single day, but what a great opportunity to grow.

JD: What makes enterprise sales at MongoDB a unique career opportunity?

LT: It is unique on several levels: The technology, the processes, the fast pace, the results of the company, and the people! Everything is amazing.

What I particularly remember is the benevolence. During my first year at MongoDB, I had the immense joy of becoming the mother of a little boy, Dorian. Starting a new job and becoming pregnant in the process is not quite what I had planned. I am grateful that the leadership team was open-minded, supportive, and more than happy for me. I was able to successfully carry out my two great journeys: Performing at MongoDB and becoming a mom. I don't think it could have gone better anywhere else.

JD: You were promoted from Enterprise Account Executive to Regional Director. What learning and development opportunities helped you achieve this, and how did sales leadership support your transition?

LT: If I hadn't had the trust and support of my entire line management, this transition would have been very difficult, if not impossible. I already had a team management role at my previous company. However, it was important for me, as for MongoDB, to go back to the field before returning to a team management position. Coming from a completely different world, how would I have been able to properly guide a team without going through the field first?

So, I honed my skills, I proved I was 100% committed, I listened as much as possible to the feedback I was given; I tried; I lost; I won. I did things differently, and I started again and again. In summary, I had confidence in my environment, and I was able to give my all while being well guided. I had regular development sessions, training, and, above all, an attentive ear from Alexandre Esculier and Jérôme Delozière, VP for continental Europe, who helped me to be self-aware and ask myself the right questions. After 18 months as an Enterprise Account Executive, I successfully transitioned to a Regional Director role managing five Enterprise Account Executives.

JD: What is most exciting about being part of the Enterprise Sales team at MongoDB?

LT: Everything! First, MongoDB’s technology is amazing. It is important to emphasize this, because it is impossible for me to work for a company where customers are not happy with our products. I want to be able to believe in what I am selling, and I believe in it. The R&D teams are always looking for the latest developments that allow us to be 5 years ahead of the market.

Additionally, selling through the MEDDIC methodology has taught me a lot. I had the art and MongoDB gave me the science. Even after 10 years of sales, I keep learning.

Most importantly, the people! Everyone is trying to be the best version of themselves and one of the builders of this great adventure. It's really nice to work with so much emulation.

JD: What is our Sales team culture like?

LT: To describe it in one word: Transparent. In transparency we can progress. We have to share with each other, help each other, point out our weaknesses, and listen. The same goes with customers. Transparency is the key.

JD: What skills and qualities make someone successful on the Enterprise Sales team?

LT: I think success comes from hard work. Nothing comes ready-made in this environment and there is no relying on luck. You have to work, learn, question yourself, and move things forward. Luck comes later.

JD: Is there anything else that you think someone should know about our Enterprise Sales team in France?

LT: I'm hiring, so do not hesitate to reach out to me via LinkedIn!

Interested in joining MongoDB’s Sales team? We have several open roles across the globe and would love for you to transform your career with us!

← Previous

How MongoDB Could Have Changed Star Wars and Saved the Jedi

May the 4th be with you! Here at MongoDB, lots of us love Star Wars. It got us thinking about how the events that unfolded throughout the movie franchises could have been different had MongoDB products and features been available. So to celebrate Star Wars Day, this article will take a light(side)-hearted look at exactly that! MongoDB Atlas: How has nobody heard of the Jedi? One of the questions that was asked a lot by fans when Star Wars: Episode VII – The Force Awakens was released was how Rey, Finn, and many others in the Star Wars universe didn’t know that the Jedi were real, let alone still existed. This can be explained by Emperor Palpatine ensuring that all Jedi Knights, temples, and traces of the Jedi were erased. But what if this information had been stored in MongoDB Atlas ? One of the core features of MongoDB Atlas is a document database-as-a-service (DBaaS), which allows for storing data as JSON-like documents in collections in the cloud, accessible from anywhere with a connection to the internet. Under the hood, this database supports high availability using replica sets , which are sets of nodes (the minimum and default value is three nodes), with one acting as the primary node and two or more as secondary nodes. The data is replicated across these three nodes, with availability handled by Atlas automatically. If the primary node goes down, the replica sets promote a secondary node to primary. Imagine if, following Emperor Palpatine and Darth Vader destroying evidence of the Jedi Order, the data could have recovered itself thanks to the high availability of clusters on Atlas. Atlas cloud recovery would have also helped prevent deleting of data in the Jedi Archives. In Star Wars: Episode II – Attack of the Clones , Obi Wan-Kenobi visits the Jedi Archives on Coruscant to locate the planet Kamino, where they expect to find answers on who attempted to assassinate Senator Padmé Amidala. However, Obi Wan-Kenobi finds himself having to call for the help of the librarian, Jocasta Nu, because he cannot find any traces of the planet in the archives. She famously says that if the planet is not in the archives then it simply does not exist. Atlas’ database gives the ability to store data in the cloud, available anywhere as long as you can access it. Therefore, you could also argue that the information in the archives would have been available from anywhere, not just in the one server within the Jedi Archives. Luminous beings we might be, but database specialists, the Jedi were not. Security: You don't belong here! In a world with ever more data being consumed and stored, people are becoming more aware of how secure their data is (or is not). When looking to use MongoDB Atlas, developers are often concerned about how safe their data is in the cloud. MongoDB Atlas comes with a lot of security features pre-configured from the start. This includes isolation, authorization, and encryption. Security stack showing Isolation, Authorization and Encryption We firmly believe that your data should be private and only visible to those with the rights to see it. In Star Wars: Episode VI – Return of the Jedi , the Alliance learns of the construction of a second Death Star and discovers that an energy shield generator to protect the new Death Star is on the forest moon planet Endor. Leia, Han Solo, Chewbacca, R2-D2, C-3P0, and the Ewoks fight in the Battle of Endor for access to the bunker containing the generator. Thanks to R2-D2 and C-3P0 drawing away the Imperial Army, the enemy is attacked by the Ewoks. Chewbacca is then able to steal an AT-ST and rescue his allies, who are attempting to hack into the bunker. They successfully gain entry to the bunker, plant explosives, and expose the new Death Star, allowing it to be destroyed by the Rebel Fleet. However, if MongoDB security had been involved, the rebels wouldn’t have gained access to the bunker and the energy shield protecting the Death Star would have remained, meaning the Empire could have won. Death Star II was able to travel across the galaxy and strike fear into the hearts of many, and perhaps this might have prevented the creation of Starkiller Base in The Force Awakens and its destruction of the entire Hosnian system, saving millions of lives. While the Empire could have wiped out the Alliance and taken control of the galaxy with the second Death Star, it would have had to remain within range of its shield generator on the forest moon of Endor, unable to terrorize the galaxy at large as Starkiller Base eventually did. The First Order and Kylo Ren may never have risen to power. Luke Skywalker may not have escaped the Emperor or redeemed his father. Life would probably look very different for those millions of lives saved in the Hosnian system. We may have, in fact, seen Darth Vader and Luke Skywalker rule the galaxy as father and son. Scary thought! Data API: Bye-Bye, R2-D2 MongoDB Atlas Data API is a new feature, currently in preview, that allows developers to access their Atlas hosted database cluster via HTTP calls over the web using just a unique endpoint URL and an API key. This opens up the possibility of using the power of the MongoDB document database model in more ways and more scenarios. You might choose to use it because you don’t want the overhead of installing and using a driver for your chosen language or platform. This could be because you are prototyping or just prefer the API approach. You may not even have a driver for that scenario but can make HTTP requests. One example of this scenario is the Internet of Things (IoT), where you often won’t have a driver as an option but can easily make calls over the web. Another scenario is from a SQL stored procedure. That might sound controversial, but what if you want to push data to both a relational database and an Atlas cluster at the same time to help with migrating over to the most popular non-relational database in the world? A driver is a programming interface, allowing for use with whatever the driver is intended for. The MongoDB driver , available for multiple programming languages, allows communication with a MongoDB database via a connection string. It simplifies that process and handles the communication so developers don’t have to write complicated low-level code. In the Star Wars universe, you can think of droids as an interface to the data in the world around them. R2-D2 is an astromech droid, whose primary function is to provide navigational abilities but is able to do far more, including interfacing with other computers via a SCOMP link, disabling autopilot on the Naboo starfighter, picking up distress signals, locating Emperor Palpatine on Grievous’s ship, and, of course, sharing the Death Star plans with the Alliance. So, if there was MongoDB Atlas Data API in the Star Wars universe, what might that look like? This could be a simple data pad, similar to a smartphone. Instead of relying on R2-D2, BB-8, or Chopper to act as an interface to the information in different computers around the galaxy, the data pads could do this instead, providing the ability to access the data stored in Atlas. Using MongoDB, the Death Star plans might have been added to a collection in the database and accessible to all those who were authorized. This would have prevented some of the danger seen at the start of Star Wars: Episode IV – A New Hope , when Princess Leia had to upload the plans into R2-D2. Of course, R2-D2 would still have proved useful in other situations, such as in battle, putting out fires in the Millenium Falcon, or throwing Luke his lightsaber during a battle in Star Wars: Episode VI – Return of the Jedi . But some of the key roles he played could have been made redundant if the Data API–enabled data pad had been available instead. Sharding: Where art thou Anch-to Speaking of R2-D2, another event he was involved in could have been different had there been a feature of MongoDB in the Star Wars universe, sharding . When you have a really large data set, like, I don’t know, all the information in the galaxy’s HoloNet, you might want to break it down into smaller pieces in order to make it faster and easier to search through. Sharding is a perfect example of this in action. Sharding works by segregating your data into smaller pieces based on a field in your document. A common real-world comparison would be a library. In a library, books aren’t all just thrown on a shelf in the order they were acquired by the library. They are instead broken down into different shelves, sorted by author surname. The equivalent of this in the database world is a sharding key, which tells you exactly where to head first, saving you time and effort. In Star Wars: Episode VII – The Force Awakens , the Alliance including Rey want to find Luke Skywalker. If the galaxy information had been sharded, it would be possible for it to have been searched to find Luke’s location much faster, without the need to find a particular map to fill out a local data set. Access to Ahch-to, the location of the ancient Jedi Temple and the galaxy’s only green-milk-producing thala-sirens, would be just a query away.. This also ties in nicely to the previous section about the Data API. Without the need to use R2-D2 for the missing piece but instead use a data pad to query all the known information on the galaxy, the Alliance may have found Luke much sooner — especially if they were able to use MongoDB’s powerful query language to perform complex queries on the data using the aggregation pipeline . MongoDB is a non relational database that can be used by all living things. It surrounds docs, penetrates analytics, and binds the galaxy together. There we have it, a trip through the galaxy and the events of Star Wars to see how the timeline might have been different had MongoDB been around. MongoDB is a non-relational database that can be used by all living things. It surrounds documents, penetrates analytics, and binds the Galaxy together. The knowledge of the Jedi wouldn’t have been erased and their reputation tarnished had MongoDB Atlas and its high availability been available. The energy shield generator on Endor would have survived, meaning Death Star II may never have been destroyed, allowing the Empire to take full control of the galaxy but thwarting the rise of the First Order. R2-D2 might not have been so important had MongoDB Atlas Data API been available on data pads, allowing direct access over the internet to the data instead of requiring a driver. Luke Skywalker may have been found much sooner had sharding been available alongside powerful querying functionality such as the aggregation pipeline to bypass the need to find a map and get the missing piece from R2-D2. How can you use the power of MongoDB Atlas today to change your own universe? Get started today with our free forever M0 tier . MongoDB World returns this June to NYC and in honor of May the Fourth we are offering tickets at only $400 May4-6. Register now and join us for announcement packed keynotes, hands on workshops, and more June 7-9.

May 3, 2022
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