10 Signs Your Data Architecture is Limiting Your Innovation: Part 1
For most businesses, the data layer is usually out of sight and out of mind. But that approach can mask the cause of major challenges facing a business — from slow time to market for new products to spiraling maintenance costs to a difficulty in focusing on innovation. The truth is, all of those issues are often rooted directly in the complexity of your data architecture. Whether you’re working with a cloud migration that has accumulated dozens of components or a legacy infrastructure that has been jerry-rigged to support modern applications, that complexity sucks up your developers’ time and resources, keeps you focused on maintenance, and creates data duplication and integration challenges that eat your budget. This complexity manifests in many different ways; as they accumulate, they can become a serious hindrance on your ability to bring innovative ideas to market. We think of the effect as a kind of tax — a tax that is directly rooted in the complexity of your data architecture. We call it DIRT — the Data and Innovation Recurring Tax. We have identified ten symptoms that can indicate your business is paying DIRT. For an in-depth view, read our white paper 10 Signs Your Data Infrastructure is Holding You Back . Symptom #1: Insights come by the month or week, not by the minute How can you serve your customers if you know nothing about them? In today’s world, insights into your customer and their needs are vital to survive, but real-time insights are what give you the competitive edge to thrive. Often, this seems to necessitate a separate database dedicated to analytics, with difficult-to-maintain ETL pipelines shuttling data between databases. But if you’re trying to match real-time insights with real-time behavior, then slow ETL pipelines put you behind before you’ve even started. And analytics databases often struggle to accommodate semi-structured, unstructured, and geospatial data. Meanwhile, the shape of your data is changing more quickly than your systems can adapt. Many organizations house their analytics in a data warehouse or a data lake. With a data warehouse or data lake, you still need to move data back and forth, introducing latency, rather than working with data where it resides. The whole process is still too slow to allow real-time analytics and power rich application experiences. Our solution: MongoDB’s application data platform solves this problem by allowing you to analyze data directly in the database in real time. Symptom #2: You can't construct a 360-degree view of your customer — or of anyone or anything What retailer wouldn’t want to have all its customer data, from clickstream to transaction history, in one place? What financial institution wouldn’t want a single view of exposure across asset classes, counterparties, and geographies? A single view, also known as a 360-degree view, can enable customer-service agents to be more helpful more quickly, because they have the data they need. A single view makes it more likely that fraud will be detected while it can still be stopped. And a single view makes it easier to comply with General Data Protection Regulation (GDPR), because you can see all your customer data in one place. Building a single view generally requires the integration of different types of data from different databases that don’t communicate. Finding one schema that will work for all the data types is extremely difficult. When you need to add new data, your old schema may not work. Our solution: Because MongoDB’s application data platform is built on the document model, it’s ideally suited to building 360-degree views. Our database supports rich customer objects, and it can accommodate any kind of data, no matter its format. These objects can be further enriched at any stage just by adding fields to a document — no schema migration necessary. For a complete view of DIRT, read our white paper DIRT and the High Cost of Complexity .
What is MACH Architecture for ecommerce?
In the past, retailers faced the looming battle of brick and mortar vs. digital buying experiences. While most in the retail industry accepted the inevitability of needing some kind of digital experience, COVID-19 forced retailers to refocus efforts to digital-first, or at the very least, hybrid digital and in-person buying options. What customers expect (and why legacy systems don't hold up) Which leads us to one of the underlying problems for modern retailers: legacy architecture. The digital solutions many depend on aren’t able to meet consumers’ digital-first (or at the very least digital-friendly) ecommerce expectations. Today’s customers expect: Mobile-friendly architecture - People shop from their phones. If your ecommerce experience was designed with web-first in mind, only retrofitting a mobile component to meet buyer demand, you may need to rethink your mobile offering. Omnichannel experience - Beyond having a mobile-friendly buying experience, consumers want to carry their purchasing power from channel to channel and even into the physical store. Think buying online and picking up in store (BOPIS), or starting an order from your phone and completing it in store, or vice versa. Dynamic product catalogues - Consumers want ample choice and a smooth search experience. Can your systems hold up with thousands of products all displayed, searchable, managed, updated, and dynamically enriched with discounts, product offerings, and more? They also expect real-time stock availability, both in store and online. They want to know you really have an item in stock at their local store before venturing out to buy it. Personalization - Personalization is so ingrained in the online retail experience now that consumers have come to expect it. They want real-time recommendations for the items they’re interested in, with predictions based on past online purchases and searches, items in their cart, and in-person buying experiences. Why is it difficult to live up to these expectations? For many in ecommerce, they’re still running monolithic applications built as a single, autonomous unit. This means even the smallest changes, like altering a single line of code or adding a new feature, could require refactoring the entire software stack, leading to downtime and lost business. In addition, the long-term opportunity cost of having your development team waste time simply maintaining and patching such a brittle ecommerce system is a constant drain, or Innovation Tax , on your business. So retailers face a unique challenge. The thought of overhauling their current systems lead to fears like downtime, expensive investments in new solutions, and ultimately, massive loss of profit. But providing an e-commerce experience that lives up to consumer expectations isn’t optional anymore; it’s how your business thrives. That’s where the MACH Approach comes in. MACH Approach: ecommerce modernization with flexibility in mind So, what’s the MACH approach and, to put it bluntly, why should the retail industry care? The MACH approach, championed by the MACH Alliance , an industry body of which MongoDB is a member, is focused on facilitating the transition from monolithic, legacy ecommerce architectures to modern, streamlined e-commerce applications. Microservices - Microservices break down specific business functionalities into smaller, self-contained services. Instead of taking your whole application offline to add new shopping cart features, you update specific elements of your architecture without disrupting the entire application. This affords developers a level of flexibility that monolithic systems can’t compete with. Greater developer flexibility means minimal downtime, faster updates, an improved experience for consumers, and ultimately faster time to value for your business. API-first - APIs, the pieces of code allowing communication between separate applications or microservices, should be at the forefront of solution development, instead of an afterthought. An API-first approach to development is just that — APIs are built first and all other actions are developed to preserve the original API for greater consistency and reusability. This approach ensures planning revolves around the end product being consumed by different devices (like mobile) and APIs will be consumed by client applications. Cloud-native - At this point, to say “the cloud is the future of app development” is cliche; we’re already there. Building and running applications exclusively in the cloud, whether public or private, allows you to reap all the benefits of cloud development from the start. There are also some cost-cutting benefits to cloud-native environments. You avoid the investment that often comes with on-prem equipment. Most cloud SaaS options have pay-as-you-go cost structures, ensuring you only pay for what you use and leading to most predictable monthly expenses. Using managed cloud solutions, like MongoDB Atlas , also frees up your development team to focus their efforts on where they’re needed most — actually developing your application — instead of sinking valuable time into burdensome administrative tasks. Headless - If your application is down, even for a minute, you run the risk of the consumer simply moving on to another retail option. Downtime equates to lost profits, so to avoid the dreaded disruption to your revenue stream, take a headless approach to application development. With headless, changes to the front end (web store layout, UX, frameworks, design, etc.) can be made without interruption to back end (products, business logic, payments , etc.) operations and vice versa. What's the upside for ecommerce? The four elements of the MACH approach come together to help ecommerce businesses reframe operations, avoid downtime, preserve revenue, provide the best user experience possible, and ultimately ensure your solutions are able to develop and evolve. To maintain a competitive advantage in a growingly competitive commerce market, your application needs to keep up. The MACH approach to ecommerce could be the ideal way to set your application and your business apart. Want to learn more about the MACH Approach and the role cloud-native database solutions like MongoDB Atlas play in the evolving world of digital retail? Get your free copy of Ecommerce at MACH Speed with MongoDB and Commercetools today.
Five Tips for Creating Your Product Design Portfolio
The UX, Interaction, and Product Design professions have experienced a massive increase in demand as more and more companies embrace technology and recognize the importance of providing a positive user experience. A designer’s portfolio is needed for almost every job application or interview process, regardless of your level of experience, and it should be an accurate representation of your process and craft. If you’re working on your portfolio or starting to interview, here are a few tips to help make your portfolio stand out. Keep it updated with your recent work or projects you’re most proud of. About 2-4 projects is usually a good target (depending on detail and length), but don’t stretch to out-of-date projects that may not reflect your current skill set. Trust in your resume to speak to the extent of your experience and let your portfolio be a spotlight for more current work. As a rule of thumb, consider replacing work on your portfolio that’s older than 5 years. Having projects that are relevant to the space you’re applying/interviewing for is always a bonus, but at MongoDB, we hire design team members from all types of backgrounds and value different perspectives. Details and aesthetics count. Your portfolio is a representation of yourself, your work, organizational skills, and more. Even if you keep it simple, creating a portfolio is a time consuming process that requires a ton of energy and thought. We recommend including high resolution images, and exporting animations to gifs or videos, proofreading and utilizing spell check. This is a great chance to showcase your strengths, attention to detail, and an opportunity to share parts of your personality! Continuing to refine your visual design skills? Try using Dribbble and other communities as a resource. Drawing inspiration from other designers on the side is a great way to learn. Tell a compelling story and be consistent with your format. Once you choose a layout and format for your portfolio, be consistent across all your projects. Don’t just show screenshots, share the details that matter most in your process and tell a compelling narrative about the end-to-end journey. We love the messy sketches, whiteboarding, wireframes, and everything in between! It’s okay if things didn’t go as planned; we also want to hear about what you learned and how you grew from the experience. Focus on the user. We are all about the users at MongoDB, and our Product Design teams are user advocates across the organization. Hearing about how user problems are solved through collaboration, research, testing, design, and strategy is what we’re passionate about. Know your audience and the role you’re applying for. Making your portfolio easily readable and starting with projects most relevant to your career interests and goals will really make it stand out. For longer or more complex pieces, try to bold the most important parts to quickly grasp your audience’s attention. Pro tip: We recommend including your portfolio and password when applying to a role. We understand that it’s important to protect any sensitive work, however, providing quick access could give you the edge in this fast-paced job market! Each person that joins our team adds something unique and special, changing the team for the better. Learn more about our Product Design team in this two-part series . If you’re passionate about technology and our Design team sounds like one you’d like to be a part of, we’d love to hear from you! Interested in pursuing a career in design at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Engineering, Done DIRT Cheap: How an Outdated Data Architecture Becomes a Tax on Innovation
In March 2021, I wrote about The Innovation Tax : the idea that clunky processes and outdated technologies make it harder for engineering teams to produce excellent tech that delights customers. In the months since then, my thinking has evolved even further. I couldn’t have guessed how many technology leaders would immediately recognize these problems in their own organizations and share their own deep frustrations with me. This article puts that evolved thought together with the massive feedback that piece received. It will give you actionable ways to decrease your tax burden — and who wouldn’t want that? The innovation tax, like income tax, is real. Of course, it saps morale (with resulting attrition and churn), but it also has other financial and opportunity costs. Taxed organizations see their pace of innovation suffer as people and resources are locked into maintaining rather than innovating. We named this tax DIRT . Why? Well, it’s rooted in data (D), because it so often springs from the difficulty of using legacy databases to support modern applications that require access to real-time data to create rich user experiences. It affects innovation (I), because your teams have little time to innovate if they’re constantly trying to figure out how to support a complex and rickety architecture. It’s recurring (R), because it’s not as if you pay the tax (T) once and get it over with. Quite the opposite. DIRT makes each new project ever more difficult because it introduces so many components, frameworks, and protocols that need to be managed by different teams of people. In retrospect, it’s clear that technology leaders would recognize this tax and immediately grasp the degree to which it’s caused -- or cured -- by their data architecture. Data is sticky, strategic, heavy, intricate -- and the core of the modern digital company. Modern applications have much more sophisticated data requirements than the applications we were building only 10 years ago. Obviously, there is more data, but it’s more complicated than that: Companies are expected to react more quickly and more cleverly to all of the signals in that data. Legacy technologies, including single-model rigid, inefficient, and hard-to-program relational databases, just don’t cut it. In over 300 CxO conversations I've had since joining MongoDB in 2020, fewer than a handful of CTOs disputed this statement. When your tech stack can’t handle the demands of new applications, engineering teams will often bolt on single-purpose niche databases to do the job (think time series, text, graph, etc.). Then they’ll build a series of pipelines to move data back and forth. And everything will get slow and complicated — and even political. Time to polish up that LinkedIn profile. If this were rare, it wouldn’t be such a big deal. But large enterprises can have hundreds or thousands of applications, each with their own sources of data and their own pipelines. Over time, as data stores and pipelines multiply, an organization’s data architecture starts to look like a plate of spaghetti. Soon you’re operating and maintaining an entire middleware layer of ETL, ELT, and streaming. The variety of technologies, each with their own frameworks, protocols, and sometimes languages, makes it harder for developers to collaborate. It makes it extremely difficult to scale, because every architecture is bespoke and brittle. Developers spend their precious “flow” hours doing integration work instead of building new applications and features that the business needs and customers will love. Enterprise architects often end up spending their time on all the wrong things. It’s clear to me that most customers are ready for a new approach to data architecture. One of the best parts of my job is listening to and learning from other CxOs. Since the pandemic made it impossible to do that in person, MongoDB moved these discussions online, inviting technology leaders to hash out some of their biggest problems 1:1 and in groups with me. In one of those sessions, a CTO commented, “Technical debt should be carried on your CFO's balance sheet.” Even on Zoom, the power of that statement was clear. We also started looking at slide decks about data architecture from some of the best-known venture capital firms. Certainly VCs must position each of their portfolio companies as a critical player in the data architecture of the future. But the overall vision was not compelling. One technology leader said, “When I look at 20 net-new technologies I need to learn, it’s terrifying.” Others commented that just looking at these architecture diagrams was a little off-putting, because they knew their own organization’s data architecture was at least that complicated already. They knew they needed to simplify their data architecture, but more than one admitted to postponing this work -- indefinitely -- because it was just too daunting. I recently met with a major health care company whose executives think it’s just barely possible, but they are bravely diving in anyway, knowing that they must do it and that they’ll learn along the way as they tear down their monoliths. In many cases, the innovation tax manifests as the inability to even consider new technology because the underlying architecture is too complex and difficult to maintain, much less understand and transform. This is why a lot of senior people at enterprise companies are sitting with their fingers in the transformation dike, waiting for retirement -- they think they can’t modernize. It won’t surprise you that we also saw how MongoDB, as a general purpose database able to handle all types of data at speed and scale, could help solve this problem. Let me be clear. I’ve been working on or with databases for my entire 35-year career, and I joined MongoDB for a reason: I believe we can build the database and application-building environment that I’ve wanted to create and use for at least 30 of those years. Our vision of MongoDB goes beyond our namesake database to a broader, more versatile application data platform that allows you to accelerate and simplify how you build any type of application. It represents significant progress toward our larger goal, which remains the same as ever: to make data stunningly easy to work with. We want to see data become an enabler of innovation, not a blocker. And we want to finally allow technology teams to start to untangle their sprawl and get rid of their DIRT. Where to start? It’s good to have a better understanding of just how DIRT might be holding your teams back. Do your developers have trouble collaborating because the development environment is so fragmented? Do schema changes take longer to roll out than the application changes they’re designed to support? Do you have trouble building 360-degree views of your customers? And if so, why? These are all good places to start digging in the DIRT. You might also take a hard look at your applications and data sources, as well as what it would take to move your data onto an application data platform. That could mean identifying the objects in your applications and all the applications that interact with them. You could then assign a complexity score to each one based on attributes such as properties, methods, collections, and attributes. Now take a step back and identify each application that connects to each of those objects and rank it based on how mission-critical it is, how many people rely on it, how many tasks it has to perform, and the complexity of those tasks. Once you have a better handle on all this complexity, you’ll be better positioned to create a plan to move off your legacy systems, perhaps starting with the least complex and least integrated data sources. Of course, your metrics and your mileage will vary, but the point is to start. I don’t pretend any of this is easy. Like many of you, I’ve spent most of my career working on problems just like these. But that also means I know progress when I see it, and the beginning of a way for organizations to start to clean up their DIRT. I’ll be continuing to write more about these challenges and hopefully continue to add some perspective. If you’re curious to learn more about DIRT, you can download our white paper . As always, I’m eager to have you tweet your alignment, lack thereof, or other thoughts at @MarkLovesTech . You can also reach out to me on marklovestech.com , where you will find a compilation of my latest musings related to MongoDB and otherwise.
The Power of Embracing Differences: My Journey to MongoDB
September 14th, 2021 marked my first full year at MongoDB, and what a year it’s been. A bit about me Hi, I’m Cara! I’m a Team Lead, Executive Assistant, specifically for Tech & Product. I’m based out of our NYC office and live in Jersey City with my girlfriend and our three cats. At MongoDB, I support our amazing Chief Product Officer and also lead a team of awesome Administrative Assistants (AAs) and Executive Assistants (EAs) within Tech & Product. We are hiring like crazy, too, and I can’t say enough great things about our team. Beyond my already rewarding and challenging role as a Team Lead, I also get to work on other meaningful projects while growing my core career. I’m incredibly grateful and humbled to be a Global Lead for two of MongoDB’s affinity groups (known as employee resource groups at some companies) alongside some of the best, most passionate people I’ve ever met: Queeries - A closed group and safe space for people who personally identify within the LGBTQIA+ spectrum. The Queer Collective - An open group for the LGBTQIA+ community as well as our amazing allies (all are welcome!) to exchange thoughts, ideas, and learn and grow from each other. As we like to say, the future is inclusive! Finding my voice and professional purpose The funny thing is, I didn’t know what an “affinity group” or “employee resource group” was for most of my career. I used to work in a more conservative corporate environment and spent over a decade in the food/hospitality industry with people whose views were wildly different from mine. One of my bosses always asked me if I had a boyfriend or when I was going to settle down with a nice guy. It was awkward and uncomfortable, but it was a discomfort I got used to. How sad is that? The crazy thing was, it didn’t feel sad or weird or anything at the time. I just thought I had to stay hidden at work. That’s what you did. It wasn’t “professional” to be gay. The first time I saw a queer coworker was when I had my first real introduction to the tech start-up environment. He was so vibrantly open about who he was, and I was in awe of him. I stayed quiet for my first few months there and studied people’s reactions, interactions, and how they responded when he would say things that I never thought could be said in an office. They weren’t bad things by any means, but they were topics about being queer that I watched everyone embrace. Then, it slipped out during lunch one day. I thought maybe I could casually mention going on a date so it would be less weird, but everyone was super surprised. I get told I “look straight” a lot, which I’ve always found irritating. What does that even mean? Do I need to be masculine-presenting to be gay? Me (right) and my girlfriend From there, I moved on to work at Zocdoc, which truly opened my eyes to affinity groups, workplace queer communities, and how far they expand. It was the first place I worked that even had an affinity group. I befriended two amazing humans there who were the founders of ZocPride, which represented Zocdoc’s queer community. We got to talking and they told me they only planned something for Pride month. They’re not planners, they actually hate planning, but they didn’t want the group to die. So I said, “Good news. Hi, I’m Cara. I’m super queer and I love to plan things!” We chuckled and then I immediately started planning and researching what I could do with this awesome gift I was just given. Since we had no D&I team and a very limited budget, I worked to find other companies to partner with as well as vendors who would be open to sponsoring events for us. Before I knew it, we were partnering with Out in Tech to host an external panel discussion about queer access to healthcare. We hosted it on Coming Out Day and had about 300 guests. From there, things really took off. We did a “spread the love” campaign for Valentine’s Day, had hugely successful fundraisers for NYC’s AIDS Walk, and then, you guessed it, went crazy for Pride. I proudly introduced the art of drag to Zocdoc and started their annual Drag Bingo Pride event. We also sponsored and had a booth at the Lesbians Who Tech Summit the year that Hilary Clinton came to speak. It was unbelievable. My MongoDB journey After receiving incredible offers to work at a few more companies, unexpectedly experiencing workplace discrimination, and reflecting on what I want and need to be happy and thrive in a work environment, I found myself at MongoDB. One of my amazing colleagues from Zocdoc was working here and we were catching up. I heard the details about the Company and role and thought it sounded like a great fit! I love working in tech, but specifically with Product & Tech teams. They’re brilliant, passionate, quirky personalities that vibe well with mine and in my experience, are hyper-focused on having fun and building a positive culture. Because of my previous experiences, I knew exactly what I was looking for. I asked questions that could be uncomfortable to some, as far as the company’s commitment to Diversity & Inclusion, what it means to them personally, and how they practice what they preach. I didn’t want any more wooden nickels. The interview process was amazing. Everyone was super responsive, informative, and helpful and didn’t hesitate to answer any of my hard-hitting questions. Interviews are a two-way street, and I was immediately put at ease when I realized that MongoDB was the place for me. My recruiter started telling me about our growing D&I team, our affinity groups, and how involved and supportive the leadership team is. Then I got to interview with my manager, our Chief Product Officer, who I clicked with instantly. I knew right away that I wanted to work with him. In my experience, I haven't always been lucky with great bosses. I’ve been ignored, lied to, dismissed, looked over, and simply not appreciated. I don’t feel that way here. I feel heard and respected, and that speaks volumes in itself. I’m often encouraged to take time for myself. I had some personal health issues at the beginning of the year. I was anxious to take time off because I was still so new, but the outpour of support and understanding I received blew my mind. That’s when I knew I had really found my new home. When I joined MongoDB last year, The Queer Collective was still a new group, only three months old at that point, and I was able to join at a very exciting time when there was lots of opportunity and momentum. We officially launched the group alongside the communication of launching our first-ever celebration of (inter)national Coming Out Day . We celebrated again this year and have decided that it will be a company-wide annual tradition. Last year, four of our leads (myself included) shared their coming out stories, and we didn’t realize how much of an impact it made until feedback started to trickle in. We were told that some employees joined MongoDB after reading our stories and some even felt comfortable coming out of the closet and stepping into their own light. If that’s not rewarding, I don’t know what is. This year, more employees shared their stories , and we partnered with our Benefits team to host an internal panel discussion. October is Mental Health Awareness Month, and we thought it would be the perfect time to talk through and bring awareness to the mental health journey that comes along with coming out and embracing your true, authentic self. We will also be planning a full week of impactful programming for Trans Awareness Week so that we can continue to amplify the voices in the Trans Community while encouraging continued education. This past July, I also spoke at MongoDB.live (formerly known as MongoDB World) with my Queer Collective co-lead and dear friend Seán Carroll about Allyship and how to upgrade to an active accomplice. It explored what accountability and support look like and how we can all improve our support of the LGBTQIA+ community. The feedback was amazing, and I can’t wait to evolve our topic and content and hopefully speak in person next year! I also have the pleasure of working closely with our incredible D&I team on impactful initiatives, such as helping with large external events and partnerships like the Lesbians Who Tech Summit, where we secured a top-tier sponsorship at the largest queer tech event in the world! I’ve also been part of meaningful conversations, such as expanding gender and identity options and helping to evolve and plan for benefits that help and impact the Queer community. The list goes on, really. I frequently sync with our D&I team and I’m so grateful to work somewhere that truly invests in fostering an inclusive and equitable work environment. Why MongoDB is the place for me I’ve worked in a lot of different industries, with people from every level and walk of life, and now I feel as though I’m where I was meant to be. MongoDB’s values truly align with my own, and this is the first company that I’ve seen make an actual effort to align their company objectives and goals with their values. Here’s how I live some of our MongoDB values every day: I proudly embrace the power of everyone’s differences (mine included). We evolve and move forward with a magical combination of varied backgrounds, interests, and ideas. Why bother doing anything if you don’t plan to make it matter ? I stand behind everything I work on and am proud of the meaningful projects and impacts I’ve seen first-hand so far. I’ve always been a big idea kind of human - Think Big, Go Far - I thrive on creativity, ambition, and being a relentless dreamer. When I joined, I received a postcard from our CEO. Part of it said, “We want your time here to become a real inflection point in your professional career”, and I can wholeheartedly say after just my first year, it already is. I’m constantly learning and growing at MongoDB. From management training to webinars to endless learning and development resources, and beyond. These were things I had been requesting, asking, and looking for at previous companies. They were things promised to me “eventually”, but they never came. Here I was in my first week at MongoDB, given them without asking. This is a company that truly cares about its employees’ development and success. I’ve hired (and am growing) an awesome team of amazing humans who I’m so proud to work alongside every day. Any job can be great, but the people make it extra special. The EA team at MongoDB is like no other, and I can’t wait to see its continued growth and evolution. Helping to build and evolve a world-class EA org is incredibly exciting and rewarding, and I love being a part of it. I love that I can be fully myself at work and am given the opportunity to make an impact in so many ways. I can’t wait to see what the future will bring. It’s been an unbelievable experience and journey so far! Interested in joining MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Five Tips for Writing Your Marketing Resume
We are always looking for talented and passionate marketers to join our team at MongoDB, and we want to set you up for success starting at the first step in our recruiting process. No matter how many positions you’ve applied for in the past, it’s always a good idea to refresh your resume for each application. If you’re interested in applying to our Marketing team, take a look at my tips for writing an impactful resume. Length and formatting There are some resume formatting tips that you may already know, but I think it’s great to start with the basics. I recommend keeping your resume to two pages or less and breaking it into sub-sections. The top of your resume should have your name, contact details (phone number and email address), and a link to your LinkedIn profile. Next, I recommend including a short summary of you and your experience. For marketing roles, it’s always great to get some insight into the companies and teams you have worked with, projects you have taken part in or led, and some of the main skills you feel you could bring to MongoDB. Next should be your experience. I always advise candidates to break their experience section into three different parts: Company and role: Provide a brief description of the company you previously worked at and a high-level overview of your role there. Responsibilities: Utilize bullet points to provide more detail about the main responsibilities you held while working there. Highlights and achievements: I recommend showcasing some of the main achievements you have had while working in each role. This helps provide a clear picture of your skills and capabilities. At the bottom of your resume, list your highest level of education achieved and any degrees you hold. You may also consider including additional information such as charity or volunteer work you’ve done, other activities you participate in, or hobbies and interests. While we are interested in your professional experience, we’re also interested in learning about you as a person! Highlights and achievements During the recruiting process at MongoDB, we want to learn as much as we can about you. Your resume is your chance to highlight all the great things you’ve done in your career. To reiterate the above, I recommend adding a section under each role you’ve held to list some of your top achievements. This will help show us where your strengths are and how you could impact the Marketing organization at MongoDB. Achievements could be marketing events you held and the impact they had on the organization or campaigns you ran that had a great return on investment. Any internal awards or recognitions you received would be great to add here, too. Numbers, stats, tools, and links As you are listing your highlights and achievements, I’d like to mention that adding numbers and statistics can really go a long way in making your resume stand out. For example, maybe you ran a campaign that led to an uptick in sales leads and conversions. Consider providing the data to showcase this. Visual aids like charts and graphs are also a great addition. If you have some examples of campaigns, webpages, or events you’ve managed, consider adding links to them within your resume. Resumes that are both qualitative and quantitative have the greatest impact and are quickly noticed. Listing some of the marketing tools you have used is also helpful for the recruiter and hiring manager to understand your experience with marketing technology. Under each role, I’d recommend adding a list of the tools you used and your proficiency with them. At MongoDB we use tools such as Salesforce, Tableau, Eliqua, and Splash, so if you’ve had experience with any of those, be sure to highlight it! People management If you are applying for a people management role, I recommend highlighting the mentoring and coaching experience you gained through your management experience. It is also helpful for potential hiring managers to understand how many direct reports you had in previous roles and the seniority level of these direct reports. Attention to detail As a recruiter, I've seen spelling and grammar mistakes on resumes at all levels and from all sectors. We are only human at the end of the day, but when applying for roles in areas such as marketing where attention to detail is key to success, it’s best to give your resume a second (or even third) look. Ensuring that your resume is well-written, grammatically correct, and formatted in an easily readable way will really make it stand out. I hope to see your resume in our applicant tracking system soon! Interested in pursuing a career in marketing at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Introducing the MongoDB Atlas Data API, Now Available in Preview
As the leading application data platform , we’re hyper-focused on accelerating and simplifying how developers leverage their application data. This has led to the introduction of features like serverless instances and the Atlas Triggers that minimize the operational burden associated with traditional database workloads. Today, we’re excited to announce the next step forward in this mission with the introduction of the MongoDB Atlas Data API – a fully managed, REST-like API for accessing your Atlas data. The Data API makes it easy to perform CRUD and aggregations on your data in minutes and allows you to query MongoDB from your backend in any language, without the need for drivers. The next level of data access Organizations are increasingly relying on operational data layers to build distributed architectures like microservices for their modern applications to speed-up development and stay competitive in rapidly changing markets. These stacks often require scalable, highly available, and secure access to the data layer. The most popular way to architect these data services is to build APIs that communicate with MongoDB data over HTTPS using REST or similar protocols. However, creating a custom-built API typically takes a lot of time and effort. It's a painful process that introduces unnecessary operational burdens like provisioning additional servers, connection management, and scaling. With the Atlas Data API, customers can generate a fully managed, REST-like API for their Atlas data in seconds. Developers no longer need to worry about the underlying infrastructuring of their APIs, and instead can enjoy the efficiency of intuitive, out-of-the box data access, while still being able to leverage the always-on and highly available qualities of Atlas as the underlying database. This unlocks a whole new level of developer productivity for use cases that were previously time consuming to accomplish – such as building data-centric microservices, simplifying access from serverless functions, and integrating with third party services . The API even has built-in support for aggregation pipelines to use with services like Atlas Search . Try the Atlas Data API All customers now have the ability to enable the Data API for their Atlas deployment. We invite you to try it out today with a new or existing Atlas account. It’s incredibly easy to get started: simply choose the cluster you’d like to connect to and generate an API key. That’s all it takes to set up and start accessing Atlas data. Have questions? Check out our documentation or head over to our community forums to get answers from fellow developers. What's next for the Atlas Data API This preview release is just the beginning. Support for services like Data Lake and Serverless Instances will be added over the coming months. And, long term, we see the Data API as the next step in our journey to abstract and automate infrastructure decisions – to help developers build the future faster. Atlas Data API documentation can be found here
Simplifying Compliance with VComply & MongoDB
As businesses globally are facing external pressures to be more focused on privacy, security, and transparency, compliance management is needed now more than ever. With 200+ regulatory updates, 900 regulatory agencies, and the average cost of a non-compliance incident being $14 million, maintaining compliance is critical for every business, no matter the size. Tracking, maintaining, and proving compliance has traditionally been incredibly difficult, resource-intensive, and takes a significant time commitment. That's why one startup aims to simplify compliance by disrupting the antiquated industry. Enter VComply . Founded in 2019, VComply is a governance, risk management, and compliance (GRC) platform that enables its customers with a secure and easy-to-use solution. VComply is highly configurable to meet the specific needs of any organization without additional coding or infrastructure changes. The platform collects, organizes, analyzes, and automatically reports on GRC data inputted into the system to provide a high-level view of an organization's compliance posture at any given time. Combining that with the ability to surface detailed information on any control, VComply modernizes how people work and interact with GRC programs within their businesses. In this week's #BuiltWithMongoDB, we take a look at VComply to learn more about how they are truly helping organizations strengthen their risk and compliance management. We spoke with Harshvardhan Kariwala, CEO, and Ashish Jha, Vice President of Engineering at VComply to discuss the company's journey and how they decided to build with MongoDB. What inspired you to build the business? Harshvardhan: VComply is actually my third startup. At one of my previous companies, I had become hyper-focused on building the business, and I eventually lost sight of compliance. Operational functions fell through the cracks, and I ended up outsourcing our compliance programs to this corporate firm in Singapore. Fast forward a bit, they ended up forgetting to do a required compliance filing, and we ended up responsible for paying the non-compliance fines associated with that. One reporting misstep, and we were fined. That's what got me worried. We got lucky that was all that happened. It only took one time to inspire action. We then built an internal tool where the entire idea was around creating a culture of reporting excellence and internal accountability. After adopting our newly created tool, in 2018, we realized that we built a very robust solution to real day-to-day compliance problems. We thought, "Why don't we spin this off into its own product?" By that time, I was ready to get back into product development, and this was the perfect opportunity. In early 2019 we set up VComply. We quickly got our first customer, the City of Boston, and never looked back. So that's where VComply got its start. It was never meant to be sold as a product. It was more of an internal compliance tracking tool. That's how we entered the GRC space. What exactly does VComply do? What are some of its most useful product features? Harshvardhan: We help businesses be compliant, mitigate risk, and adopt a culture of transparency. If there isn't internal alignment within a company, no tool is going to help them. At its core, VComply is designed to be easy to use so that anyone in an organization can adopt a compliance-first mindset. By removing the traditional technological barriers, we found that businesses can realize the benefits quickly. That said, VComply serves as the single source of truth for everything GRC within an organization. Think tracking compliance obligations, compliance monitoring, automating activities, alerts and follow-ups, compliance evidence collection, audit trails, and more. Another popular piece of our tool is our enterprise risk management as well as policy management functionalities. You can monitor and manage risk programs, quickly identify risks, and start linking compliance obligations to mitigate that risk. What makes VComply stand out from its competitors? Harshvardhan: Most other solutions on the market require a compliance expert, are hard to navigate, and take a significant time commitment upfront to get up and running. We built VComply to be more practical and realistic with how people manage their compliance and risk programs today. VComply is easy to set up, simple to use for the end-user, and flexible to map to the specific controls a business needs to comply with without any additional coding. How did you decide to build with MongoDB? Ashish: Easy and intuitive search support, as well as indexing and automated performance suggestions, were the key drivers for us building with MongoDB. Also, training new developers is very straightforward. What has your experience been like scaling with MongoDB? Ashish: Scaling is pretty seamless with MongoDB. Setting up alerts and monitoring is very straightforward. We've had nothing but great experiences so far. Do you have a favorite technical book or podcast that you would recommend to other tech entrepreneurs? Harshvardhan: I would recommend The Great CEO Within: The Tactical Guide to Company Building by Matt Mochary. That's definitely a great read. This is a bit of an open questions, so feel free to interpret it how you'd like. What are you currently learning? Harshvardhan: That's a tough one. I think you're always learning so many different things on any given day that it's difficult to give one answer. Today, I'm learning marketing strategies, like demand gen as well as sales tactics to scale the business. Ashish: Primarily, I'm learning how engineering can augment and support other organizations within the company. Who are some tech leaders or entrepreneurs that you admire? Ashish: I do admire Jeff Bezos quite a bit. I admire the laser focus that he has and the clarity in terms of his reasoning. Harshvardhan: Elon Musk because of his ideas and execution. One thing that's great about him is how he executes his ideas flawlessly. Interested in learning more about MongoDB for Startups? Learn more about us here .
Preparing for Your Consulting Engineer Interview at MongoDB
Are you a software professional who isn't always just about the software? Do you write code, but just as often get an equally strong sense of accomplishment by configuring a tricky but vital part of the operating system or DBMS? Do you enjoy working with a variety of computer professionals from SysAdmins to Devs to CTOs? Do you feel that special spark from knowing there's so much more to learn about the technology you eat, sleep, and breathe, and that you might never learn every last bit of it, but it'll be a heck of a ride trying to? Are data management and consulting two things you enjoy doing more than anything else? We are always on the lookout for such professionals. Those who seek the challenge. Those who can immerse themselves in every cubic millimeter of a particular stack in their quest to find “the answer”. Those who find fulfillment in helping MongoDB's customers realize every bit of potential that our products can give them. MongoDB Professional Services provides best-of-breed expertise and experience for all of our products to help our customers and community users get the most out of them. This can involve one or more of: Application Lifecycle Expertise, providing both strategic and tactical consulting from the conception to delivery to post-delivery phases of your application lifecycle Dedicated time with a dedicated MongoDB technical expert, with all of the resources of the company and the community at their disposal Public and Private Training for DBAs, DevOps Engineers, Developers, and Data Scientists Migrating customer workloads to MongoDB in Public Clouds And on the front lines is the Consulting Engineer (CE). The Jack-of-all-trades of all things MongoDB who works directly with our customers on a daily basis. What follows is a guide for those looking to join MongoDB Professional Services. We have Consulting Engineer positions available at a variety of levels, and this guidance should help make for the best possible interview experience! Do you have what we're looking for? Contrary to popular belief, you do not need to know how to use MongoDB. Trust me, that was my situation when I interviewed with MongoDB. Don't get us wrong, it is a definite “plus” to have some experience or be an expert, but no experience with MongoDB isn't a deal-breaker. It also isn't an absolute requirement to have been a Consulting Engineer before (I hadn't been), but you do need the skills and qualities that can be made into a successful CE. We look for bright, motivated people who can learn quickly, pivot effortlessly, and adapt relentlessly to a myriad of challenges and situations. People who rise up to technical challenges in pursuit of our customers' needs. We are mostly focused on customers after the sale, although we do work in tandem at times with our Account Teams. A MongoDB Consulting Engineer is well-versed in modern software stacks, database technologies, software development, deployment, and day-to-day operations. They utilize MongoDB Best Practices, deliver MongoDB Technical Training, and work with both customer Dev and Ops teams to ensure successful deployments of MongoDB-based software solutions. They are resourceful, adaptable, always willing to learn, and (if and when we get back to it) comfortable travelling a majority of the time. They enjoy interacting with software professionals on a daily basis. They enjoy representing MongoDB and its products and technologies. They enjoy real-world technical challenges. Do we have what you're looking for? The very first step in your journey is to check the Customer Engineering careers page for open Consulting Engineer positions. If one or more look like a potential fit, we encourage you to apply! As an organization, MongoDB Professional Services strives to be one of the best in the industry. We adhere to very high standards, which translates to maximum benefit to our customers. We are always learning from each other and learning about our new products and technologies as they come down the pipeline. We work hard, we have a lot of fun, and we make a difference. Because a Consulting Engineer must possess a broad skill set, there is significant potential for career growth within the organization. People management is one route, or you might decide you'll always prefer to 'stay technical' - in the latter case, consider a development path that could land you a coveted MongoDB Distinguished Engineer position some day. Alternatively, you might at some point determine that you wish to move into other Professional Services roles with other emphases, such as: Tool and Framework Development for our customers, as well as your fellow Consulting Engineers Curriculum Development, for internal or external Training offerings Engagement Management, where you working more closely with Account Teams to present Professional Services' value proposition to potential and current customers Project Management You are given extensive freedom as a MongoDB Consulting Engineer. We give you the freedom to explore, the freedom to create, the freedom to learn, and the freedom to contribute to the organization and our customers in your unique way. Do you aspire to give a presentation at a MongoDB.local or at MongoDB World? Perhaps the written word is your thing, and you'd like to try your hand at blogging for MongoDB and Professional Services (like I'm doing right here!). Or maybe you just like to develop new and interesting tools for other MongoDB users through the MongoDB Community. All of those and more are possible. Is that what you're looking for? As a company, MongoDB aims to be recognized as a leader in how we value and look after our employees, as well as our customers. Want to learn more? Check out our Life At MongoDB blog posts. Interview step one: speaking with a recruiter Once you've applied for a Consulting Engineer position, a Recruiter will review your resume and determine if they think your skills and experience could be a good fit for the role. If so, they’ll reach out to you to get to know you better and to discuss your qualifications for the particular position, your experience in the industry to date, and what you are looking for in a position with MongoDB. The more you can reflect on your experience and expertise and then show its applicability to what we're looking for, the better. Think about what you are wanting in a career at MongoDB as a Consulting Engineer and how we may be able to make that happen together. A good job fit is, after all, a two-way street. Interview step two: speaking with the hiring manager If the Recruiter confirms that you are a potential fit for Professional Services, you will be scheduled for some time with the Hiring Manager. Give some thought to the following: What do you want out of your next job? What are you looking for in a company and a manager? Why do you feel, at this point, that you are an excellent fit for this position? Pick some example experiences/situations from your past that may be relevant to this position, and be prepared to discuss them. The manager will likely share more about the overall and day-to-day expectations of the job. They will also ask if you have additional questions that they can answer to give you a fuller picture. Our goal is to give you a proper overview of the team (and its culture), Professional Services, and what it's like working at MongoDB. Interview step three: speaking with MongoDB Consulting Engineers In this phase, you will have a handful of one-hour interviews with established MongoDB Consulting Engineers. Each interview covers one or more of the following: Database expertise (Relational and non-Relational) Software development experience and familiarity Problem solving expertise and approach(es) Consulting experience/expertise Rigors of and requirements for daily customer interaction Now: Working with customers remotely (Potentially) In the future: Business travel a majority of the time (note: on hold at present due to COVID) "Soft skills" needed to be a successful MongoDB Consulting Engineer Report writing skills Verbal communication skills (1-on-1 and to groups) Dealing with various customer personalities and situations Comfort talking to customer individual contributors, management, and business stakeholders No, we do not expect you to code an O(n) sorting algorithm on a whiteboard while we wait. Nor do we expect you to install and configure a database server on the fly from a terminal window. That being said, if those sorts of things intrigue you, well…. points for that. What we will do is dig into how you attack problems, how you work with individuals and groups to find solutions, and how you make use of available resources and think outside the box when required. We also ask questions to see how quickly you can absorb new information and how quickly you can adapt to rapidly changing situations. Interview step four: speaking with the PS Director The last stage in the interview process is a chat (usually via video conference) with the Professional Services (PS) Director for that region. This can give you a slightly different perspective of the organization and the role itself, as well as added visibility into our business and company culture. The good news is that this will not be as technical as the interviews above. Before this discussion, consider what you've discussed so far in the interview process, and what other aspects of the role you have further questions about. I will say that when I interviewed back in the day, I sat down with our newly-hired head of Professional Services and asked him "where do you see the organization in two to three years?". His answer was a significant piece of why I accepted MongoDB's offer, so don't be afraid to ask what's really on your mind! Questions? I love to make connections between outstanding individual contributors and MongoDB Professional Services, so if you have any questions about this process or the jobs, feel free to drop me a line. If you’d like to hear more about my experience as a Principal Consulting Engineer, listen to this episode of The MongoDB Podcast. You can find me on LinkedIn, or by writing to me at firstname.lastname@example.org . Good luck! Interested in pursuing a career as a Consulting Engineer at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!