Meet Our Growing Flex Consulting Team

Aman Kumar
June 25, 2021 | Updated: June 28, 2021

In this blog post, Aman Kumar, Director of Flex Consulting, writes about the growing Flex Consulting team within our Professional Services organization. Aman and some of his team members give insight into the Consulting Engineer role; what you can expect in terms of training, learning opportunities, and team culture; and why this is an exciting career opportunity.

What are Professional Services and Flex Consulting?

An organization’s success often rests on its ability to leverage software and data to innovate better and faster. The Professional Services team provides expertise to accelerate the success of customers’ most important projects. With strategic advisory services and deep technical knowledge and experience, our Consulting Engineers (CEs) help drive success at all stages of application development and digital transformation with MongoDB.

We know customers who work with MongoDB Professional Services are more likely to succeed in their journey or project compared to those who do not.

With the objective of helping as many customers as possible and extending the reach of our consulting, MongoDB Professional Services launched Flex Consulting in late 2019 to provide a more flexible offering with variable engagement sizes and delivery models.

Whether a customer has a few questions they need answered or a larger project with which they need help, Flex Consulting from MongoDB can help them meet their goals. With variable engagement sizes, we can help design and develop new applications, migrate to MongoDB successfully, optimize MongoDB usage, or even operationalize MongoDB deployments.

Read how Flex Consulting has played a role in these MongoDB customer journeys:

The journey so far

It has been a roller-coaster ride for everyone involved, but the offering has been a big success for our corporate customers. We have helped customers all over the world succeed in their application lifecycles, which has led to consistently positive feedback even after working with customers at scale.

When the Flex Consulting team began, there was only one Consulting Engineer (Saurabh Mishra) and I. We have come a long way since then. We are a quickly growing team with more than 25 members based across India, and the extended Professional Services team is spread across the world.

What we look for in a Consulting Engineer

We look for people with a wide variety of skills — typically a software engineering background with great communication and problem-solving skills. This job requires not only a thorough understanding of MongoDB products and technologies, but also an understanding of best practices for software development, DevOps, application design, and competitive products.

Just as technology is ever-evolving, so is this role. You should love to learn and keep yourself updated on what’s happening not only with MongoDB, but also with the technology world overall. Every day is a new challenge, so you should like to solve technical problems while helping customers. Being agile is key in this environment.

Learning and growth opportunities on the Flex Consulting team

The market continues to accelerate toward consumption-based models as the norm, and Flex Consulting is at the forefront of our Professional Services portfolio. You get exposed to many interesting use cases on your journey with MongoDB Professional Services and Flex Consulting.

This is still a new team growing at a rapid rate, creating growth opportunities on its way. We’ve promoted three individual contributors (ICs) to leadership positions from within the team, and we believe this is the best way to set up the team for success as they transition into natural mentors and managers. There is also an IC growth path for those who prefer to keep their hands in solving customer problems.

As we grow, we will continue to invest and build new roles within the Flex Consulting team and the larger Professional Services organization.

Setting up Consulting Engineers for success

As with all our tech roles, MongoDB offers extensive training, including technical training that provides a deep understanding of MongoDB’s product portfolio. After you complete the initial technical training, you’ll go through another robust program specifically designed for our Consulting Engineers. This allows you to practice with exercises and learn the skills needed to be a successful CE. Finally, you will shadow and co-lead engagements with some of our existing CEs as a way of learning on the job before you start your own journey.

You will be given autonomy and accountability, but your leaders will be there to teach, coach, enable, and show you how to get where you need to be to succeed. You’re still very much supported, but you have the freedom to drive your engagements independently.

Team culture

Although we haven’t met some of our new hires in person due to our remote-working environment during the COVID-19 pandemic, the camaraderie and team cohesion is amazing. Whether you have a technical problem or a personal situation to deal with, the team is just a Slack message away. Although this role can be challenging, the support from the team is unmatched.

