Switching Teams and Beginning a New Career as a Solutions Architect: Meet Idriss Ouazzani

I sat down with Idriss Ouazzani, a Solutions Architect (SA) based in France, to gain a deeper understanding of his fast track to success, rising from Customer Success Manager (CSM) to his current SA role in less than two years. We also spoke about his upbringing in Morocco, his deep love of learning, and the ways in which MongoDB has kept him motivated and energized.

Idriss Ouazzani

Jess Katz: Thank you for sharing your story, Idriss. Can you tell me what you did before joining MongoDB?

Idriss Ouazzani: I was born and raised in Meknès, Morocco, and lived there until I was 18 years old. Although I did extremely well in the entrance exam for the Moroccan Army, I decided instead to move to France and further my studies in engineering. I was always passionate about new technologies, and I decided to pursue electronics/signal-processing engineering.

While at university, I had a ton of impactful experiences, ranging from working as a receptionist in Japan to serving as Treasurer, and ultimately a President, of the third-biggest event in France for technical students, the Forum Toulouse Technologies. These experiences helped me discover another passion: business development.

I decided to apply for a double degree partnership between the engineering school and the business school, and I ended up getting a master’s degree in engineering and business.

From there, I decided to join Atos, a French multinational information technology service and consulting company, as an Enterprise Account Executive covering the business unit in France’s southwest region and managing a large portfolio.

After more than two years at Atos, I started to feel as if my passion for technology wasn’t quite getting fulfilled. I decided to take on a new challenge, and move to a new country (Ireland) and join MongoDB!

JK: What inspired you to join MongoDB?

IO: During my time in sales at Atos, all my consultants were MongoDB lovers. They were so impressed by the technology and the continuous innovation that I couldn’t resist joining this young but well-established company. While doing some of my own research, I was blown away by the growth rate, the innovation, the developers’ feedback, and much more.

JK: Can you walk us through your career path at MongoDB?

IO: I joined MongoDB on August 19, 2019, as a CSM covering the entire French region. Moving from Toulouse, France, to Dublin, Ireland, I noticed that although the weather was colder, the atmosphere was so warm and welcoming. Even though I had an engineering background, I didn’t know much about databases when I joined. Week one, I remember getting introduced to MongoDB University, and I was so impressed with the quality of the content that I got addicted to it. Within a month, I completed the presales bootcamp training and the new-hire technical training prep course. Everytime I learned something new, I understood that there was so much more to learn. When you’re someone like I am who loves to learn, this is an amazing feeling.

I quickly took the lead on solving some of our customers’ technical challenges in France. I remember the evenings I spent with our world-class Support Engineers finding creative solutions for a customer. I also built technical demos for my CSM colleagues and helped them expand their technical knowledge.

From there, I became a CSM covering the Middle East in addition to France. As an Arabic speaker, it was a great opportunity for me to work with a new market and speak three different languages all the time while collaborating with an amazing team. Even though I was offered the opportunity to be a SA in France, my manager at that time wanted to promote me to Senior CSM for my contribution to the CS program and for helping the organization grow. This really demonstrated to me just how great a company MongoDB is. After several months in the Senior CSM role, I moved back to France and became an SA, and it’s been an incredible experience so far.

JK: What excites you most about being an SA, and why?

IO: Two months after I joined MongoDB, I went to Paris for the QBRs. There I met the SA team and started to learn about their role within the company. For those who don’t know, an SA is a salesperson with very strong technical skills whose role is to understand customers’ and prospects’ requirements and explain how MongoDB can help them solve their problems. I had one of these moments where you think to yourself, “That’s a job I could see myself doing.” I asked about the typical SA career path at MongoDB, and one impressive thing was that each SA I spoke with had a unique growth path, and they were all very passionate about their work and the technology.

During the QBRs, I met Emmanuel Macé, an SA manager in France, and he saw the interest I had in the SA role. He made a decision that I will never forget: He asked me if I would like to attend a two-day team-building session at a French Normandy castle with the entire Southern Europe SA team to learn more about the role.

After spending those two days learning more about the team and the role, I grew extremely interested in the opportunity. However, when speaking with my manager and other people, becoming an SA seemed like a longer-term goal (more than 3 years), because I needed sufficient technical knowledge before taking it on. A couple of months later, the COVID-19 pandemic started, and the lockdown followed shortly after. I was stuck in a tiny apartment in Dublin and decided to gain as much knowledge as possible in order to secure the SA role. I remember spending hours and hours teaching myself technical concepts. I ended up getting both a MongoDB Developer and Microsoft Azure certification. I reached out to my manager and the SA manager about the role and wound up going through an interview process. This included everything from logic and technical knowledge tests to interviews with managers and vice presidents and finally a challenge.

Throughout the process, the CS leaders were there for me and provided their full support (a special thanks to Ruth Neligan, Sara Escribano-Slowey, and Julia Prause).

JK: How have you been able to be creative in your roles at MongoDB?

IO: I’ve never before been afforded this degree of freedom to create and innovate. In the CS org, each time I had an idea, I had full support from the managers to pursue it. During that time, I started a MongoDB championship concept: one-on-one speed “dating” with developers where they get 30 minutes to ask all the questions they want and much more. Additionally, when I had a technical question, other teams were always there to help. Last but not least, MongoDB’s managers know how to create a “safe space” for me and others to share all of our thoughts with complete transparency.

JK: What are some interesting technical and creative aspects of being an SA?

