Mark Porter is CTO at MongoDB, and a technologist with broad interests and a deep history in software leadership and practice. Porter joined MongoDB at the beginning of 2020, after serving as CTO at Grab, a ride-sharing, delivery, and mobile payments “superapp” company based in Singapore. Before that, he spent nine years building Amazon RDS managed database services at AWS. Earlier in his career, he spent 12 years at Oracle, where he worked on the Oracle RDBMS, managed the Oracle RDBMS server development team, and eventually rose up the ranks to report directly to CEO Larry Ellison.
I recently had the opportunity to speak with Porter about joining MongoDB, his relational database snobbery, the advantages of the document model, how to make software developers happy, how to make software deployments safe, and what today’s developers need from the database tier. Porter also discussed what it was like working with Larry Ellison and why developers should not have to become managers to “succeed.”
MongoDB
MongoDB CTO Mark Porter
Matthew Tyson: Hey Mark, thanks for chatting with me. You took up the CTO mantle at MongoDB at the beginning of 2020. What was that experience like, right as the pandemic was unfolding?
Mark Porter: Matt, thanks for taking the time. My journey to MongoDB was an interesting one. To be authentic and a bit ashamed, I really didn’t understand what I’d gotten myself into. While I’d used MongoDB in multiple jobs, I have to say that I was still a relational snob. But as I got to see the power of the document model, built-in scalability, and fully architected high availability, I became much more open-minded. Frankly, MongoDB is a natively highly available distributed system that handles transactions, while relational databases are single-primary transactional systems that struggle with distribution and availability. It also took me awhile to fully comprehend the power of a modern platform—with MongoDB’s drivers, you program naturally in your language and don’t have to go through this incredibly cognitively difficult SQL translation layer. Sure, SQL is mathematically really pure. But MongoDB lets you get things done more practically, easily, and efficiently.
Tyson: What do you see as the frontiers in data? Where is MongoDB researching and pushing the state of the art?
Porter: Well, JSON, believe it or not, is still pushing the frontier of data. We launched with JSON back in 2009, and the power of that data type that is both computer- and human-readable and processable is still being felt across the world. Open standards like JSON, Parquet, etc. are so powerful. And combining them with streaming standards and huge economical object stores on the cloud providers allows easier integration of systems than ever before. We’re really focusing on making it easier to move data between MongoDB clusters and data lakes but also into and out of MongoDB. And we’ll manage it all for you. Just like we removed the need to build a separate search cluster, manage it, and upgrade it — we added open-source Lucene search directly into our back-end engine. Almost every app needs search now, and with Atlas, you turn it on with the click of a button or an API call. I envision more and more integrations like that, but all while remaining standards-based and composable, so people can integrate us anywhere in their workflow — as the system of record, as the landing spot for IoT data, or as the sink for all of a company’s 360-degree data on their customers and suppliers. It’s all about being easy to build with.
Tyson: It’s amazing to think how a seemingly innocuous language feature like JSON has had such a massive impact (thank you, Douglas Crockford).
I’m really curious how you guys go about staying in touch with developers “on the ground.” How do you keep up with the pulse of things as you maintain and expand such a big operation?
Porter: MongoDB has always been a developer-first company. But it’s one thing to say and another to do it; you have to want to listen and learn from the feedback that is given rather than just use “developer first” as a hidden marketing ploy. They see right through that, and justifiably.
So firstly, I think it's a question of mindset rather than the execution of "how." In all of our early years, MongoDB engineers would spend a lot of time at meetups and conferences. Of course, not every interaction can be in person and the pandemic definitely brought that point home for us and many other technology companies. Now that we’re bigger, with millions of downloads and hundreds of thousands of registrations per month, we have a pretty large Developer Relations team, a Champions program, and we’re restarting those same meetups and conferences. But frankly, that stuff has trouble scaling. So we have a lot of great tooling that helps us keep in touch with developers and our open-source roots, and many open-source products keep us in touch with the community.
For example, we still embrace issues and pull requests via GitHub. We use Jira, and our tickets for improvements are public, so users comment on those, and they can correspond directly with our engineers. We use Intercom for chat support. You can reach out to MongoDB support engineers and get an answer usually within five minutes, 24 by 7. And then we use Chorus.ai, which records check-ins and conversations with users and transcribes them. On the back end, our product team goes through those transcripts and uses that data to inform what we prioritize and what we build. On a more aggregate level we analyze and review all the developer surveys that we can find annually—the JetBrains survey, the Stack Overflow survey, and the State of JavaScript are some examples.
I think we are sometimes in the same position as our customer base, which is that we have so much data — culling through and analyzing it in order to prioritize and decision it — that's what's hard. So, we do a lot of things to stay in touch with developers personally, and because of the scale, we bring software and data in to help as well. There is no compression algorithm or shortcut to this part of the business — humans are complicated!
Tyson: When I saw the title of your recent article (“Overcoming the Fear and Loathing of Pushing to Prod”) I had to laugh. There’s always a certain apprehension when the rubber meets the road and the business is about to depend on code we just wrote.
You’ve written a lot of great posts on how to make deployments more robust (“The 180 Rule”, “The Goldilocks Gauge”, etc.). My question here is, how hard is it to get people and culture to adopt these practices? Do you have any insights on that?
Porter: (Laughs.) I’m kind of nervous having you read my stuff. I think I might surprise your readers with my answer. These posts and these discussions are actually far more popular and in-demand from me than anything I say about databases or data. I regularly give talks at all-hands meetings of engineering teams, and we talk about two main things: engineering culture and deployments. I recently was asked to talk to a panel of 56 CIOs, and all they wanted to talk about was culture and deployments! Because, like you say, they’re two sides of the same coin. I mentor teams to focus on candid and open conversations up and down the management chain. Managers need to give developers context, and developers need to give managers honest and timely updates—especially when the news is bad.
But back to your actual question… I find that both managers and leaders need to be more brave. They know what will make their deployments safer, what will make their developers happier, and what will make their sprints more predictable. So when I talk to them, I talk about having low-stakes, honest conversations, where all parties both speak and listen with good intent. Once that is established, the rest can happen. Without that trust, everything is just so hard.
Tyson: You’ve been involved with several patents, including one with Oracle’s Larry Ellison. What is the process of carrying an idea all the way through to a patent? How do you see the role of patents in the software business?
Porter: That one with Larry has a funny backstory. I was in a shop waiting for my car to be fixed and Larry called me about something completely unrelated. But, over an hour later, long after my car was ready, we’d come up with this idea for network-aware bandwidth and resolution adjustments for video streaming. With regard to the role of patents in general, I focus on two aspects — engineering and commercial. There is a certain purity in bringing an engineering idea to such clarity that you can express it in a set of claims that form an elegant onion, building on the idea layer by layer. And engineers should be proud of that — after all, reducing chaos to order is literally what we do.
In addition, from a commercial point of view, it’s important for companies to have portfolios they can use defensively to protect against the trolls out there, the ones trying to make money without adding any actual benefit to the universe. I’m proud of my patents, and we also have an opt-in patent program here at MongoDB that helps engineers be proud of their innovations — and there are a lot of them in progress!
Tyson: Larry Ellison is such an iconic figure, what was it like to work with him?
Porter: Haha, now the gloves are off, is that it? Larry is indeed an iconic person. I’ve found that leaders like him, or Andy Jassy at AWS, or even my current boss, Dev [Ittycheria], here at MongoDB, set the culture for the company — all the way down to every person typing furiously to build or support customers at the company. Larry has a mixed reputation, no doubt about it. My interactions with him were technical — around building database and video server technology — and his passion was always to build the right elegant product, the one that would save customers money and help them move faster. I learned a lot from him during the years I worked both indirectly and eventually directly for him.
For example, we had a meeting culture where all exec staff meetings were Monday, then the next level was Tuesday, then down through the company during the week. By doing this, every single employee at the company had the opportunity to hear about new ideas or directions from Larry’s staff meeting, in person, with the ability to comment and ask questions within a single week.
I think where Larry struggled and continues to struggle is that he lets the senior executives around him build a culture of not treating customers well, and he doesn’t jump in and course correct that. All in all, I’m a Larry fan and deeply value the 13 years I had the privilege of working with him and Oracle. That said, I think the culture of engineering empowerment, intellectual honesty, and good intent that Dev has built here is pretty fantastic — and I’m still pretty much a student of that particular game.
Tyson: I read that you did some coding on the Apple II in Pascal, and I have to tell you, that brings back memories. (When you were creating software to help Alaskans learn trades, I was writing Ultima clones :)
In the same article you say that “every management level should have an equivalent individual contributor leadership level and the pay should be equivalent.” That really struck me. How can we convince companies to make it so? Especially given the prevalence of the belief that one has to stop coding and start managing at a certain point?
Porter: First off — Ultima! What a wonderful world that was. It was amazing what we could do with 64K of memory, a processor running just over a million eight-bit instructions per second, and 140K on a floppy drive, right? Crazy.
Back to your question about having to go into management to succeed. This is a real hot button with me. For the last decade, at News Corp, AWS, Grab, and now at MongoDB, I’ve worked to have equivalent individual contributor ladders and management ladders. And not only equivalent in pay — but equivalent in responsibility and influence. For example, at MongoDB now, Distinguished Engineers are at the same level as Vice Presidents and involved in appropriate levels of decision making and planning. But, like you say, there is this prevalent belief that you have to go into management to make the most money and have the highest title and the most influence. Total hogwash. At each of those companies, I’ve written a document about the differences between being a senior individual contributor and a senior people leader. Both roles care deeply about the company, of course, and about the people. But the people leader takes a deep visceral interest and holds responsibility for every one of their people’s struggles, growth, compensation, and career. Whereas the senior individual contributor mentors people but also focuses just as viscerally on the quality of the code, the processes, and architecture.
Tyson: I read somewhere that you keep up your coding chops by teaching your kids programming (Scala, Java, and others). Do you have any insights on how to maintain that elusive work/life balance?