The team is always doing things together — constantly looking to collaborate on projects and work together. The culture has been one of my favorite parts of working at MongoDB. The team also brings diversity of background, thought, and experience, and without it we wouldn’t be able to innovate, challenge the norm, or think about different ways of doing things as much as we do. On top of all this, we don’t forget to have some fun along the way!

Meet some team members

Karan Srivastava, Manager, Professional Services

“I started my journey as a Consulting Engineer, and I have since moved into a leadership role. My goal was always to be in a customer-facing technical role and to help people by doing what I love the most: building and running efficient software! The Consulting Engineer role provided me with just that. At its core, Flex Consulting helps customers succeed with MongoDB. My prior experience in software development has immensely helped me to be successful in this role, but the speed at which you’ll learn here is supersonic. What I love the most about MongoDB — especially this team — is that everybody is focused on making you successful, helping you develop new skills, and allowing you to be creative and own your ideas.”

Jay Chakra, Consulting Engineer

“In this role, every day is meticulously planned. Unlike software engineering, however, where you work on a single project for a long period of time, every day we work with different customers on a variety of problems and use cases. Solving interesting real-world technical problems gives me a sense of great achievement. In this role, you’re also given a lot of visibility and opportunities to make an impact. MongoDB’s product portfolio and reputation as a leader enables us to continue to make our mark on the massive database industry. This gives members on the Flex Consulting team a lot of potential to grow, as well as the opportunity to work with some of the smartest people in the industry.”

Interested in pursuing a career in Professional Services at MongoDB? We have several open roles on our team, and we would love for you to transform your career with us!

← Previous

Import and Export Your Charts Dashboards

With the latest release of MongoDB Charts, we’ve added the ability to export any dashboard to a file, as well as import those files back into a Charts project. To export a dashboard, simply choose Export Dashboard from the dashboard’s tile on the main Dashboards page. To Import a dashboard, choose the command from the menu next to Add Dashboard. Let’s look at some things you can do with this new capability. Copy dashboards between projects MongoDB Cloud allows you to create multiple projects, each of which has its own Atlas cluster. There are a bunch of reasons to use multiple projects, but one common example is to use them for different environments of an application, such as Development, QA or Production. Each Charts dashboard also lives within a project, and up until now there was no way of moving or copying a dashboard between projects. This could be problematic if a dashboard that was created in the Development project needed to be promoted to QA or Production. WIth the new Import/Export feature, you can simply export a dashboard from one project and import it into another. Version control your dashboards Taking this example one step further, now that you can export your dashboards to a file, you can treat them as code. That allows you to store the dashboard definitions in a source control system, making it easy to track changes, go back to specific versions, and keep the dashboards stored safely alongside other code artefacts used in your solution. Share dashboards with the community While some dashboards only make sense when connected to your own private data, others may be built on a commonly-available schema, whether that’s the Atlas sample data , some open data from the web, or data created by a reusable script . Once you’ve built a great dashboard using this generally available data, why not export it and share it with the world? Copy dashboards and change their data sources Whenever you import a dashboard from a file, Charts will give you the opportunity to “remap” the data sources used on the dashboard. This is important because the data in the new project might not match what was in the original project. You can use this feature to your advantage if you want to quickly change the data sources used on a dashboard, even if you are importing back into the same project. As an example, suppose you are a multinational company and used a different collection to track sales in each country you operate in. You could build a dashboard with a bunch of great charts, all linked to your “US Sales” collection. If you wanted to easily build an equivalent dashboard for your Australian sales, you could simply export the US dashboard, reimport it and remap your data sources on import to the “Australian Sales” collection. Migrate from Charts on-prem Finally, this feature provides a great option for Charts on-prem users who want to move to the cloud and take advantage of all of the new features only available to cloud users. While the on-prem version of Charts does not have the Export feature, on-prem users can contact MongoDB Support to obtain a script that will generate export files for on-prem dashboards. Those files can then be imported into your MongoDB Cloud projects using the new Import feature. We hope you’re as excited about this feature as we are! Remember, if you haven’t used Charts before, you can get started for free by signing up for MongoDB Cloud , deploying an Atlas cluster and activating Charts.

June 24, 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