Control Your Colours in MongoDB Charts
Colours are integral to the story you want to convey with any sort of data visualisation. With the latest release of MongoDB Charts , we have added more control to how you can assign colours to your charts! Previously, colour assignment of a series were always based on the series order within that chart. However, we may instead want to colour the chart based on the series value. Some basic scenarios where these different strategies prove useful include: Colouring the top 3 series with the colours gold, silver and bronze. Colouring the series "Summer" and "Winter" with "Red" and "Blue" respectively, to symbolise the season. If the above examples did not give it away enough, we will create some beautiful charts using an Olympics dataset to fully understand the capabilities of the new features. Single-series charts We will start off with a basic single-series chart. These charts usually have a single field encoded to the x and y axes and will display a single colour for the chart. In these charts, we now show a single colour swatch for you to edit. Simple, right? Multi-series charts For more complicated charts with multiple series, we may want to colour the series based on the encoded field itself. These charts are created when multiple fields are encoded to an aggregation channel where the field key is used to build the multi-series chart. In the above chart, I have a medal tally of the top 10 countries based on medal count. The chart itself is fine, but we could improve this chart with some useful colouring! A notable colour scheme we could apply to this chart is assigning each series to the colour of the medal. Inside the Color Palette customisation option, you will see that each encoded field is now listed based on the order that they were encoded in. With the colour scheme set to the medal colour, the chart will be a lot easier to convey the original information. Colours assigned to these channels will always have the same colour assigned and will ignore the ordering of these fields. Assigning chart colours to string data The final chart that we want to create, involves a chart where the data itself is a String type. With these chart types, the Color Palette will provide options to toggle between the two different colour assignment strategies where: 'By Order' will allow you to assign colours by the ordering of the series 'By Series' lets you customise the colour for a specific series value To help streamline the process of assigning colours in the above chart, in the ‘By Order’ menu, I can choose to assign colours based on the value order of the Discipline that appears in the chart. This may be useful if we don't care what the colours are that represent each Discipline. Alternatively, we could assign colours using 'By Series' so that we can be assured that I can represent the Disciplines with an associated colour. Now that we have created all of our charts using the different ways we can assign colours, we can be confident that the colours in our data visualisations are consistent throughout our dashboard. Want to start colouring your charts today? You can start now for free by signing up for MongoDB Atlas , deploying a free tier cluster and activating Charts. Have an idea on how we can make MongoDB Charts better? Feel free to leave an idea at the MongoDB Feedback Engine .
Digital Transformation with MongoDB Atlas and Accenture Cloud First: Three Use Cases for Cloud Modernization
Choosing which providers to partner with when moving to the cloud is a critical first step in pivoting to meet this new field of opportunity. Together, MongoDB and Accenture deliver deep expertise, proven success, and the right balance of experience across industries. Here’s how—and where—we can help. Journey to the cloud: Three value-unlocking use cases typically prioritized by CIOs and CTOs Accenture and MongoDB have identified three common use case patterns across industries, each worth examining further: Building out APIs for modern application development Moving from monolith to microservice for modernization Offloading from legacy or mainframe systems These scenarios typically come to the forefront of the CIO/CTO agenda as they aim to accelerate their journey to the cloud and to release gridlock from old but valuable business applications. A common mistake is believing that the business case for this migration is entirely IT-driven. The true motivation must come from understanding that the legacy technology is stunting the ability for applications to keep up with the increasing pace of change in the business. Additionally, and especially for mainframe applications, the labor force segment that knows these business critical applications is rapidly approaching retirement, leaving a critical knowledge gap in supporting and extending these applications. Let’s take a deeper look. 1. Building out APIs for modern application development Innovative applications require businesses to react and adapt quickly. Development needs to be quick, the architecture must be loosely coupled, and the deployment model must have scalability built into its core. Technical challenges facing today’s applications include: Incoming digital requests can vary and follow trends, in an often quick-bursting and even disruptive manner Businesses need to be able to adapt on the fly – and, therefore, so does the data structure Innovation today requires data models that can be extended to meet future demands The weight of these requirements has been exacerbated as businesses become more and more structured for our on-demand world. Mobile applications at a bank, for example, need to be able to service customers in real-time and 24/7. And it’s not just banks—demand volatility is on the rise across industries and customer expectations continue to evolve. The secret sauce in these new applications is to build the data to fit the application – rather than dealing with the constraints of the relational data models of the previous generation applications. With the flexible data structures and ease-of-change with MongoDB, developers can build and adjust the data structures to meet the rapidly evolving needs of new applications, delivering the speed and agility needed to create disruptive change. Furthermore, you can scale out quickly with the horizontal scaling capabilities of the leading NoSQL database, while uniquely still having access to ACID database properties where needed. Finally, with MongoDB Atlas , the fully managed MongoDB solution, the needs for scale-on-demand and ready-to-use secure production infrastructure in Azure, AWS, and Google Cloud, peace of mind has never come easier when preparing for an industry-changing innovation. 2. Moving from monolith to microservice for modernization Not all innovation comes in a brand-new application. In order to innovate with old applications, sometimes they need to be extended in ways that were not contemplated when leading architectures centered around monolithic application configurations and deployments. Many of our clients experience challenges with their application portfolios because they have not kept pace with the rapid evolution of technology, driving one critical business problem: the inability to scale at pace. Digital Decoupling is an Accenture solution designed to extend the life of critical business applications while augmenting them with new functionality – often through the modern development techniques and architecture as described in section 1. Initially, this will mean that there is yet another technology pattern included in the footprint of the business application. However, the difference here is that the transformation from “legacy java” to modern architectures can be accelerated. Once you have experienced the simplicity of data that matches exactly what your application needs, it will be difficult to stop! Diagram A: Monolith to microservices transformation The diagram above (reference Diagram A ) illustrates the historical move to a more ideal data architecture from monolith to microservices. However, in the real world, companies often find completely moving over to a microservice layer to be too expensive or too much effort. That is why over the last 5 years, Accenture has developed its Digital Decoupling approach to solving this problem. More details can be found here . With Accenture’s Smart Data Mover data can be moved from the relational database into MongoDB and code can be substantially ported as-is while simplifying the data access layer, accelerating organizations in their onramp to rapid change and innovation. The size and shape of the new services can adjust from microservices for rapidly evolving functions to coarse-grained services that don’t have much change and don’t warrant further investment. MongoDB is designed to work well as the storage layer of a microservice or API architecture and can mitigate risk during the refactoring phase, so that businesses can meet demands that ebb, flow and ideally grow in traffic. 3. Offloading from legacy or mainframe systems As more and more companies migrate to the cloud, a common (and often painful) use case is the requirement to offload applications from mainframes and other legacy data stores. It is painful for many reasons, most predominantly because no one within the organization has the institutional knowledge required to maintain and operate the legacy application, and because many times the movement of the data from the system involves several complex technical hurdles to implementation. To solve this, Accenture’s Digital Decoupling approach extends to the mainframe as well. This approach within the mainframe offload scenario is located below (reference Diagram B ). Diagram B: Mainframe offload reference architecture with MongoDB Atlas: When transitioning from a legacy or mainframe system, there are several aspects to consider: How will the data and code be migrated? If moving to a more scalable data solution, how will code in triggers and procedures get ported? How will the new data platform solution deliver on required flexibility, scale (and not just for read-only copies of the data) in addition to resilience non-functional requirements? The last point is the pivot of our conversation. To gain a true advantage, most organizations will need to preserve traditional enterprise capabilities, but also meet the needs of a modern day and age where storage is no longer a concern. To help move the data over, Accenture Smart Data Mover can get the job done seamlessly. CDC tools and/or Kafka can also be leveraged for continuous update, if the preferred source of truth for some applications still needs to be the mainframe. Please check out this solutions guide for more information about best practices on offloading from the mainframe with MongoDB. Why MongoDB? MongoDB’s document-based, distributed database provides users with the versatility to build sophisticated applications that can respond and adapt to changing customer demands and market trends. As the leading choice for general-purpose databases, MongoDB reduces time spent on development cycles and empowers developers with flexible schema and the tools they need to innovate. Furthermore, MongoDB’s fully managed database-as-a-service option, MongoDB Atlas , is the only multi-cloud document database available in the market, and delivers the most advanced security and data distribution capabilities of any fully-managed service. MongoDB has also spent years building out a full modernization program to help customers and their architects with their journey to the cloud. This program includes training, tools, and best practices that have been co-developed with System Integrators, especially Accenture. This is why MongoDB is partnering heavily with Accenture in helping customers move to the cloud. Why Accenture Cloud First? Accenture Cloud First is a multi-service group of 70,000 cloud professionals across the globe that brings together the full power and breadth of Accenture’s industry and technology capabilities to help move organizations to the cloud with greater speed and achieve greater value, faster. The Cloud First team combines world-class cloud and cloud native engineering, learning and talent development expertise, deep experience in cloud change management, and cloud-ready operating models with a commitment to responsible business by design. Security, data privacy, responsible use of artificial intelligence, sustainability, and ethics and compliance are built into the fundamental changes Accenture helps companies achieve. How MongoDB and Accenture can help Our clients have taken a deep, insightful look at their application portfolios and uniformly decided that they need to accelerate their migrations to the cloud under the realization that their data center isn’t where they want their employees, i.e. their most precious resource, to spend most of their time. This realization has pushed Cloud Migration and Modernization efforts front and center for the C-Suite. Accenture has developed an end-to-end Value-Led Modernization methodology that analyzes each business case to deliver the most value possible for our clients. We built this methodology in order to be laser-focused on delivering the right outcome: increased value to the organization vs. just doing modernization for modernization’s sake. Core to our methodology is the belief that modernization initiatives should take a lean engineering approach to the work itself while simultaneously enabling new value streams for the business. To enable this dual reality that CIOs and CTOs find themselves in today, we architecturally focus on three tenants: Minimal invasive modernization efforts using our digital decoupling techniques Establishment of an enterprise, event-driven architecture as the core of communication Establishment of a modern data architecture to underpin our new value propositions while simultaneously supporting existing value cases. To remain competitive in today’s ever-changing marketplace, you need to be able to scale quickly and securely while enabling access to one of the business’ most important assets: its data. Together, Accenture and MongoDB have made several investments to date and continue to partner to bring the best to our clients. Accenture and MongoDB have launched another joint solution, our “Modernizer Tool,” to help customers modernize as they migrate to the cloud. The Modernizer tool is an asset that identifies relevant information and speeds up feeding and integration and migration process definition by standard techniques. The tool aims to mitigate data modeling and integration challenges by applying a metadata-driven approach which anticipates key risks. Looking Forward Bottom line? Your organization needs a modern database—one that can allow it the speed and agility to keep up with ever changing business needs. Further investment in modernization today isn’t an option, it’s a necessity to remain competitive, to realize your digital transformation goals and to provide your organization with the foundation necessary to innovate. Accenture and MongoDB will continue to partner in making investments in Cloud Enablement, Cloud Migration and Modernization that will enable you to realize your goals. We look forward to working with our customers on cloud modernization projects in the field. Find out more about the MongoDB & Accenture partnership here .
Considering NoSQL? Let's Break Down Your Options
Non-relational alternatives to relational databases — usually referred to as NoSQL databases — have been rapidly gaining popularity over the past decade. In 2013, MongoDB published one of our most popular white papers, “Top 5 Considerations When Evaluating NoSQL Databases.” We have since updated that paper as the technology has evolved. MongoDB is now offering a major update, which adds two new issues organizations should include in their thinking: how a database handles data generated at the edge by mobile devices and how a database fits into a broader data platform that includes search and analytics. If you’re testing the waters of NoSQL databases, then you’re probably familiar with how they’re different from traditional relational databases. The list of things you already know about NoSQL probably looks something like this: They use a different data model and query language. They have dynamic schemas. They scale horizontally. Beyond those common features, there are significant differences among NoSQL databases. The seven areas of significant differences among your options are: Data model (document, graph, key-value, etc.) Query model Consistency and transactional model APIs Mobile data Data platform Commercial support, community strength, and lock-in From MongoDB’s point of view, the most important consideration is the data model. We popularized the document model , which supports a superset of all data models, making it useful for a wide variety of applications. Key features include the ability to index and query in any field, and the natural mapping of document data structures to objects in modern programming languages. Recent shifts in how modern applications are developed and deployed — and in the experiences they offer customers — highlight the two new considerations. Mobile use cases: Mobile applications introduce the added challenge of not always being connected to the network. Developers need a solution for keeping all their customers’ apps in sync with the back-end database, no matter where they are in the world and what kind of network connection they have. The solution also needs to scale easily and quickly as more users download an app, and support the cutting edge of mobile development technologies as they evolve. Data platform: MongoDB’s application data platform provides developers a unified interface to serve transactional and operational applications alongside search, real-time, and data lake application needs. It eliminates the overhead and friction of developers having to stitch together multiple discrete technologies into a complex architecture, each creating its own duplicated data silo — connected by fragile ETL pipelines — and accessed, secured, governed, and operationalized by different APIs and tools. For a deep dive into all the differences among NoSQL databases, download our white paper, “ Top 7 Considerations When Evaluating NoSQL Databases .”
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .
解決失業問題：DWP Digital 和 MongoDB 如何攜手合作，以增強開發人員的能力，並應付英國面臨的一些巨大挑戰
技術和企業是為了維持社會正向發展而存在。我們都有帳單要付，家庭要養，但除此之外，它遠比企業盈利更加重要。我也相信，開發人員尤其對一個組織所能取得的成績，包括社會影響和盈利水準，有著巨大的影響。英國就業與養老金部門的數位團隊 (DWP Digital) 是完美典範的團隊，該團隊理解並接受開發者人員在解決重大問題上可以發揮的重要作用。今年，我們有幸與 DWP Digital 及其開發人員合作，最終希望能夠應付英國面臨的一些巨大挑戰。 就業與養老金部門 (DWP) 是英國最大的公共服務部門。該部門負責向有需要的人提供政府援助，其中包括一系列福利，例如國家養老金、殘疾津貼等。超過 2200 萬位公民依靠 DWP 每年發放的 1680 億英鎊維持生計。 DWP Digital 團隊負責建置並支援使這一切成為可能的各種應用程式。他們運作 1,000 多個應用程式，並且據估計，他們已經為這些應用程式撰寫了超過 5,000 萬行程式碼。目前，DWP Digital 正在發生重大轉變，因為大部分最重要的工作已逐漸轉回到內部運作，而開發人員正在採用更敏捷的交付方法。其目標是提供更優質、更高效且更以客為尊的服務；如果沒有一支敬業、熟練和富有創造力的開發人員團隊，他們就無法做到這一點。 Hack the North:Hack the North：MongoDB 贊助 DWP Digital 的曼徹斯特基地黑客松 (Hackathon) Hack the North 對於那些不明就理的人來說，黑客松(Hackathon)是一項讓開發人員有機會嘗試新技術、解決新問題和試驗新方法的活動。基本上，您會想從黑客松(Hackathon)中獲得三樣東西：學習新知、玩得開心，以及努力回饋社會。然而，在我們進入黑客松(Hackathon)之前，有些統計資料表示：曼徹斯特城及其周邊地區有超過 75,000 名失業者在此生活 (資料來源：DWP 的丘吉爾申請，2017 年 6 月)，整體失業率高於全國平均水準，居民失業率為 5.5% (資料來源： Nomis，官方勞動力市場統計資料 )。科學、研究、工程和技術專業等領域的工作，僅佔曼徹斯特總勞動力的 4.69%。然而，該類別的職位空缺占公布的職位空缺總數的 18% (資料來源： 2016/2017 年第一季度市議會經濟儀表板 )。 因此，當 DWP Digital 決定在 2018 年初曼徹斯特數位中心開業之前舉辦一場黑客松(Hackathon)時，他們想要解決的重大挑戰是顯而易見的。Hack the North 是一場為期兩天的公共黑客松(Hackathon)，專注於尋找解決方案，以協助解決該市的失業問題。它通常在場外進行，以便讓使參與者脫離日常活動的思維空間。那裡通常有很多食物 (披薩)、飲料和競爭性的玩笑。 The project board at Hack the North Hack the North 的計畫委員會 由於 DWP Digital 是 MongoDB 在歐洲最重要的使用者之一，而且我們的開發人員宣傳團隊擁有舉辦黑客松(Hackathon)的經驗，因此我們的一些團隊與其他贊助商 ThoughtWorks 及 TechHub Manchester 一起支援這項活動。過去這幾年以來，我參加過好幾次黑客松(Hackathon)，老實說，這是我參加過最精彩的一次。所有參與者的想法、執行力和熱情，都非常的蓬勃煥發。 我們在現場有 70 多人，分為 10 個不同的團隊，每個團隊的任務就是在短短兩天內利用 Churchill (DWP 的公共資料儲存庫 – 也是建立在 MongoDB 上) 等公共來源的可用資料，開發出一個全新的就業解決方案。 "I’d expected DWP to be quite corporate, but the people I’ve met here really want to make a difference to the world.” Our @dtanham on the innovation & creativity on display at our #HackTheNorth #hackathon in #Manchester 🐝 👉🏽 https://t.co/NPbqhiSy6H pic.twitter.com/t2kmurOa5O — DWP Digital (@DWPDigital) December 11, 2017 最終的解決方案面面俱到、富有創意，並且令人印象深刻。我們擁有一切，從協助新失業者入職過程的引擎，到將簡歷和能力測試遊戲化的平台。然而，最終獲勝者是一支名為 UpSkill 的團隊。UpSkill 採用 MongoDB Atlas 建置了一個應用程式，可以將求職者的技能與雇主的要求配對，還有一個 API 允許求職者存取各種資源來提高他們的技能。這是一個非常靈巧、執行順暢的最終產品，在眾多創意中獨樹一幟。 誠然，我們還沒有完全解決曼徹斯特的失業問題，但在我看來，為期兩天的活動取得了巨大的成功，開發人員學到了很多東西，並建立了一些強而有力的概念驗證。如果想要瞭解更多資訊，請查看 #HackTheNorth Twitter 新聞 ，或我的評委同事 Dan Tanham (DWP Digital 的副主任) 撰寫的這篇優秀 部落格貼文 。 教學相長 直到您可以把所學傳授給別人，才是真正學會了這一課。除了黑客松(Hackathon)之外，DWP Digital 使其團隊保持在開發最佳作法前沿的另一種方式，就是讓他們在開發人員大會上進行演講。我們很高興有數十個 DWP Digital 團隊參加了去年 11 月在倫敦舉行的 MongoDB Europe 2017 ，但真正特別的是 DWP Digital 的首席技術官 Rob Thompson 發表了一整個上午的主題演講。 您可以在下面看到他演講的完整影片，您不會被他的論點所震驚。在概述了 DWP Digital 之後，Rob 談到了 MongoDB 和敏捷開發如何成為協助英國最大的公共服務部門轉變其資料基礎架構，並在養老金、健康、福利和分析方面建置許多旗艦級數位服務的關鍵工具。Rob 堅信，在大多數計畫中，開發人員是決定成敗的關鍵。 在分組討論中，Rob 的同事 David Parry 更詳細介紹了 DWP Digital 如何在雲端中使用敏捷開發、Java 和 MongoDB 來建立微服務架構。這種架構使得從概念驗證快速重複到數百個服務成為可能，因為它們在全國範圍內推出。遺憾的是，我們無法拍攝每場會議，因此如果您想觀看這種類型的演示，您只能親自參加今年稍晚舉辦的 MongoDB Europe。 與 DWP 數位團隊如此緊密合作的幾個月，是一段十分愉快的時光。他們不僅以令人難以置信的強大方式使用 MongoDB，而且更重要的是，我親眼見證了該組織是如何以開發人員為中心的。您可能很難相信大型政府部門會成為開發人員創新的孵化器，但值得慶幸的是，他們確實可以。事實證明，DWP Digital 與矽谷的精英一樣具有前瞻性、敏捷性和以一般使用者為中心的理念，而社會也因此變得更加美好。 在 DWP Digital Jobs Twitter 帳戶 上瞭解有關 DWP Digital 職位空缺的更多資訊，或瀏覽 careers.dwp.gov.uk 。如果您想更深入瞭解 MongoDB 的開發人員重點和我們舉辦的活動，請跟隨我的帳號 @jdrumgoole 。
Intern Series: From MongoDB User to Return Intern - Meet Andy Mina
Insight into the World of a Top-Level Executive
The MDBWomen’s Group recently hosted a company-wide event with guest speaker, Maya Leibman , Executive Vice President and CIO of American Airlines . Maya covered a wide-range of topics, including her 27-year career at American Airlines, her successes and learnings along the way, and what it means to be the “air traffic controller” of American Airlines’ technological transformation. Maya Leibman, Executive Vice President and CIO of American Airlines Here are just a few of the highlights from the insightful event with Maya: Question: Being at the technology helm of the world’s largest airline is quite an awe inspiring position. What does your role entail? Answer: I have been with American Airlines for 27 years and have done a lot of different roles both inside and outside technology. I have done this job for the last eight or nine years and I have responsibility for all things technology. Everything from development to infrastructure, cyber, data and next generation tools and practices. Q: You have been described as the air traffic controller of American’s technological transformation. What do you think they meant? A: An air traffic controller is responsible for ensuring that everything goes smoothly at the airport which is a really complex place. My team and I have responsibility for ensuring that as we modernize the way we deliver technology that we do it in a safe and secure way and a way that recognizes the risks and seeks to minimize them. We are taking something really complex and making it as smooth as possible. Q: How has COVID impacted your approach to technology innovation? A: It has been impactful in so many different ways. The biggest is in the ways that we are working. Who knew that in the space of a couple of days we would all have to go home and find ways to connect, work and be productive? We would never have thought that it would be as easily done as it was. At American, we say that everyone has a responsibility for innovation. Q: How do you empower different teams and measure how innovative they are? A: What is hard with a big company is that people like consistency, standards, and predictability so processes get built around things and it’s like a fence that prevents innovation. We can’t hire people and put them in a tiny pen because they’ll never achieve what we hired them for. As leaders, we need to have the judgement to understand that while we need standards and consistency, we can’t have it at the expense of people thinking their best thoughts, spreading their wings, and producing new, innovative approaches not just to what we are doing but how we are doing it. (Top left to bottom right: Alexandra Hills , Lacy Ceder , Stephanie Samuels , Maya Leibman ) Q: How has your leadership style evolved over time? A: Every positive attribute you can think of can be used to describe leadership. Personally, for me, it plays on both what your strengths and weaknesses are. One of my strengths is communication. I believe that part of my success as a leader has been the ability to communicate, stand up in front of a group, make compelling arguments and be somebody who can speak confidently with authority and knowledge. One of my weaknesses is listening. I’m not good at it; I interrupt people and am impatient. Honing my leadership skills means trying to get better at the things I’m not good at. Q: You have talked about the JetStream Program quite openly. Why is that and what did you learn from it? A: Jetstream was a disaster. It was a project that my group worked on for two years to develop this system that would re-write our reservation system. During that time, not one line of code was written and that’s how bad it was. We’ve all had experiences in our careers that we are not proud of and I think we should be open about them because it makes us more real and relatable. That’s life. Q: How do you lead your team through those moments of disaster? A: A lot of that has to do with developing an experimental mindset. Technology transformation is all about being willing to experiment and to learn and if it doesn't work, to pivot and do something different. That’s what Agile delivery transformation is all about. When you’re building technology you are doing something that nobody has ever done before so why do you think you are going to get it perfect the first time? Q: You didn’t start at CIO. How did your other roles at American shape you? A: I had ten or 15 jobs in the 27 years and each one has taught me different things. You just extract whatever you can from whatever role you are doing. The one thing I learned is that nothing is linear. We all got to where we are through twists and turns so you have to take your hands off the wheel a little bit and recognize that things are going to come along that you might not have expected. Don’t get too stressed about how your career is going. Everything really works out in the end. Q: Do you have any advice on how women can overcome difficult conversations and negotiations on things like salaries? A: Certain things are endemic to gender and I think it’s important to remember that the men you work with are not hesitating to go to their boss and say they want a review or more money. A lot of women think their work will speak for itself and that they don’t have to put themselves out there but you do have to have those difficult conversations and you do have to get comfortable with being uncomfortable about them. Find a friend and rehearse them before time or have somebody role play with you. We, as women, need to get to a place where we feel confident having those discussions. Q: What has been the biggest challenge in your career and how did you overcome it? A: The merger between American and US Airways was really hard. Hard from a work perspective and also from a people perspective. We were trying to bring two cultures together and two different philosophies around technology. It was a difficult time in a lot of ways. One of the things I insisted on was that we assume positive intention. You have to go into this assuming that everyone is doing the best possible thing. It’s so easy to vilify other people. Q: How do you envision the transition back after COVID? A: People are diametrically opposed on how they think about risk. It’s important when we return to the office to be empathetic with everyone’s re-entry into this process. For me, it’s not about whether we’re going to work from home, it’s about when we are going to work from home. Thank you, Maya for a phenomenal event and for sharing your expertise with the MongoDB community. You are an amazing role model in technology and we appreciate you sharing your insights with us!
Meet MongoDB's Global Talent Sourcing Team
As MongoDB’s India-based team grows, we’re looking to add new members to our Global Sourcing team in the Gurugram office. Hear from Gagan Singh , Senior Manager of Talent Sourcing, along with some Sourcing team members to learn more about the day-to-day of a Talent Sourcer and how MongoDB provides access to leadership, fosters inclusion, and enables career growth. About the Sourcing Team Our team of Global Talent Sourcers partner with our recruiters to identify and hire top talent for MongoDB. We are divided into specialized sourcing teams by business units (Sales, Engineering, Customer Engineering, Corporate, and Marketing), and our team works to support the hiring needs in Australia/New Zealand, Asia Pacific, Europe, and North America. The Recruiting team partners with the Sourcing team to pipeline for open positions, as well as organizing ad hoc projects such as talent pool insights to understand availability of talent, location analysis to understand favourable locations to hire, and org chart creation of target companies for our open positions. As Talent Sourcers, our job is to help find the best talent within a competitive market. Our day begins with doing extensive secondary research for talent on sites like Linkedin, Google, Github, Seekout, and in our internal database. We then identify which candidates qualify for a role based on the skills required for the open position. Quality candidate profiles are uploaded to our CRM (candidate relationship management tool) and ATS (applicant tracking system) for further review and outreach. Along with sourcing talent, our group of Talent Sourcers who support open positions in APAC engage with candidates over the phone, email, and InMail to prequalify them for recruiters. The team also contributes by examining the market and target company trends and developing useful insights based on their research for different locations. This helps us be strategic talent advisors to our recruiters and hiring managers. The success measures for a Talent Sourcer are divided into leading and lagging indicators. Number of prospects, candidates sourced, and candidate quality are the leading indicators. Number of candidates sourced by the Talent Sourcer who received an offer or were hired is a lagging indicator. Hear from some of our team members Ruchi Puri, Global Corporate & Marketing Sourcer “Being a global Sourcer is pretty exciting. Although we each support our given business unit and region, we still get to work and strategize with other recruiters and sourcers. There is an open culture which allows us to reach out to our stakeholders and leaders for absolutely anything. Being part of the Global Corporate & Marketing Sourcing team gives me the ability to work with recruiters from various countries and cultures. The best thing is that our recruiters and leaders have trust and confidence in us and are always available to provide any kind of support we need." Vivek Negi, Global Customer Engineering Sourcer “Working at MongoDB has been a joy so far, and I have gained tremendous knowledge about the database market and software industry. I also had the opportunity to visit our New York City headquarters for a People Team offsite, and it gave me the opportunity to meet our senior leadership team and have one-on-one conversations with my stakeholders. I am privileged to work with really smart people.” Tanu Saxena, Tech Sourcer - NA “I’ve been working at MongoDB for three years, and what a journey it has been. I can’t be more thankful to work with such a talented and amazing bunch of people willing to help each other do great work with a positive mindset. I have worked in a similar structure at my previous companies but the people here at MongoDB are truly amazing. I have never felt like one team with global stakeholders in my previous jobs but here it is an entirely different level with amazing partnership.” Kuldeep Pandey, Sourcer- APAC “I joined MongoDB in August 2018 from an agency background where I was responsible for managing a team. Being a part of MongoDB has been a great journey. I have worked under different lines of business including North America Sales, Global Customer Engineering, and now India/APAC Sourcing. I was promoted in August 2020 from Talent Sourcer to Senior Talent Sourcer and can certainly see a clear path of growth and learning for myself in the coming years.” Yumna Alvi, Sr. Sales Sourcer- EMEA “I am very proud to work at a company that embraces diversity and accepts people from all cultures. I remember when I started wearing my headscarf (hijab), a lot of my friends and relatives warned me that it could affect my long-term career goals. After receiving my MBA, I began interviewing to start my career, and many companies questioned me about my attire. These questions were very demotivating and my response was always, ‘I cover my head, not my brain.’ MongoDB never questioned me about anything. Instead, they always supported and appreciated me by simply letting me be myself. In the last two years, MongoDB has provided me with the best opportunities of my life: international exposure, managing stakeholders, mentoring new hires, and interviewing candidates. MongoDB practices its core values every day, especially Embrace the Power of Differences.” Tanya Agarwal, Sr. Sales Sourcer- NA “MongoDB has been a life-changing journey for me. I received two promotions within two years of me joining the company and each level has helped me build on my knowledge. I feel special when I get to know how I am contributing to the growth of MongoDB. Over the past couple of years, I have benefited from the international exposure I have had while partnering with my recruiting counterparts in North America. I have the liberty to make mistakes and I always have the support of my leaders to focus on improvements.” How to succeed on the team We look for individuals with strong research skills, knowledge of LinkedIn Recruiter, and a drive to go above and beyond to find great candidates, especially for niche roles and geographies. If you are applying to be a tech sourcer, you need strong conceptual technical knowledge of topics such as MongoDB fundamentals, products, and competitors; databases; software development lifecycle (SDLC); web services and microservices; DevOps, DataOps, and TechOps; and distributed systems. Experience in sourcing from unconventional tools such as Github is highly desirable. Our interview process involves a live sourcing test followed by interviews with the hiring manager, department head, and stakeholders. For sourcing tests, we ask candidates to read a job description, prepare a boolean based on their understanding of the job requirements, and then run a search. Candidates are assessed on their approach and engagement with the interviewer throughout the conversation, more than the number and quality of search results. The rest of the interview rounds focus on culture fit, relationship building skills, communication, and articulation. Overall, if you have attention to detail, great communication skills (sharing your observations and asking right questions), are research-oriented, and can be creative with boolean strings, we would love to network with you. Interested in pursuing a career on the Talent Sourcing team at MongoDB? We have several open roles and would love for you to transform your career with us!
4 Common Misperceptions about MongoDB
One year ago, in the middle of the pandemic, Dev Ittycheria, the CEO of MongoDB, brought me on as Chief Technology Officer. Frankly, I thought I knew everything about databases and MongoDB. After all, I’d been in the database business for 32 years already. I’d been on MongoDB’s Board of Directors and used the products extensively. And of course I’d done my due diligence, met the leadership team, and analyzed earnings reports and product roadmaps. Even with all that knowledge, this past year as MongoDB’s CTO has taught me that many of my preconceived notions were just plain wrong. This made me wonder how many other people might also have the wrong impression about this company. And this blog is my attempt to set those perceptions straight by sharing my four major revelations of the last year. My first revelation is that MongoDB is not trying to become this generation’s relational database. For years I assumed that MongoDB basically wanted to be a better, more modern version of Oracle when it grew up. In other words, compete with the huge footprint of Oracle and other commercial RDBMSs that have been the industry archetype for so long. I was way off. The whole point of MongoDB is to leave all those forms of archaic, legacy database technology in the historical dust. This was never supposed to be an evolution, but instead a revolution. Our founders not only envisioned the world's fastest and most scalable persistent store, but also one that would be programmed and operated differently. The combination of embedded documents and structures combined with automatic high availability and almost-infinite distribution capability all add up to a fundamentally different way of working with data, building applications, and running those applications in production. Oracle and (SQL*Server, etc) still hang their hats on E.F. Codd’s 51-year old vision of rows and columns. To obtain high availability and distribution of data, you need add ons, options packages, bailing wire and duct tape. And you need a lot of database administrators. Not cheap. Even after all that, you’re still trailing the technological edge. This is how wrong I was. Our durable competitive advantages over these legacy data stores make competing with those products almost irrelevant. We instead focus on the modern needs of modern developers building modern applications. These developers need to create their own competitive advantage through language-native development, reliable deployments to production, and lightning fast iteration. And the world is noticing; just check out the falling slope of Oracle and SQL*Server and the rising slope of MongoDB on the db-engines website. Which brings me to my second revelation: MongoDB was built for developers, by developers. I always knew that MongoDB was exceedingly fast and easy to program against. One time while I was bored in a meeting (yes, it happens here as well!), I built an Atlas database, loaded it with 350MB of data, downloaded and learned our Compass data discovery tool, built-in analytics aggregation pipelines, and our Charts package, and embedded live charts in a web page. This took me all of 19 minutes, end to end. To build something like that for engineers , it just has to be built by engineers , ones that are free to focus on all the rough edges that creep into products as features are added. I was first exposed to software planning and management over 40 years ago, and my LinkedIn profile shows a pretty diverse tour around the industry. Now, one year in, I can emphatically state that engineering and product at MongoDB are both different and better than any company I’ve ever had the privilege to work at. Our executive leadership gives engineering and product broad brushstokes of goals and desired outcomes, and then we work together to come up with detailed roadmaps, updated quarterly, that meet those goals in the way we think best, with no micromanagement. And we’re not afraid of 3-5 year projects, either. For example, multi-cloud was more than three years in the making. Also unlike any other company I’ve been at, we embrace the creation and re-payment of tech debt, rather than sweeping it under the rug. We do this through giving our product and engineering teams huge amounts of context, delivered with candor and openness. And one more essential thing; we have an empowered program management team that improves processes (including killing them) as fast as we create them. In short, we paint the targets for our teams and let them decide how and when to shoot. They even design the arrows and bows. It’s true bottoms-up engineering. Our engineers feel valued and understood. And that, in turn, empowers them to develop features that make our customers feel valued and understood, like a unified query language, or real-time analytics and charting directly in the console, or multi-region/multi-cloud clusters where all the networking cruft is taken care of for you. And this brings me to my third revelation: MongoDB is built for even the most demanding mission critical applications. Fast? Yes. Easy? Of course. But mission-critical? That’s not how I saw MongoDB when I used Version 2 for a massive student data project 10 years ago. While it was the only possible datastore we could have chosen for the amount of data and the speed of ingestion and processing needed, it was pretty hard to set up and use in a 24 x 365 environment. MongoDB had gotten ahead of itself in the early 2010’s. There was a gap between our capabilities and the expectations of the market. And it was painful. Other databases had had more than 30 years to solidify their systems and operations. We’d had five. But with Version 3 we added a new storage engine, full ACID transactions, and search. We built on it with Version 4. And then again with Version 5, released this week at our .Live conference. I knew about all this progress intellectually of course when I joined, but not viscerally. I came to realize that the security, durability, availability, scalability, and operability our platform offers (of course in addition to all the features that developers love too) was ideal for architecting fast-moving enterprise applications. And I found the proof in our customer list. It reads like a Who’s Who of major global banks, retailers, and telecommunications companies, running core systems like payments, IoT applications, content management, and real-time analytics. They use our database, data lake, analytics, search, and mobile products across their entire businesses, in every major cloud, on-premises, and on their laptops. And that leads me to my fourth and final revelation. MongoDB is no longer just a database. Of course, the database is still the core. But MongoDB now provides an enterprise-class, mission-critical application data platform. A cohesive, integrated suite of offerings capable of managing modern data requirements across even the most sprawling digital estates, and scaling to meet the level of any company’s ambition, without sacrificing speed or security. Since the day I was first introduced to MongoDB’s products, I’ve had tremendous respect and admiration for the teams and their work. After all, I’m a developer, first and foremost. And it always felt like they “got” me. But had I known then what I know now, I would have jumped on this train a long time ago. In fact, I might have camped out on their doorstep with my resume in hand. And who knows? Maybe a bunch of people reading this will do just that, and have their own revelations about how fulfilling and exciting it can be to be at a great company, with a great culture, producing great products. I’ll write another letter a year from now, and let you know how it’s going then. In the meantime, please reach out to me here, or at @MarkLovesTech .