Sales Development Series: Meet the EMEA Account Development Team
Sales Development is a crucial part of the Sales organization at MongoDB. Our Sales Development function is broken down into Sales Development Representatives (SDRs), who qualify and validate inbound opportunities from both existing and prospective customers, and Account Development Representatives (ADRs), who support outbound opportunities by planning and executing pipeline generation strategies. Both of these roles offer an excellent path to kickstarting your career in sales at MongoDB. In this blog post, you’ll learn more about our EMEA (Europe, the Middle East, and Africa) outbound ADR team, which is divided into territories covering the UK & Ireland, the Nordics & Benelux, Central Europe, and Southern Europe. Hear from Manager David Sinnott and a few Account Development Representatives about the ADR role, team culture, and how MongoDB is enabling ADRs to grow their career. Check out the first blog in our Sales Development series here . An overview of Account Development in EMEA David Sinnot , Sales Development Manager for the UK & Ireland The Account Development team works very closely with our Enterprise Sales organization, supporting some of our largest customers across all industries. ADRs partner with Enterprise Account Executives to identify and uncover some of the biggest challenges facing their customers and through further discovery, position MongoDB as the solution to help solve whatever these challenges are. I started my own career in tech sales as a Sales Development Representative 11 years ago. In tech sales, reps will have lots of successes and challenges and personally, I have always used these experiences as a way to try and better myself. My advice to reps just starting out is when things are not going to plan, take a step back to analyze the reason why, learn from it, and implement some new methods to avoid it happening again. The opportunity to learn never stops at MongoDB. My team and I learn something new every day! Our products are always evolving and we continue to release added features and functionality, so we continually provide training around all of this. ADRs also spend a great deal of time learning about and implementing the sales methodology frameworks that MongoDB uses across the entire Sales organization. There are promotion paths available to all of the ADRs, whether that be staying in Sales or exploring other parts of the business, such as Marketing or Customer Success. All of the knowledge and skills picked up during their time as ADRs ensure that they hit the ground running once they are promoted to their next role within the business, whatever that may be. Some of the most successful Corporate and Enterprise reps in MongoDB started their own careers here as part of the ADR program. We do our absolute best to support all team members in deciding what is the best career path for them in the long term. MongoDB is disrupting an industry that largely hasn’t changed in over 40 years. We currently have around a 1% market share of the database market, which IDC predicts will be close to $119B by 2025, so the potential for MongoDB is still massive. With data being at the core of every modern-day business, organizations are having to modernize their legacy technology stacks and are starting to move more of their business functions to the cloud. MongoDB has an opportunity to play a big part in all of these initiatives and transformations. It’s still an incredibly exciting time for any sales rep out there who may be considering MongoDB for their next move. Hear from some team members Johanna Sterneck , Sr. Account Development Representative for Central Europe I joined MongoDB because I wanted to be part of a fast-growing, successful company that would help me grow professionally and personally. Over the past 10 months, every day has been a new experience and I feel that I’ve become part of something bigger. My onboarding experience was completely remote, but my team, manager, and everyone else at MongoDB have been very welcoming and supportive. The entire onboarding process was very well structured which allowed me to ramp up quickly. As an ADR, persistence in getting things done and positivity are definitely key factors in my role. What’s exciting is learning from the people around me and the great feedback culture we have. My team is very supportive, caring, and fun, and we are all happy to go the extra mile to achieve our goals. Federica Ramondino , Sr. Account Development Representative for Southern Europe I joined MongoDB because I believed it was a company where I could develop my skills and grow professionally. I’ve stayed because it lived up to my expectations! I see a clear career path for myself here, and I am excited to progress into my next role and get closer to my final objective of becoming a manager. To excel in an ADR role, you need dedication, good time and stakeholder management skills, and a positive attitude! My team is an amazing bunch of people that are always positive and keen on helping each other, even in a constantly evolving environment. What’s exciting about this role is all the other teams that you get to work with and learn from, from Sales to Customer Success and Marketing. Ruhan Jay Bora , Sr. Account Development Representative for the UK & Ireland I joined MongoDB because I was keen to work for a company creating experiences for the future, and I wanted to be a key player in helping companies digitally transform. I see myself staying at MongoDB for a while because of the heavy emphasis that leadership places on development. I have monthly catch-up sessions with the VP of Sales for EMEA, VP of Cloud Partners, and regular 1:1’s with my managers. Not a day goes by where I feel like I’m stagnating, and between learning about the latest in tech and sharpening my client-facing skills, there is plenty more room to grow! If you want to be successful as an ADR, the first thing you need to have is a tremendous work ethic. I believe sales is ultimately a game of grit, perseverance, and resilience. It’s not easy to learn so many technical concepts in the span of a few weeks, but our Sales Enablement team has compiled a bevy of excellent and readily digestible content that makes upskilling on MongoDB much easier. I will be moving into a new organization formed by our Sales team called the Associate Account Executive program. I harbor an ambition to become an Enterprise Account Executive, and this program will help me to develop the skills needed to work regularly with some of our most exciting clients! The feeling of seeing a client's satisfaction and astonishment at how MongoDB can solve some of their technical and business challenges truly amazes you. Hearing how great MongoDB is directly from clients makes you realize we really have a great product. I also find that the opportunity to accelerate your career here is extremely tangible. The company is young enough for you to shape your own path and no goal is too ambitious. The ability to engage with senior leadership up to the C-level is great too. Interested in joining the Sales team at MongoDB? We have several open roles on our team and would love for you to transform your career with us!
Real-time Applications Made Simple with MongoDB and Redpanda
MongoDB has a long history of advocating for simplicity and focusing on making developers more agile and productive. MongoDB first disrupted the database market with the document model, storing data records as BSON (binary representation of JSON documents). This approach to working with data enables developers to easily store and query their data as they use it naturally within their applications. As your data changes, you simply add an attribute to your documents and move on to the next ticket. There is no need to waste time altering tables and constraints when the needs of your application change. MongoDB is always on the lookout for more ways to make life easier for developers, such as addressing the challenges of working with streaming data. With streaming data, it may take armies of highly skilled operational personnel to build and maintain a production-ready platform (like Apache Kafka). Developers then have to integrate their applications with these streaming data platforms resulting in complex application architectures. It’s exciting to see technologies like Redpanda seeking to improve developer productivity for working with streaming data. For those unfamiliar with Redpanda, it is a Kafka API compatible streaming platform that works with the entire Kafka ecosystem, such as Kafka-Connect and popular Kafka drivers : librdkafka , kafka-python , and the Apache Kafka Java Client . Redpanda is written in C++ and leverages the RAFT protocol, which makes Apache ZooKeeper irrelevant. Also, its thread-per-core architecture and JVM-free implementation enable performance improvements over other data streaming platforms. On a side note, MongoDB also implements a protocol similar to RAFT for its replica set cluster primary and secondary elections and management. Both MongoDB and Redpanda share a common goal of simplicity and making complex tasks trivial for the developer. So we decided to show you how to pull together a simple streaming application using both technologies. The example application (found in this GitHub repository ) considers the scenario where stock ticker data is written to a Redpanda and consumed by MongoDB. Once you have the example running, a “stock generator” creates a list of 10 fictitious companies and starts writing ticker data to a Redpanda topic. Kafka Connect service listens for data coming into this topic and “sinks” the data to the MongoDB cluster. Once landed in MongoDB, the application issues an aggregation query to determine the moving averages of the stock securities and updates the UI. MongoDB consumes the ticker data and calculates the average stock price trends using the aggregation framework . Once you have downloaded the repository, a docker-compose script includes a Node server, Redpanda deployment, Kafka Connect service, and a MongoDB instance. The Kafka Connect image includes the Dockerfile-MongoConnect file to install the MongoDB Connector for Apache Kafka . The Dockerfile-Nodesvr is included in the nodesvr image and it copies the web app code & installs the necessary files via NPM. There is a run.sh script file that will launch the docker-compose script to launch the containers. To start the demo, simply run this script file via sh run.sh and upon success, you will see a list of the servers and their ports: The following services are running: MongoDB server on port 27017 Redpanda on 8082 (Redpanda proxy on 8083) Kafka Connect on 8083 Node Server on 4000 is hosting the API and homepage Status of kafka connectors: sh status.sh To tear down the environment and stop these services: docker-compose down -v Once started, navigate to localhost:4000 in a browser and click the “Start” button. After a few seconds, you will see the sample stock data from 10 fictitious companies with the moving average price. Get started with MongoDB and Redpanda This example showcases the simplicity of moving data through the Redpanda streaming platform and into MongoDB for processing. Check out these resources to learn more: Introduction to Redpanda MongoDB + Redpanda Example Application GitHub repository Learn more about the MongoDB Connector for Apache Kafka Ask questions on the MongoDB Developer Community forums Sign up for MongoDB Atlas to get your free tier cluster
Driving Innovation with MongoDB Atlas on Google Cloud
MongoDB Atlas and Google Cloud’s global partnership continues to set the standard for cloud modernization across industries. Our joint solution helps customers modernize their database stack when they migrate their infrastructure to the cloud, ultimately boosting developer productivity and reducing total cost of ownership (TCO) while giving customers access to state-of-the-art analytics and the machine learning capabilities of Google Cloud. Our partnership is producing plenty of exciting developments—read on to learn more about our joint awards, latest integrations, and what’s next. Earlier this month on October 12, MongoDB was announced as a Google Cloud Cross-Industry Customer of the Year . On the heels of an expanded, five-year partnership that began earlier in 2021, MongoDB and Google Cloud continue to create excellent customer experiences for our joint customers across the globe. Adopted by clients in the gaming, retail, healthcare, financial services, and automotive industries, among others, MongoDB Atlas on Google Cloud is experiencing exciting year-over-year growth in a variety of innovative fields. After putting much effort into launching joint integrations to become a first-class database within Google Cloud Marketplace, MongoDB was also named Google Cloud Technology Partner of the Year Award - Marketplace —for the 2nd year in a row . Since being made available on Google Cloud Console and Marketplace, MongoDB Atlas on the Marketplace has rapidly become the preferred engagement model for users. MongoDB Atlas on the Marketplace is available as a pay-as-you-go offering, and clients can now use their Google Cloud spending commitments toward Atlas to take advantage of integrated billing and support. The intuitive database structure of MongoDB combined with the cloud computing power and security of Google Cloud enables clients to take a quantum leap forward from their legacy systems. With MongoDB Atlas on Google Cloud, companies gain the power to scale effortlessly, maintain business-critical reliability, and cut costs. So, what's the latest? Today’s users expect a seamless application experience regardless of where they’re located. MongoDB Atlas delivers responsive and reliable applications worldwide alongside continuous support for new regions. Most recently, three new Google Cloud regions for Atlas dedicated clusters were released in Delhi (asia-south2), Melbourne (australia-southeast2), and Warsaw (europe-central2)—for a total of 27 supported regions, allowing customers to deploy fully managed MongoDB databases in every Google Cloud region. These regions expand the geographical coverage not just of Atlas on Google Cloud, but Atlas as a whole. The availability of Atlas in new regions will provide lower-latency access to data, offer more options for disaster recovery globally, and make it easier for customers to satisfy local regulatory and compliance requirements. Companies across the world are benefitting from our global partnership. In Japan, e-commerce analytics company PLAID has migrated to MongoDB Atlas on Google Cloud to automate operational tasks like version upgrades and backups. And in North America, the largest tire distributor on the continent, ATD, now has its own custom event-driven architecture that’s accessible, pluggable, and scalable to support the company’s expanding business horizons. ATD can now scale up for bulk one-time loads and process more than 50 million transactions in less than four hours, which is nearly 5x their real-time transactions per day. In a development that was just announced, MongoDB Atlas now allows users to deploy a serverless database on Google Cloud via serverless instances , available in preview. Serverless computing is becoming increasingly popular among developers due its undeniable benefits—including consumption-based pricing and a service that scales dynamically as needed, which eliminates the need to provision and manage capacity needs. Serverless computing abstracts and automates away many of the lower-level infrastructure decisions that consume precious developer time so they can instead focus on building differentiated features. With serverless instances, users can get started with minimal configuration—simply choose a region and give your database a name and Atlas will provide the resources your app needs. For any company that needs faster insights from data stored all over their organization, Google Cloud introduced Datastream, and MongoDB Atlas was excited to be a launch partner . Datastream is a new serverless change data capture and replication service that allows developers to easily stream data from relational databases like Oracle and MySQL to MongoDB Atlas. By making data more accessible, Datastream and MongoDB Atlas help companies make their data more actionable, and therefore more valuable. Announced in August 2021, Google Cloud’s Private Service Connect (PSC) is now generally available in all Google Cloud regions . By abstracting the underlying networking infrastructure, PSC allows users to create private and secure connections from cloud networks to services like MongoDB. PSC will allow Google Cloud customers to use MongoDB Atlas more easily, while ensuring that the connectivity is private and secure. Connecting MongoDB Atlas with Google Cloud services will make it possible for enterprises to innovate faster. Together, MongoDB and Google Cloud are developing ways for companies to accelerate digital transformation, empower employees, and raise customer satisfaction to new levels. Learn more about what your organization can do with MongoDB and Google Cloud at our first-ever joint Developer Summit on October 28. Sign up now to hear directly from your peers about how they’re using the combined power of MongoDB and Google Cloud, and participate in a live developer Q&A.
How to Prepare for Your Engineering Interview at MongoDB
MongoDB’s Engineering team is full of creative individuals who play an impactful role in building our industry-leading technology. Our interview process is designed to ensure that you and MongoDB are a great match, and, no matter how many interviews you have done in the past, being prepared is the key to being successful. At MongoDB, we do our best to make sure you have a great interview experience and an opportunity to learn about our company, culture, and the people you will be working with. To help you prepare for your technical interviews, we want to share some tips. Research is key Candidates who do research and come prepared for interviews at MongoDB are able to make the most of their interview process. People sometimes think they do not need to do research because they are already familiar with our products, but that will set you up for unexpected surprises. Before beginning your interviews, you should have high-level knowledge of our company’s mission, values, and goals . The in-depth technical information you can learn about MongoDB and the role and team you are interviewing for may also help set you apart from other candidates. MongoDB has a variety of products and Engineering teams, and this information will give you a chance to learn more about what we are working on, technical stacks we use, and what you’d be contributing to if you joined. Take a look at some of the resources below, and use them to your advantage. MongoDB Blog : Our blog is updated regularly with new posts about life at MongoDB, news, products, and events. MongoDB University : This platform was created to empower developers through education. We offer completely free online courses led by Curriculum Engineers for any learner, whether you’re just getting started or already familiar with MongoDB. MongoDB Documentation : The documentation page has detailed information about our products and tools that will give you an idea of what you will be working on as an engineer. MongoDB Developer Hub : The developer hub provides articles on and resources for how to get started with MongoDB. Learn from our Developer Advocates and the MongoDB community! Types of interviews After doing some initial research, it is important to prepare for the actual interviews. Our interview process usually includes one or two virtual interviews and then an onsite interview, which we are currently conducting via Zoom. This may change in accordance with company and COVID-19 guidelines. These interviews and what they cover will vary by team, so it is important to speak with your recruiter and ask for any additional tips or insight into what to expect. Our recruiting process is primarily team-based, which means you’ll interview for a role on a specific team, and many of your interviewers will be team members, as well as your manager. In general, you can expect to receive questions about your background, interest in MongoDB, and why you are interviewing to work with that team. You’ll also have the opportunity to ask your interviewers questions about all things MongoDB. Technical Interviews Technical interviews have a variety of areas that may be covered, including concurrency, distributed systems, algorithms, system design, and language-specific coding. An important part of the technical interview that often goes under the radar is the need for effective communication when talking through your thought process or discussing the problems that are presented. Below are some of the things our engineers look for in a good technical performance. Writing code: strong understanding of the language being used, code is concurrency-safe, works in edge cases, good object-oriented design Software engineering: understanding of data structures and algorithms, considering trade-offs (e.g., run time vs. memory), testing your code Collaboration: clear and concise code that is readable and organized, responding well to suggestions or hints, effective communication about difficulties faced Systems design: design a solution to scale to high levels of concurrency, throughput, and reliability. Does it avoid common bottlenecks, how do we prove its correctness, and what are the trade-offs or alternative solutions? Behavioral Interviews Behavioral interviews focus on how you may add to the culture we continue to build at MongoDB. Reviewing our code of conduct and core values will show you how we operate as a company and what we expect from our employees. Other topics of discussion you should expect in these interviews are successes and failures, what you have learned from these experiences, and what you are looking for in your next role. We will also ask you about your experience with mentoring and learning from other engineers and leaders, your goals and aspirations for the future, and your experience with owning or leading projects. What we offer There are a few things we can promise if you decide to interview for an Engineering role at MongoDB. First, you’ll have a speedy and transparent process with a single, dedicated recruiter. We tailor each of our interview processes to fit the role’s responsibilities and seniority level, and you won’t be asked any riddle questions that aren’t related to the work you’d be doing. Our interview questions are typically sourced from real problems we have had to solve. You’ll also have the opportunity to interact with your future manager and some future teammates, and we hope you find that your interviewers are genuinely interested in you as a person and seeing you succeed at MongoDB. We believe different experiences, identities, and perspectives build a unique culture that helps us create and innovate the next generation of MongoDB. In short, following this guide will help prepare you for a successful interview at MongoDB. Ensure you have gained some knowledge about our company, mission, and goals; the role you’re interviewing for and the team you’d be working on; and the types of interview questions you may be asked. And be prepared with questions for us! We’re so glad you’re interested in joining our team, and we look forward to seeing you in the interview process. Interested in pursuing a career in engineering at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
BDR to CRO: Empowering Salespeople to Own Their Career Path at MongoDB
Hear from VP of Sales Productivity Frank Chisholm to learn more about how MongoDB’s BDR to CRO program enables professional development and empowers salespeople to take control of their career path. An overview of BDR to CRO At MongoDB, we believe our people are our biggest asset. We also understand that in today’s world of agile practices, remote working, and ever-increasing digitization, it is important that we empower our salespeople with the tools and vision they need to navigate such fluidity. The Business Development Representative to Chief Revenue Officer (BDR to CRO) program ensures that our salesforce is prepared to drive results within their career path and, as a result, play an integral part in the overall MongoDB growth story. This program structures the learning and development process and ensures our salespeople know all the career options available to them at MongoDB. Whether they aspire to move within Sales or to a different function or different geography, BDR to CRO will help employees navigate the learning and development needed to make their goals a reality. The goal of the BDR to CRO program is to ensure there is transparency, meritocracy, and flexibility by providing options to help MongoDB salespeople build their careers, offering clarity concerning key promotional criteria, and outlining the standards of excellence that need to be met consistently when assessing mobility readiness. Mobility within the Sales organization The Sales organization has outlined four dimensions of mobility for our team members. For those who prefer to stay in an individual contributor (IC) role, there is a clear development path from Business Development or Sales Development into Corporate and Enterprise Sales roles. For those interested in progressing into sales management, we have several routes from Corporate and Enterprise Sales into management positions. We also support internal transfers for anyone interested in exploring roles on other teams within the broader Sales ecosystem at MongoDB, and we have outlined skill development plans at both the IC and management levels to help our salespeople make these transfers possible. We recognize that we’re a global company, and our team members may be interested in (inter)national mobility — and in some cases it may be necessary. There are countless opportunities at the IC and management levels, as well as within the broader Sales ecosystem globally. Upskill programs Often, taking the next step in your career can be more difficult than anticipated. Our BDR to CRO upskill programs are designed to outline the skills and knowledge needed to excel in a new role, identify your areas of growth, and help you bridge those gaps to ensure you’re set up for success. We currently run three specific upskill programs aimed at preparing our salesforce for progression into their next role of interest: Sales Development to Corporate Sales, Corporate Sales to Enterprise Sales, and Aspiring Manager. In addition to completing the upskill program, this next career step is dependent on achieving the following criteria: Achieving your numbers consistently Understanding how you reach your numbers and being able to teach your sales process Inspiring others by being a role model Gaining the trust and respect of your colleagues Building camaraderie and having an overall positive impact on your team The combination of completing an upskill program and achieving promotion criteria has proven to set our salespeople up for success in their new roles. Sales Development to Corporate Sales This upskill program prepares our Sales Development Representatives (SDRs) for a Corporate Sales (Inside Sales) role at MongoDB. The program is broken into three phases over three months. In the first phase, SDRs participate in “deep dive” sessions on the topics of professional services, sales discovery, and MongoDB Atlas. In the second phase, reps participate in weekly roleplay sessions and call shadowing with mentors, who provide feedback on rep strengths and areas of improvement. In the final phase, reps participate in enablement sessions focused on MRR processes, account prioritization, and account management throughout the sales cycle, and take the lead on setting up customer meetings and managing their own list of accounts. Lavish Khurana , Cloud Account Executive, Gurugram I started my journey with MongoDB in December 2018 as a Business Development Representative. During my work in research, I had the opportunity to explore many career paths, and I saw sales as the place I wanted to build my career. I transitioned into a Sales Development Representative role, where I had my first interaction with customers and learned how they use MongoDB and how it enables developers to build faster than ever before. I still wanted to manage the full sales cycle though. The BDR to CRO program is run with transparency and offers one-of-a-kind training that helped me improve my sales and technical discovery skills. It also provides a clear career path to advance within the Sales organization at MongoDB. After successfully completing the BDR to CRO upskill program, I was promoted to Cloud Account Executive. The constant support and coaching the management team has provided me are unparalleled. Corporate Sales to Enterprise Sales Our management team identifies high-potential Corporate Account Executives (CAEs) to be considered for future Enterprise Account Executive (EAE) roles based on promotion criteria and individual CAE career goals. Once selected, CAEs participate in a three- to six-month upskill program focused on mentorship and call shadowing; extended account planning and management; pipeline generation planning and execution; and exposure to the EAE role, team, and leadership. Marie-Christine Van Parys , Account Executive, Paris When I joined MongoDB in 2017, the BDR to CRO program was not yet created, and every role I took on as a new challenge helped build the program and the processes we have in place today. I started my journey as a Sales Development Representative and have progressed through both Cloud and Corporate Sales to achieve the role of Mid-Market Account Executive within our Enterprise team. As soon as the BDR to CRO program was set up, I was able to benefit from and contribute to the various upskill programs that supported me throughout my move from Cloud to Corporate to Enterprise. The program provides clear guidelines to help plan the direction I want to take my career. Creating the BDR to CRO program is a powerful message from our leadership team that shows MongoDB’s commitment to growing the sales leaders of tomorrow. Being part of the Sales organization at MongoDB isn’t just about being a good sales representative; it’s about being part of a growth-mindset community. The past four years I’ve spent in the Sales organization have been a constant learning experience. First, there’s the quickly evolving market, which represents a huge opportunity and an ongoing challenge. The constant learning of the technology and the competition always keeps you on your toes. Then there’s the leadership team, which is committed to giving you all the tools needed to be successful. This support allows us to be true professional partners to our customers. There is always room to learn more, which not only helps you grow as a professional, but also as an individual. At MongoDB, I see exponential career growth; the opportunity to continue building new teams, programs, and territories; and the support from both peers and leaders who are deeply committed to my success and development. On top of this, the BDR to CRO program offers a clearly defined path to achieving the next step in my career journey. Aspiring Manager Program The six-month Aspiring Manager Program aims to help CAEs and EAEs gain experience in recruitment, coaching, people development, forecasting, and territory management as they explore taking on a leadership role at MongoDB. Program participants will have a lead role in regional training, offering their expertise in a given area such as pipeline generation, champion building, and sales process and execution. They will work with current Regional Directors and VPs to better understand the MongoDB sales candidate profile, interview tactics, and the feedback and selection process, and build skills related to forecasting and qualification and territory planning and management. Participants will also be official mentors to a new hire and take responsibility for specific areas of their onboarding process, from call shadowing to territory management, and will help drive their development through coaching and training. Individuals also will take part in training sessions on managing inclusively and having crucial conversations. Graduates of this program will move into first-line sales management roles. Arman Jam Jam , Regional Director, Paris I began as an Enterprise Account Executive for the French market in June 2019. After going through the BDR to CRO program, I was promoted to Regional Director in February 2021. The BDR to CRO program was well structured and helped me manage expectations for the Regional Director role. I was provided a plan that outlined areas of growth to be a successful leader that helps my team grow. The most exciting part of the BDR to CRO program was related to personal development, such as having crucial conversations with our customers, team, and management. This training in particular has helped me effectively communicate in my new role. I really enjoyed that all the training sessions were group sessions, which allowed for open discussion and feedback among group members. We could share any feelings, fears, or questions that came up during the program. I also received a dedicated “buddy” for the duration of the program, which helped me build relationships with other stakeholders at MongoDB. The exercises, the involvement of every leader, and the open discussions with my peers helped me grow and improve upon the skills needed to be successful in a Regional Director role at MongoDB. Although I’m always working on improvement, I’m already a better version of myself due to the great experience and training I received in the BDR to CRO program. Internal transfers MongoDB is committed to the internal promotion and development of all employees, and we encourage employees to expand their skill set within MongoDB. The Sales organization has supported employee transfers out of direct sales roles and into enablement, operations, customer success, and partnership roles, among others. We’ve also had individuals transfer into sales roles from other teams . Lacy Ceder , Customer Success Manager, Austin, Texas I joined MongoDB in 2019 as a Cloud Account Executive. Being customer focused, my favorite part of both sales and customer success has been seeing product adoption firsthand and watching my customers grow. Before Cedric, our CRO, and the Sales leadership team implemented the BDR to CRO program, the idea of moving into any role other than sales didn’t seem possible. The BDR to CRO program enabled me to find a role that encompassed everything I loved about sales but through a different avenue. As a Cloud Account Executive, I had the opportunity to connect with our early Atlas customers directly, helping them adopt best practices, hit project deadlines, and explore new features. This sparked my interest in making the transition into our Customer Success program, where I would be able to use those passions to further my career. Leadership was supportive of my long-term goals, and they facilitated introductions to internal stakeholders and helped me prepare for interviews, making the transition smooth and allowing me to take a much-needed week off to rest before starting my new role. My experience and tenure at the company allowed me to ramp into my Customer Success role quickly and focus on the technical piece of my job. Because of this program, Sales employees are able to explore roles such as Customer Success Manager while remaining close to the Sales ecosystem. International mobility All employees are welcome to explore international career opportunities within MongoDB, and we currently have employees in over 20 countries. We’ve had multiple Sales employees relocate to build out a team or better support customers in a specific region. Gracie Harris , Cloud Account Executive, Sydney I started my career at MongoDB in November 2018 as a Sales Development Representative (SDR) in Austin, Texas. My goal was to transfer internationally with MongoDB, something I emphasized to my manager and other internal stakeholders throughout my time in Austin. In May 2019, my colleague Ed Liao transferred to the Sydney office as an SDR. It was exciting to see that international mobility was not only possible, but also encouraged by MongoDB’s sales leadership team. When a similar opportunity to transfer to Sydney became available at the end of 2019, I knew it was exactly what I wanted to do. I connected with Jeremy Powers ( who had relocated to Sydney from the U.S. shortly before me ) and Ed to discuss Australia’s Sales team, their expectations, and all the other details you have to manage when moving across the globe. Eventually, I packed up my life and headed to Sydney in March 2020. I’ve been in Australia for about a year and a half, and I have grown more as a person and in my career than I ever thought possible. It’s been amazing to be a part of the Australia/New Zealand (ANZ) Sales team as it’s changed and grown over the past 18 months. I was the first member of the newly started ANZ Cloud Account Executive team, and I have an incredible group of colleagues. We lift each other up and have a great time together. Moving to Sydney is one of the best things I’ve ever done for myself and my career, and I’m excited to see how I continue to grow with MongoDB as my journey progresses. Why Sales at MongoDB? As part of MongoDB’s Sales organization, you’re more than an employee number. Our Sales leadership team is deeply committed to investing in our salespeople and fostering a culture of learning and growth. The BDR to CRO program exemplifies this commitment as we work to build a salesforce that’s passionate about their roles in MongoDB’s story. Whether you’re interested in moving up into corporate, enterprise, or management roles; joining other teams; or relocating, our Sales leaders look forward to helping you achieve the next step in your career. Interested in pursuing a career in sales at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Safe Software Deployment: The 180 Rule
In my last post , I talked about the anxiety developers feel when they deploy software, and the negative impact that fear has on innovation. Today, I’m offering the first of four methods I’ve used to help teams overcome that fear: The 180 Rule. Developers need to be able to get software into production, and if it doesn’t work, back it out of production as quickly as possible and return the system to its prior working state. If they have confidence that they can detect problems and fix them, they can feel more confident about deploying. All deployments have the same overall stages: Deployment: You roll the software from staging to production, either in pieces -- by directing more and more transactions to it -- or by flipping a switch. This involves getting binaries or configuration files reliably to production and having the system start using them. Monitoring: How does the system behave under live load? Do we have signals that the software is behaving correctly and performantly? It’s essential that this monitoring focuses more on the existing functionality than just the “Happy Path” of the new functionality. In other words, did we damage the system through the rollout? Rollback: If there is any hint that the system is not working correctly, the change needs to be quickly rolled back from production. In a sense, a rollback is a kind of deployment, because you’re making another change to the live system: returning it to a prior state. The “180” in the name of the rule has a double meaning. Of course, we’re referring here to the “180 degree” about-face of a rollback. But it’s also a reference to an achievable goal of any deployment. I believe that any environment should be able to deploy software to production and roll it back if it doesn’t work in three minutes, or 180 seconds. This gives 60 seconds to roll binaries to the fleet and point your customers to them, 60 seconds to see if the transaction loads or your canaries see problems, and then 60 seconds to roll back the binaries or configurations if needed. Of course, in your industry or for your product, you might need this to be shorter. But the bottom line is that a failed software deployment should not live in production for more than three minutes. Developers follow these three stages all the time, and they often do it manually. I know what you’re thinking: “How can any human being deploy, monitor, and roll back software that fast?” And that is the hidden beauty of the 180 Rule. The only way to meet this requirement is by automating the process. Instead of making the decisions, we must teach the computers how to gather the information and make the decisions themselves. Sadly, this is a fundamental change for many companies. But it’s a necessary change. Because the alternative is hoping things will work while fearing that they will not. And that makes developers loath to deploy software. Sure, there are a lot of tools out there that help with deployments. But this is not an off-the-shelf, set-it-and-forget-it scenario. You, as the developer, must provide those tools with the right metrics to monitor and the right scripts to both deploy the software and possibly roll it back. The 180 Rule does not specify which tools to use. Instead it forces developers to create rigorous scripts and metrics, and ensure they can reliably detect and fix problems quickly. There’s a gotcha that many of you are thinking of: The 180 Rule is not applicable if the deployment is not reversible. For example, deploying a refactored relational schema can be a big problem, because a new schema might introduce information loss that prevents a roll-back. Or the deployment might delete some old config files that aren’t used by the new software. I’ll talk more about how to avoid wicked problems like these in my subsequent posts. But for now, I’m interested to hear what you think of The 180 Rule, and whether you’re using any similar heuristics in your approach to safe deployment.
Safe Software Deployment: Overcoming the Fear and Loathing of Pushing to Prod
Over the course of my career, I’ve had the privilege of deploying many different types of software. I’ve shipped CDs. I’ve pushed customer software over the web. I’ve updated database instances and control planes. And I’ve live-updated large, running, mission-critical systems. I call this a privilege because getting software into the hands of end users is what software engineers love most. But deployments are not all fun and games. And while each deployment presents its own unique challenges, there is one thing they all have in common: fear. Those of you responsible for significant software deployments know exactly what I’m talking about. You work, you prepare, you test. But when the day finally comes for your software to set sail, you are left hoping and praying it proves seaworthy on the Ocean of Production. In most companies, production is so different from your development and staging environments, that it’s almost impossible to know whether the code that worked in staging is going to succeed in production. Yet one thing is certain: if your software fails, everybody is going to know about it. Hence the fear. When it comes to understanding the effects of fear on the developer, I think Frank Herbert, author of the epic science-fiction saga Dune, said it best: “Fear is the mind-killer.” Fear undermines experimentation and the entrepreneurial spirit. It discourages risk-taking and leads to bad habits, like avoiding deployment for months. And worst of all, fear slows down the innovation process. (See my post on the Innovation Tax many organizations are paying, and don’t know it.) Pushing to production is undeniably scary. But over the last 30 years, working with my peers, I’ve developed a few methods for creating the conditions for safe, confident deployments. And my next four blogs in this series will unpack each of them in turn: · The 180 Rule - Enabling fast, automated, easily reversible deployments · Z Deployments - Limiting downtime from failed rollbacks · The Goldilocks Gauge - Making the size and frequency of deployments just right . Through the Looking Glass - Ensuring alignment between Dev, Stage, and Prod environments These methodologies aren’t perfect and they won’t guarantee you a bug-free deployment. But they’re the best practices I’ve seen. And they help create a culture of confidence within an engineering team, which is the foundation of meaningful innovation. To get started, my next blog will explain the “180 Rule” to help you reduce outage minutes in production. In the meantime, feel free to share your own tips and techniques for safe deployments with @MarkLovesTech .
Build a Single View of Your Customers with MongoDB Atlas and Cogniflare's Customer 360
The key to successful, long-lasting commerce is knowing your customers. If you truly know your customers, then you understand their needs and wants and can identify the right product to deliver to them—at the right time and in the right way. However, for most B2C enterprises, building a single view of the customer poses a major hurdle due to copious amounts of fragmented data. Businesses gather data from their customers in multiple locations, such as ecommerce platforms, CRM, ERP, loyalty programs, payment portals, web apps, mobile apps and more. Each data set can be structured, semi-structured or unstructured, delivered as stream or require batch processing, which makes compiling already fragmented customer data even more complex. This has led some organizations to bespoke solutions, which still only provide a partial view of the customer. Siloed data sets make running operations like customer service, targeted marketing and advanced analytics—such as churn prediction and recommendations—highly challenging. Only with a 360 degree view of the customer can an organization deeply understand their needs, wants and requirements, as well as how to satisfy them. A single view of that 360 data is therefore vital for a lasting relationship. In this blog, we’ll walk through how to build a single view of the customer using MongoDB’s database and Cogniflare’s Calledio Customer 360 tool. We’ll also explore a real-world use case focused on sentiment analysis. Building a single view with Calleido's Customer 360 With a Customer 360 database, organizations can access and analyze various individual interactions and touchpoints to build a holistic view of the customer. This is achieved by acquiring data from a number of disparate sources. However, routing and transforming this data is a complex and time-consuming process. Many of the existing Big Data tools often aren’t compatible with cloud environments. These challenges inspired Cogniflare to create Calleido . Figure 1: Calleido Customer 360 Use Case Architecture Calleido is a data processing platform built on top of battle-tested open source tools such as Apache NiFi. Calleido comes with over 300 processors to move structured and unstructured data from and to anywhere. It facilitates batch and real-time updates, and handles simple data transformations. Critically, Calleido seamlessly integrates with Google Cloud and offers one-click deployment. It uses Google Kubernetes Engine to scale up and down based on the demand, and provides an intuitive and slick low-code development environment. Figure 2: Calleido Data Pipeline to Copy Customers From PostgreSQL to MongoDB A real-world use case: Sentiment analysis of customer emails To demonstrate the power of Cogniflare’s Calleido , MongoDB Atlas , and the Customer 360 view, consider the use case of conducting a sentiment analysis on customer emails. To streamline the build of a Customer 360 database, the team at Cogniflare created flow templates for implementing data pipelines in seconds. In the upcoming sections, we’ll walk through some of the most common data movement patterns for this Customer 360 use case and showcase a sample dashboard. Figure 3: Sample Customer Dashboard The flow commences with a processor pulling IMAP messages from an email server (ConsumeIMAP). Each new email that arrives into the chosen inbox (e.g. customer service), triggers an event. Next, the process extracts email headers to determine topline details about the email content (ExtractEmailHeaders). Using the sender's email, Calleido identifies the customer (UpdateAttribute) and extracts the full email body by executing a script (ExecuteScript). Now, with all the data collected, a message payload is prepared and published through Google Cloud Platform (GCP) Pub/Sub (Kafka can also be used) for consumption by downstream flows and other services. Figure 4: Translating Emails to Cloud PubSub Messages The GCP Pub/Sub messages from the previous flow are then consumed (ConsumeGCPPubSub). This is where the power of MongoDB Atlas integration comes in as we verify each sender in the MongoDB database (GetMongo). If a customer exists in our system, we pass the email data to the next flow. Other emails are ignored. Figure 5: Validating Customer Email with MongoDB and Calleido Analysis of the email body copy is then conducted. For this flow, we use a processor to prepare a request body, which is then sent to Google Cloud Natural Language AI to assess the tone and sentiment of the message. The results from the Language Processing API then go straight to MongoDB Atlas so they can be pulled through into the dashboard. Figure 6: Making Cloud AutoML Call with Calleido End result in the dashboard: The Customer 360 database can be used in internal back-office systems to supplement and inform customer support. With a single view, it’s quicker and more effective to troubleshoot issues, handle returns and resolve complaints. Leveraging information from previous client conversations ensures each customer is given the most appropriate and effective response. These data sets can then be fed into analytics systems to generate learnings and optimizations, such as associating negative sentiment with churn rate. How MongoDB's document database helps In the example above, Calleido takes care of copying and routing data from the business source system into MongoDB Atlas, the operational data store (ODS). Thanks to MongoDB’s flexible data structure, we can transfer data in its original format, and subsequently implement necessary schema transformations in an iterative manner. There is no need to run complex schema migrations. This allows for the quick delivery of a single view database. Figures 7 & 8: Calleido Data Pipelines to Copy Products and Orders From PostgreSQL to MongoDB Atlas Calleido allows us to make this transition in just a few simple steps. The tool runs a custom SQL query (ExecuteSQL) that will join all the required data from outer tables and compile the results in order to parallelize the processing. The data arrives in Avro format, then Calleido converts it into JSON (ConvertAvroToJSON) and transforms it to the schema designed for MongoDB (JoltTransformJSON). End result in the Customer 360 dashboard: MongoDB Atlas is the market-leading choice for the Customer 360 database. Here are the core reasons for its world-class standard: MongoDB can efficiently handle non-standardized schema coming from legacy systems and efficiently store any custom attributes. Data models can include all the related data as nested documents. Unlike SQL databases, MongoDB avoids complicated join queries, which are difficult to write and not performant. MongoDB is rapid. The current view of a customer can be served in milliseconds without the need to introduce a caching layer. The MongoDB flexible schema model enables agility with an iterative approach. In the initial extraction, the data can be copied nearly exactly as its original shape. This drastically reduces latency. In subsequent phases, the schema can be standardized and the quality of the data can be improved without complex SQL migrations. MongoDB can store dozens of terabytes of data across multiple data centers and easily scale horizontally. Data can be shared across multiple regions to help navigate compliance requirements. Separate analytics nodes can be set up to avoid impacting performance of production systems. MongoDB has a proven record of acting as a single view database, with legacy and large organizations up and running with prototypes in two weeks and into production within a business quarter. MongoDB Atlas can autoscale out of the box, reducing costs and handling traffic peaks. The data can be encrypted both in transit and at rest, helping to accomplish compliance with security and privacy standards, including GDPR, HIPAA, PCI-DSS, and FERPA. Upselling the customer: Product recommendations Upselling customers is a key part of modern business, but the secret to doing it successfully is that it’s less about selling and more about educating. It’s about using data to identify where the customer is in the customer journey, what they may need, and which product or service can meet that need. Using a customer's purchase history, Calleido can help prepare product recommendations by routing data to the appropriate tools such as BigQuery ML. These recommendations can then be promoted through the call center and marketing teams for both online or mobile app recommendations. There are two flows to achieve this: preparing training data and generating recommendations: Preparing training data First, appropriate data from PostgreSQL to BigQuery is transferred using the ExecuteSQL processor. The data pipeline is scheduled to execute periodically. In the next step, appropriate data is fetched from PostgreSQL, dividing it to 1K row chunks with the ExecuteSQLRecord processor. These files are then passed to the next processor which uses load balancing enabled to utilize all available nodes. All that data then gets inserted to a BigQuery table using the PutBigQueryStreaming processor. Figure 9: Copying Data from PostgreSQL to BigQuery with Calleido Generating product recommendations Next, we move on to generating product recommendations. First, you must purchase Big Query capacity slots, which offer the most affordable way to take advantage of BigQuery ML features. Here, Calleido invokes an SQL procedure with the ExecuteSQL processor, then ensures that the requested BigQuery capacity is ready to use. The next processor (ExecuteSQL) executes an SQL query responsible for creating and training the Matrix Factorization ML model using the data copied by the first flow. Next in the queue, Calleido uses the ExecuteSQL processor to query our trained model to acquire all the predictions and store them in a dedicated BigQuery table. Finally, the Wait processor waits for both capacity slots to be removed, as they are no longer required. Figure 10 & 11: Generating Product Recommendations with Calleido Then, we remove old recommendations through the power of two processors. First, the ReplaceText processor updates the content of incoming flow files, setting the query body. This is then used by the DeleteMongo processor to perform the removal action. Figure 12: Remove Old Recommendations The whole flow ends with copying Recommendations to MongoDB. The ExecuteSQL processor fetches and aggregates the top 10 recommendations per user, all in chunks of 1k rows. Then, the following two processors (ConvertAvroToJSON and ExecuteScript) prepare data to be inserted into the MongoDB collection, by the PutMongoRecord processor. Figure 13: Copy Recommendations to MongoDB End result in the Customer 360 dashboard (the data used here in this example is autogenerated): Benefits of Calleido's 360 customer database on MongoDB Atlas Once the data is available in a centralized operational data store like MongoDB, Calleido can be used to sync it with an analytics data store such as Google BigQuery. Thanks to the Customer 360 database, internal stakeholders can then use the data to: Improve customer satisfaction through segmentation and targeted marketing Accurately and easily access compliance audits Build demand planning forecasts and analyses of market trends Reward customer loyalty and reduce churn Ultimately, a single view of the customer enables organizations to deliver the right message to prospective buyers, funneling those at the brand awareness stage into the conversion stage and ensures retention and post sales mechanics are working effectively. Historically, a 360 view of the customer was a complex and fragmented process, but with Cogniflare’s Calleido and MongoDB Atlas, a Customer 360 database has become the most powerful and cost efficient data management stack that an organization can harness.
MongoDB Employees Share Their Coming Out Stories: (Inter)National Coming Out Day 2021
National Coming Out Day is celebrated annually on October 11 and is widely recognized in the United States. MongoDB proudly supports and embraces the LGBTQIA+ community across the globe, so we’ve reimagined this celebration as (Inter)National Coming Out Day. In our yearly tradition of honoring (Inter)National Coming Out Day, we asked employees who are members of the LGBTQIA+ community to share their coming out experiences. These are their stories. Jamie Ivanov , Escalation Manager For as long as I can remember, I always wanted to play with dolls and felt closer to my female cousins. This was rather difficult for someone who is a male at birth being brought up in a fairly conservative family. At a young age, I knew that I was different but lacked a way to describe it. I certainly didn't have the support I needed, so I was brought up as a male. My father went out of his way to “make a man out of me” and toughen me up in ways that weren't exactly the most productive. Going through school, I still knew that I was different because I kept feeling attracted to both genders, but I was too afraid to admit to it. I found a youth group for LGBT teenagers that gave me a safe place to be myself and admit to people who I really was. Outside of that group was still pretty scary; I knew that I had to be straight or I would risk being beaten up or harassed, so I tried to push my queerness aside. In my 30s, after going through the Army and having three children, I realized that I couldn't keep pretending anymore -- who I was wasn't the true me. I started telling people that I was bisexual and hoping that they wouldn't see me as less of a person. Most of the responses I received were "yeah, we kinda figured.” Having that weight off of my shoulders was immensely relieving but something still wasn't quite right; while admitting that helped explain who I was interested in, it still didn't explain who I was. Through a series of fortunate unfortunate events, a lot of the facade I had built up for so many years came down, and I realized that who I was didn't match the body that I was given. It was terrifying to talk to anyone about how I was feeling or who I was, but I finally told people that I am a transgender woman. It was one of the scariest things that I have ever done. Some people didn't understand, and I did lose some family over it, but most people accepted me for who I am with open arms! Since being true to myself, more weight has been lifted off of me, and my only regret is not having the resources and courage to admit who I really was years and years ago. Since I've come out as bi/pansexual and a transgender woman, I've built stronger relationships and felt much more comfortable with myself, even to the point of liking photos of myself (which is something I've always hated and realized it was because it wasn't the real me). When a MongoDB recruiter reached out to me, I asked him the same question I asked other recruiters: "How LGBT friendly is MongoDB (with an emphasis on the transgender part)?" The response I got back from my technical recruiter Bryan Spears was the best response I had received from ANY recruiter, or company, and was the deciding factor in why I chose to work at MongoDB. Here’s what he said: “MongoDB is a company that truly does its best to follow our values like embracing the power of differences; we have many employees who identify as LGBTQ+ or are allies of the LGBTQ+ community. We also have two ERGs, MongoDB Queeries and UGT (Underrepresented Genders in Tech), which both aim to create and maintain a safe environment for those identifying as LGBTQ+ or questioning. From a benefits standpoint, we have expanded the amount of WPATH Standards of Care services available for people who identify as Transgender, Gender Nonconforming, or Transsexual through Cigna. While I know none of the information I have shared tells you what life is like at MongoDB, I hope that it shows we are doing our best to make sure that everyone feels respected and welcome here.” I didn't always have the support I needed to be myself at some previous jobs but MongoDB has raised the bar to a level that is hard to compete with. I'm happy to finally find a place that truly accepts me for who I am. Ryan Francis , VP of Global Demand Generation & Field Marketing Growing up in the 90s in what I used to call “the buckle of the Bible Belt,” I did not believe coming out was in the cards. In fact, I would sit up at night to devise my grand escape to New York City after being disowned (how I planned on paying for said escape remains unknown). I was, however, out to my best friend, Maha. During the summer between my Sophomore and Junior years of high school, I spent time with her family in Egypt. On the return trip, I bought a copy of The Advocate to learn about the big gay life that awaited me after my great escape. Later that month, my mother stumbled upon that magazine when she was cleaning the house. She waited six months to bring it up, but one day in January sat me down in the living and asked, “Are you gay?” I paused for a moment and said… “yup.” She started crying and thanked me for being honest with her. A month later, she picked up a rainbow coffee mug at a yard sale and has been Mrs. PFLAG ever since, organizing pride rallies in our little Indiana hometown and sitting on the Episcopal church vestry this year in order to push through our parish’s blessing of same-sex marriage. Needless to say, I didn’t have to escape. My father was also unequivocally accepting. This is a good thing because my sister Lindsay is a Lesbian, so they sure would have had a tough time given 100% of their kids turned out gay. Lindsay is the real hero here who stayed in our homeland to raise her children with her wife, changing minds every day so that, hopefully, there will be fewer and fewer kids who actually have to make that great escape. Angie Byron , Principal Community Manager Growing up in the Midwest in the 80s and 90s, I was always a “tomboy;” as a young kid, I gravitated to toys like Transformers and He-Man and refused to wear pink or dresses. Since we tended to have a lot in common, most of my best friends growing up were boys; I tended to feel awkward and shy around girls and didn’t really understand why at the time. I was also raised both Catholic and Bahá’í, which led to a very interesting mix of perspectives. While both religions have vastly different belief and value systems, the one thing they could agree on was that homosexuality was wrong (“intrinsically immoral and contrary to the natural law” in the case of Catholicism, and “an affliction that should be overcome” in the case of Bahá’í). Additionally, being “out” as queer at that time in that part of the United States would generally get you made fun of, if not the everlasting crap kicked out of you, so finding other queer people felt nearly impossible. As a result, I was in strong denial about who I was for most of my childhood and gave several valiant but ultimately failed attempts at the whole “trying to date guys” thing as a teenager (I liked guys just fine as friends, but when it came to kissing and stuff it was just, er… no.). In the end, I came to the reluctant realization that I must be a lesbian. I knew no other queer people in my life, and so was grappling with this reality alone, feeling very isolated and depressed. So, I threw myself into music and started to find progressively more and more feminist/queer punk bands whose songs resonated with my experiences and what I was feeling: Bikini Kill, Team Dresch, The Need, Sleater-Kinney, and so on. I came out to my parents toward the end of junior high, quite by accident. Even though I had no concrete plan for doing so, I always figured Mom would be the more accepting one, given that she was Bahá’i (a religion whose basic premise is the unity of religions and equality of humanity), and I’d have to work on Dad for a bit, since he was raised Catholic and came from a family with more conservative values from an even smaller town in the midwest. Imagine my surprise when one day, Mom and I were watching Ricky Lake or Sally Jesse Raphael or one of those daytime talk shows. The topic was something like “HELP! I think my son might be gay!” My mom said something off-handed like “Wow, I don’t know what I would do if one of you came out to me as gay...” And, in true 15-year old angsty fashion, I said, “Oh YEAH? Well you better FIGURE IT OUT because I AM!” and ran into my room and slammed the door. I remember Mom being devastated, wondering what she did wrong as a parent, and so on. I told her, truly, nothing. My parents were both great parents; home was my sanctuary from bullying at school, and my siblings and I were otherwise accepted exactly as we were, tomboys or otherwise. After we’d finished talking, she told me that I had better go tell my father, so I begrudgingly went downstairs. “Dad… I’m gay.” Instead of a lecture or expressing disdain, he just said, “Oh really? I run a gay support group at your Junior High!” and I was totally mind blown. Bizarro world. He was the social worker at my school, so this makes sense, but it was the exact opposite reaction that I was expecting. An important life lesson in not prejudging people. When I moved onto high school, we got… drumroll ... the Internet. Here things take a much happier turn. Through my music, I was able to find a small community of fellow queers (known as Chainsaw), including a ton of us from various places in the Midwest. I was able to learn that I was NOT a freak, I was NOT alone, there were SO many other folks who felt the exact same way, and they were all super rad! We would have long talks into the night, support each other through hardships, and more than a few of us met each other in person and hung out in “real life.” Finding that community truly saved my life, and the lives of so many others. (Side-note: This is also how I got into tech because the chat room was essentially one gaping XSS vulnerability, and I taught myself HTML by typing various tags in and seeing how they rendered.) I never explicitly came out to anyone in my hometown. I was too scared to lose important relationships (it turns out I chose my friends well, and they were all completely fine with it, but the prospect of further isolating myself as a teenager was too terrifying at the time). Because of that, when I moved to a whole new country (Canada) and went to college, the very first thing I did on my first day was introduce myself as “Hi, I’m Angie. I’ve been building websites for fun for a couple of years. Also, I’m queer, so if you’re gonna have a problem with that, it’s probably best we get it out of the way now so we don’t waste each others’ time.” Flash forward to today, my Mom is my biggest supporter, has rainbow stickers all over her car, and has gone to dozens of Pride events. Hacking together HTML snippets in a chat room led to a full-blown career in tech. I gleaned a bit more specificity around my identity and now identify as a homoromantic asexual . Many of those folks I met online as a teenager have become life-long friends. And, I work for a company that embraces people for who they are and celebrates our differences. Life is good. Learn more about Diversity & Inclusion at MongoDB 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!