IO: When you are an SA, you’re focused on understanding your prospects’ and your customers’ needs. Oftentimes, they don’t know a lot about MongoDB, so the challenge is to become a MongoDB expert and to understand the technical aspects that surround it. When you are an SA in MongoDB, you need to fully understand other technologies (Kafka, Kubernetes, Spark, cloud providers’ offerings, Terraform, Ansible, and much more). You also need to understand the competitive landscape. I really like that we are at the cutting edge of technology.

JK: What would you want potential candidates to know about working at MongoDB?

IO: My advice is to be yourself. One key value we share is to “embrace the power of differences.” Be proud of what you’ve achieved, think big, and remember, I didn’t know much about databases when I joined, but I do now, and if you want to, you can too.

And lastly, take risks. When interviewing me, the team saw potential when I raised my hand even though I was far from being a traditional candidate.

JK: Did you have support from your managers each time you made an internal transfer? What were those conversations like?

IO: This is one of the most impressive things I saw at MongoDB. I was scared about how my manager would react if I asked for an internal transfer, but each time, I had full support from my managers. As a matter of fact, they went a step further and asked me what they could do to teach me about the position I wanted to get.

Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe, and would love for you to build your career with us!

← Previous

The Evolution of Data

It used to be so simple. Not that long ago, the universe of corporate data was a fraction of its current size. We fit most of it into rigid little rows and columns. And we didn’t ask all that much of it: some transaction processing, a few charts and graphs, a little business intelligence. I’m exaggerating, of course. We’ve been pushing the boundaries of data processing since at least 1964, when SABRE, the world’s first airline passenger system, launched on two IBM mainframes and 1,500 terminals, processing an average of one transaction per second. But it’s not hyperbole to say that today’s data would barely recognize its early ancestors. First of all, there is more of it – 59 zettabytes and counting. Second, the very definition of data has changed dramatically, expanding well beyond payroll records and stock prices to include diverse data types like weblogs, fraud scores, maps, and fingerprints. But perhaps the biggest change has been the role data plays in the enterprise. Data has always been used to inform business strategy. But today, data often is the business strategy. Consider this: 20 years ago, there was no such thing as a Chief Data Officer. Today? Almost two-thirds of Fortune 1000 companies have one. Why? Because we are asking more of our data than ever before. And rightly so. In the digital economy, every company competes on the basis of insight-driven innovation. More and more, those innovations take the form of software built around clever algorithms. And the raw material to both craft and execute those algorithms is data. All of which means the ability to efficiently and effectively manage data -- at speed -- is a strategic imperative for any company, in any industry. And yet, even as the volume, variety, and strategic importance of data has rapidly evolved over the last two decades, many enterprises haven’t changed how they manage it. Of course, I’m talking about the continued use of legacy relational databases, which are too rigid and don’t scale well enough to handle the demands of modern application development. Solving this problem was the entire reason for the “NoSQL” movement in the late 2000s, and MongoDB’s invention of the document-oriented database in the first place. But I’m talking about something bigger; a longer-term trend that demands a fresh look at the way we work with data. Our customers are telling us that the fundamental requirements of their various data sets aren’t just changing, they’re converging. This is a surprise, and a reversal of the trend of siloization and specialized tools for the last 50 years. Let’s take a step back: For decades, enterprises have maintained systems of record and systems of engagement. Systems of record are foundational, mission-critical, sources of truth that are accessed primarily by internal programs and users. Systems of engagement are the digital interfaces with which customers and employees interact. And recently we have seen the addition of systems of insight, which combine data from various sources to inform decision making across the enterprise. For a long time, each system lived on different computers, had different data management requirements, and were funded by different departments. But that is changing. With the hard and fast divisions between back office and front office dissolving, we now need all of our data systems to do everything. They need to be both fast and accurate. They need to be both accessible and secure. They need to handle both transactions and analytics. In particular, with the rise of model training and inference, a different kind of analytics is arriving; one where it is programs that are asking the systems of insight questions and reacting to them in real time, rather than humans asking questions and then writing programs to implement them. This is a fundamental shift; so fundamental that you could liken it to the change from the IBM 7090s that powered SABRE to those that (will?) power SKYNET. This “convergence” of data requirements is both a challenge and an opportunity. Just like document databases enabled us to rethink how data was accessed and stored, convergence is forcing us to rethink the systems we use to manage data across the enterprise yet again. Companies across the industry, from Snowflake to Databricks to MongoDB, and every cloud provider, are working to provide the systems that let companies get more value from their data, using microservices-based networks or programs that drive informed, real-time decision making. Interestingly, this comes at a time when most companies are undergoing radical digital transformation projects in order to become innovation-powered, software-driven, and cloud-based. In other words, even though everyone is already quite busy, there has never been a better time to think beyond the database, and architect an actual “data platform” that can process, store, secure, and analyze data in real-time, across all the relevant data sets - either without copying the data or making such copying invisible. Over the coming months, I’ll be sharing more about what these data platforms look like and how they support the creation of modern applications. I’ll also try to peer into the foggy future with you, looking at the constraints and freedoms of the modern enterprise, and predicting what products will be built to address that matrix. But for now, I’m interested in hearing what you’re seeing under the hood of your data(base) estate. Are you experiencing a similar convergence of data requirements? If so, is it factored into your digital transformation strategy? And if not, what changes are you seeing in the way you use data across the enterprise? Please reach out to me here or on Twitter, at @MarkLovesTech - because I really do. Thanks for reading - may the data odds be in your favor until we chat again. Mark

March 8, 2021
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