10 Exciting Things About MongoDB.local London
After nearly two years of the coronavirus pandemic preventing in-person events, MongoDB is very excited to once again see people face-to-face at MongoDB.local London! This event is designed to help developers grow and will be packed with educational content to teach you how to build data-driven applications without distraction. MongoDB.local London will be run as a hybrid event, featuring both in-person and virtual attendance options. For those unable to attend in-person, we will live stream most sessions for you to enjoy. All streamed content will be available on-demand for 30 days after the event. In-person attendance for the event is limited, so head over to our registration page and sign-up today! MongoDB.local London takes place on November 9, 2021. There will be something for everyone at .local London. Here are 10 exciting things about our upcoming event: Hear it Here First: The Keynote presentation will provide a recap of the products released in MongoDB 5.0 and highlight the new features in 5.1. Following the keynote, attendees can pose questions to MongoDB CTO, Mark Porter, CPO, Sahir Azam, and a larger panel of MongoDB experts. Customer Stories: During these sessions, attendees will hear from MongoDB customers and community members about how they are utilizing the MongoDB data platform to enhance the way they work with data. These sessions will include speakers from Boots, Vodafone, NatWest, and DWP Digital. “Ask Me Anything" Panels: Attendees can have their questions answered and problems solved live by a panel of MongoDB engineers and product experts. Panel topics include Performance & Security, the Aggregation Pipeline, and Schema Design. Technical Sessions: Over the course of the event, there will be 20+ educational technical sessions that will cover beginner, intermediate, and advanced level content. The information in these sessions has been selected specifically for this audience and will be delivered by the MongoDB experts who build the data platform. MongoDB Product and Feature Demos: The MongoDB product teams will be conducting dozens of demos on everything MongoDB, from Atlas to Ops Manager . This is the perfect opportunity to learn more about MongoDB and how it can work for you. Ask the Experts: Our MongoDB Experts will be offering free 1:1 technical consulting sessions where attendees can ask any technical questions that they have. Only available to in-person attendees. Deep-Dive Tutorials: Opportunity to learn by doing long-format, classroom style sessions on the latest data trends with MongoDB. You will receive 1:1 attention from MongoDB experts while you get hands-on with the data platform. Only available to in-person attendees. Community Café: Come to the Community Café stage where there will be an “up close and personal” with MongoDB CTO, Mark Porter, customer interviews, trivia, and so much more! Happy Hour: In-person attendees can grab some food and drinks at the event happy hour. Here’s your chance to engage and network with other attendees. Swag: Is it really a tech event if there isn’t some free swag? Stop by the event booths to get some swag from our MongoDB team members. Register today to save your spot for the event! Whether you attend in-person or virtually, we look forward to having you join us!
Safe Software Deployment: Z Deployments
If you’ve gotten this far in my Safe Software Deployment series, you know how scary deployment day can be. Sleepless nights. Knots in the stomach. Cold sweats. These are the symptoms of uncertainty. And three decades of experience have taught me that all the positive thinking in the world won’t ensure a bug-free deployment. That’s why I’ve developed a number of techniques that can consistently help teams minimize fear and achieve safe software deployment. In the last post, we discussed the 180 Rule . The purpose of this post is to explain how you can use “Z Deployments” to mitigate both fear and downtime. In future posts, we’ll look at both the Goldilocks Gauge and Through the Looking Glass. Z Deployments are more than a catchy name. This is all about failed rollbacks, which in my experience are the biggest source of downtime in any software deployment pipeline. Now, we all try our best to eliminate the need for rollbacks in the first place - but when they do happen, we want them to be successful. However, in most companies, rollbacks are only tested in Prod, not in the prior stages of the pipeline. Even if you use the 180 Rule, which encourages quick and automated rollbacks, you don’t have any more certainty that they will work. This is where Z Deployments come in. With a Z Deployment, the goal is to make rollbacks just as predictable and reliable as your normal “roll forward” software deployments. I call this technique a Z Deployment, because if you chart out the process, it looks like a Z. But you can also think of Z Deployments as akin to pressing “Command Z” on your keyboard: undo. Fast, simple, no drama. Here’s how it works. Roll your code forward from development into staging. In staging, do your canary testing. Then roll back into development. Do your canary testing again. If it doesn’t work, then you just proved that your rollback code was faulty in some way. Roll your code forward into staging again, and do your full testing. If it’s successful, roll your code forward into production. Of course, this only works if your staging environment is clean and your team trusts it. I’ll get into this more in a future post called “Through the Looking Glass.” But the bottom line is that developers need to know that things will work in production; including any needed rollbacks. And the only way to do that is to test rollbacks in staging. Your version of canary tests and full tests might be different - in a perfect world you’d run full tests three full times, but often build systems aren’t set up to do that quickly enough. Too often, staging is not clean. But generally, when developers deploy to staging, their added functionality tends to work. Everyone else is using staging, and their functionality is working, too. This is the “Happy Path” - where engineers test that their new thing works. That sounds great. But what else happens? Adjacent things get broken. Often when you roll back, you’re not necessarily returning to your system’s original state, either for your own software change or for the adjacent software components. Your rollback code has to undo all the state changes your deployment to staging (or prod) may have made. Otherwise, the staging environment becomes polluted, and the results in staging won’t match the results in production. Developers lose faith in staging, and deployment again becomes a terrifying ordeal. I used to work with someone who was absolutely obsessive about staging. He ran testing, and he refused to have a long-term staging environment. Instead, his team blew away staging every month and rebuilt it from scratch. Did I like this? Absolutely. Did it work? Yes. Developers trusted staging, which meant that deployments to prod were less scary. The next step of safe software deployment is to embrace the Goldilocks Gauge, which helps make deployments routine and even boring – in a good way. It also makes both the 180 Rule and Z Deployments easier to execute, and it’s a necessity for teams working toward continuous development. In the meantime, feel free to share your own techniques for safe deployments at @MarkLovesTech or in the comments below.
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 .