Mark Porter (MongoDB)
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 Amazon Web Services (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.”
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 prioritise and what we build. On a more aggregate level we analyse 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 analysing it in order to prioritise 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.
Read more in the next page...
