Mark Porter has always been fascinated with puzzles, so tech just fit for him and a great journey for him. He got his first 4k computer in middle school, and then moved into doing programming for the Department of Education. His big learning from this was that you can use tech to do social good. He's married with 5 kids, and as he puts it, they put up with his deep tech obsession.Mark joined the board of MongoDB in 2019. What got him excited about the company was the world changing nature of the product. So much so, that he asked to step off the board to be CTO - and carry the banner to the developer community about the power of their doc based, distributed system performing DB transactions.This is Mark's story with MongoDB.LinksWebsite: https://www.mongodb.com/LinkedIn: https://www.linkedin.com/in/marklovestech/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
The company was founded on the concept of scaling rights. Of course, the world has changed in the 15 years to now, you know, many orders of magnitude, more demand on our servers. One of the things we have to build into the product is scalability as a feature. And one of the things I've seen in product after product is scalability is an afterthought. So what you'll see is they'll release a POC.
It'll be awesome. They'll go to market. People adopt the product. And then the product management team comes back to engineering and says, okay, now we need to scale it by 10 or 100x. And they say, oh yeah, now we have to go rewrite it from scratch. My name is Mark Porter and I am the CTO of MongoDB.
This is CodeStory, a podcast bringing you interviews with tech visionaries who share in the critical moments of what it takes to change an industry and build and lead a team that has your back. I'm your host, Noah Laphart, and today how Mark Porter stepped off the board and into the role as CTO and continued to build faster with MongoDB. All this and more on CodeStory.
Mark Porter has always been fascinated with puzzles, so tech just fit and has been a great journey for him. He got his first 4K computer in middle school and then moved into doing programming for the Department of Education. His big learning from this was that you can use tech to do social good. He's married with five kids, and as he puts it, they put up with his deep tech obsession.
Mark joined the board of MongoDB in 2019. What got him excited about the company was the world-changing nature of the product, so much so that he asked to step off the board to be CTO and carry the banner to the developer community about the power of their doc-based distributed system performing database transactions. This is Mark's story with MongoDB.
MongoDB is a company that produces a developer data platform. And that means we produce all the different pieces of software that really makes a developer want to build applications. So from a database, to charts, to analytics, to a mobile solution, and we put it all together in a way that is just so easy for developers.
And frankly, that's kind of our origin story, is our two founders, Elliot Horowitz and Dwight Merriman, were trying to build an application. and the current technology they had available just didn't work. And they were developers, and rather than giving up, they said, I don't know, why don't we just go build it ourselves?
And so they took some time off from the company they were building, which was DoubleClick, and they actually built MongoDB. And the reason they needed to build it is so that they could do writes at scale, which for any of you techies out there, you know that you always want your database to be able to take your write, or your entire application grinds to a halt.
And then over time, they figured out that they could make it easier for developers by using a document model. And to this day, even though we've done so much over the last 15 years, the whole concept of being able to read and write at scale and the concept of using the document model are still two of the main tenants of MongoDB's success.
Tell me about what would be your MVP, Mark. So when you joined Mongo, what was the MVP or what was the product you took on, the state of the company? Tell me a little bit about that.
I joined the board in 2019 and then got so excited with the company and its potential and the fact that fundamentally MongoDB had the chance to change the world that I actually asked to step off the board and step up as CTO.
But what got me going was the fact that we had this product that a lot of people didn't know about and still to this day, market awareness is something we're working on every day and is fundamentally a different product. It is a distributed system that performs database transactions as opposed to a single system that tries to be distributed.
And so my MVP when I came on board was this product, which frankly was magical and had so many capabilities that people didn't know about. And so I focused my energy in two main areas since I joined. Area one is growing the team. We've more than doubled the team since I grew the engineering team and growing it as a healthy team with healthy culture and keeping the tech moving forward.
And a second area for me personally has been really helping get the message of MongoDB out into the marketplace with talking with marvelous people like you and just getting that message out that MongoDB is different.
So as you're getting that message out to the world and as you're carrying the banner, I hear that you stepped off the board to be CTO. You're super excited about Mongo. In that process and in the process of advancing Mongo, you gotta make certain decisions and trade-offs about what you can do in the short term versus what you have to cut right then.
So tell me about some of those things in terms of your involvement with Mongo and how you coped with those decisions.
This is fun, and this was an area that I spent a lot of time on. So I started my career at Oracle doing enterprise class databases back in the 1980s and 90s. I then went to AWS and ran one of the largest enterprise class fleets of databases in the world, RDS.
And I then went to a consumer company, Grab, where we were serving 650 million Southeast Asians, serving over 15 million rides, meals, transactions per day. And so mission critical is in my blood, frankly. When I came to MongoDB, we had this great product, but I wanted to have the team feel comfortable with really focusing on what I call the layers of the onion.
And the layers of that onion are security, durability, correctness for a database, of course. Availability, it's always up. Scalability, it can scale when you need to. And operability, meaning that in this world of services, it's operable. Now, all of those things come before the shiny new feature. Now, customers are going to come to you and they're going to say, I want that shiny new feature.
I want that new capability or that new API call. But they assume that you're dealing with security, durability, correctness, availability, scalability, and operability, the six internal layers of the onion. And if you don't focus on those, then you've betrayed the people who put their trust in you. And so when I came to MongoDB,
though we were making progress on all of those areas, I really hammered into the culture that at any level, anyone can raise the card of an inner layer of the onion, security, durability, correctness, et cetera, over an outer layer. And we would focus all of our research efforts and development efforts on that.
And what it did is it gives the team almost a guiding light of how to make decisions, which I like having decisions made at the leaf nodes of the company. not at the core, at the tree, at the trunk. And so by doing this, I helped MongoDB move ahead and have developers who work for me make more and more decisions by themselves.
So from the point of starting and then progressing the product and your mission, how have you gone about that? I think what would be the most interesting thing in that is how you built your roadmap or approach or how you decided this is the next most important thing to address to enable developers to make those decisions.
Well, I got to tell you, this is my humble pie moment of this podcast, probably. I mean, there might be another one, but this is my first one. I came to MongoDB and I discovered a completely different way of building roadmaps. So, of course, we have customers coming and requesting things and all that.
But we have this bottom-up empowered mechanism where any developer can write, probably with a couple other developers most of the time, can write what we call an initiative brief. And they can work with a product manager and they can just ideate
it gets prioritized and we do quarterly planning which is such the right cadence i find split planning to be too tactical i find yearly planning to be i mean heck by the time my yearly planning is done it's obsolete already and so we do this quarterly planning cycle we do it with these a mix of these bottom up and top down briefs and then here's where the magic comes in
The product team spends the first half of every quarter looking through the whole roadmap and going, okay, this came from engineering. This came from this customer. What do we think is important? And then the engineering team spends the last half of each quarter saying what they can and can't get done.
And then the last two weeks on every quarter are everyone getting together and saying, wow, now that we've heard from everybody, and I'll dig into that a little bit more in a second. Now that we've heard from literally everybody, what are we going to do next quarter? Of course we have long-term roadmaps, right?
I mean, we're going to make the server board durable, or we're going to, you know, launch a new multi-year feature. But most of what we do, we don't delude ourselves that we know what's going to happen three quarters from now. Instead, we figure out exactly what we're going to get done next quarter. And the second thing about building our roadmap is we use this thing called LGTM.
And this is my humble pie moment, which is I've always been part of top-down organizations. Organizations where, you know, my boss's boss's boss makes the decision or I make the decision and the team executes. Here, I only LGTM, which means looks good to me. No one comes to me for an official approval on all but the most important things, typically around security.
Most of the time, I'm down in the trenches with the troops making the decisions as a peer. And that makes engineers so excited And so empowered that they just keep coming up with great ideas. And so our roadmap is the amalgamation of all of those ideas. And then every quarter, we lay down in the roadmap what we're going to do. And then we restart over that process again for the next quarter.
So the power dynamic in companies is real. When I say something, I think it's a whisper, but it's a shout. And when I say, oh, that's a bad idea, well, all of a sudden people go, that's not what we're doing. And so one of the things about our culture is it helps what I intend to be a whisper. That whisper that says, God, could you guys just look at this a little bit deeper?
To actually be perceived more like a whisper than a shout.
Well, speaking of that team, tell me about your team and how you went about building it. And what do you look for in those people to indicate that they're the winning horses to join you?
So of course we focus on domain expertise and can they run servers and they know how to program and do they have good logical skills and things like that. But one element that we really focus on at MongoDB is this concept of cultural fit. Now, when I told you about how we did our roadmap, that is an awful lot of people participating in a somewhat consensual process.
And I said how everyone needs to have a voice. So when we interview people, we look for people whose voices are too quiet, who aren't going to speak up, or we look for people whose voices are going to be too loud and they're going to talk over people. And we're really pretty allergic to that. What we want is people who value working together and coming up with great ideas, consensually.
So I, you know, I talked a little bit about LGTM. That's, that's a kind of consensus. And so when I first came here, I was like, God, there's a lot of consensus here. And as I've been here longer, I've learned to delight in this concept, which I haven't patented or trademarked, but I probably should, which is called consensus that moves fast. So a lot of people associate fast moving with control.
And a lot of people associate consensus with moving slow. We work very hard to have consensus that moves fast. So when we build the team, we ask questions about how do you make decisions? How do you work with others? How do you do things like that, where you work? The other thing we do is we, we relentlessly communicate to people.
And so during the interview, we communicate all of our values, we communicate everything that's going on at the company and we watch how they react because we know that if in an interview, they don't react favorably to our cultural tenants or how we behave with each other, they're sure not going to act that way when they get to the company. So,
The final thing we do is we focus on customer obsession. We look for signs that this person is going to have this North star of just wanting to make our customers happier every day and not, they're going to want to get richer or they're going to want to do the next coolest, deeply technical thing, or they're going to want to have a big team.
We really, really focus on listening carefully during the interviews for customer obsession.
It makes a ton of sense. And that speedy consensus, makes also a ton of sense almost like the the speed of there's a little bit of alignment with speed of trust but i haven't heard exactly put that way that's really that's really interesting
I do like the book Speed of Trust a lot. I'm glad you mentioned it. Yeah, it's it's interesting. And of course, we're still working through it. Like while I've been at the company, we started COVID with like fifteen hundred employees and now we're over four thousand, I believe. And so obviously, as we scale and it's going to be really interesting to keep rolling these things out.
So scaling is is just such an interesting challenge for executives.
So it's interesting segue. Actually, it's a perfect segue. How you approached Mongo when you started and you set out to enable developers, you know, tell me about how you think about scalability or how the company thinks about scalability or how the approach to what you did. But was it built to scale or was it executed on scale efficiently from day one?
Or have you been fighting this and changing as you gain traction?
So there's technical scalability, which is obviously awesome. And then there's obviously org scalability. And so the company was founded on the concept of scaling rights. And over time, of course the world has changed in the 15 years to now, you know, many orders of magnitude, more demand on our servers.
And we stick with that belief that one of the things we have to build into the product is scalability as a feature. And one of the things I've seen in product after product that I've either helped build or been part of in my career, is scalability is an afterthought.
So what you'll see is they'll release a POC, it'll be awesome, they'll go to market, people adopt the product, and then the product management team comes back to engineering and says, okay, now we need to scale it by 10 or 100x. And they say, oh yeah, now we have to go rewrite it from scratch. That's just a true betrayal. It's a betrayal to your product management team.
It's a betrayal to your customers. We worked very hard to have all those things I talked about part of our plan from day one. Here at MongoDB, just to go deep into the weeds, One of the things we do is sharding is how you scale out MongoDB clusters.
And now we have a tenant, a tenant meaning a foundational belief in the organization that every single thing we write works with sharding out of the gate. So every single thing we write can be scaled out of the gate because otherwise success actually becomes your failure.
Well, as you step out on the balcony and you look across all that you've built, what are you most proud of?
I'm proud that I have pivoted from problems I faced were under my fingers writing code to the problems I faced were figuring out what a product direction was. Now the problems I face are human problems, are problems with how orgs work together, or problems with how industries see our company. And so I'm really proud of that.
These problems, frankly, are more challenging than the technical problems because they're very amorphous and ambiguous. And as a tech person, gosh, I would just love it if everything was, you know, reducible to an algorithm. But I cannot reduce people to algorithms. I cannot reduce behavior to algorithms.
But I do have a couple specific things I've learned over the years about how organizations function. One of them is this thing called Conway's Law. And Conway's Law stated very simply and not scientifically is that the structure of a product and how well a product works and how the pieces of it interoperate will reflect the organizational structure that built it.
And put rather snarkily, if two managers hate each other and they're working on a product together, those two parts of the product are not going to work well together. And so one of the things I really work on is I work with Conway's Law to make sure that the organization we build is built to serve the product, not the other way around.
We don't look at people's careers and say, oh, we're going to build a team around you having 30 people next to you rather than 12. We try to figure out the product and we fit people into that org structure. So that's number one. And that pays off. And number two, there's this thing called Dunbar's number.
And Dunbar was a researcher at Cambridge who's done research for the last 30 years about how humans interact. And what he found in his initial research was that tribes, and he really did do research into tribes, over human history, groups of about 100 to 150 have been the unit of social cohesion.
Tribes in the Amazon jungle, Roman legions, divisions within companies, and his research is fascinating. And then what he found out and he published this just a couple of years ago, is that there's Dunbar layers. So there's 10 people who I will trust with my life. There's 30 people who I will go out to dinner with on a regular basis and trust and I'll share secrets with them.
There's this 150 group of people who I work with and trust. And once you go past that, now you're in the wild level, the people who you might not trust. So, God, why am I talking about psychology here?
Because if you build teams where the degree of trust you have to work with someone efficiently is larger than your Dunbar numbers, you'll get approval processes, you'll get distrust, you'll get escalations, you'll get politics. And what I've found over the last 10 years as I've focused on this
at AWS and Grab and now here at MongoDB is if I build small teams where the degree of trust matches the team size, things are just easy. And then at the individual dynamics level, Dan Pink said it best with mastery, autonomy, and purpose. People want to be great at something, they want to be left alone to be great at something, and they want to feel that's important.
So rather than thinking about scaling my organization, I think about getting the micro elements, the nano elements of my organization right in terms of people having mastery, autonomy, and purpose, and in terms of groups being organized, according to their Dunbar number and Conway's law. And I find that if you do that, everything is just easier. And so you asked me what I was proud of.
And frankly, it's these insights that I am most proud of as CTO.
Let me flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
There's a lot of mistakes to choose from. Some of them were avoidable, some weren't. So I love to embrace experimentation and figure out what's going to happen as a result of it. I don't view those as mistakes. Some people call that embracing failure. I call it embracing experimentation. A mistake is something where you could have predicted bad stuff was going to happen.
So a huge mistake I made is when I joined Amazon, the relational database service, the operational excellence of the team was just not great. And we kept delivering feature after feature after feature. And yet our databases didn't stay up.
so i was yelled at for the first two years i was the general manager of rds i was yelled at by customers and it hurt and my mistake was not pivoting fast enough to operational excellence to those things i told you about to security durability availability operability all those things and when i did pivot i lost almost 60 of the group over that next year because they'd been trained to come in
and fix operational mistakes and firefight. And none of them had ever been trained by me to hold their ground on operational excellence and security and durability. Now RDS was a great service, don't get me wrong, but we held it together with human toil, not with software. And so what I learned from that and what my team learned from that is it is never
too early to talk about operational excellence. It is never too early to in your very first product document to talk about scalability. Now here at MongoDB, I found a culture which actually cherishes that, I think. And so it's really delightful. So I hate betraying people and I hate being screamed at because I betrayed them.
And so now at MongoDB, I'm open and transparent with customers about what our product does and doesn't do, sometimes much to their surprise. And that makes my team trust me that as CTO, I'm not going to paint them into some imaginary corner of lying to customers about what our product does when they know full well it doesn't do that.
Well, Mark, let's switch to you. Who influences the way that you work? Name a person you look up to and why.
Well, this is going to sound pretty, pretty brown nosing, but I really look up to my CEO, my CFO, my CPO, and my CRO, my chief revenue officer. And in fact, to many degrees, that's why I joined MongoDB. It wasn't just the technical thing. And the whole rest of the C staff we have here is, and the E staff, the executive staff here we have is amazing.
But let's get into some details of why I look up to people. I look up to people when they can turn a high stakes conversation, something that is emotionally charged and risky into a low stakes conversation. And there's a book called crucial conversations, which I will highly recommend all of your listeners.
And it talks about how there's this false choice between saying what needs to be said and having a big argument. The reality is, is that the best leaders teach their teams to say what needs to be said without it being a big argument.
And the way I do that and the way I've been taught to do that by these great leaders is we turn and we face the customer and we say, what is the best thing for the customer? We have full faith that that's going to result in being the best thing for our company.
And we have full faith that's going to result in being the best thing for our employees and by transference, the best thing for our shareholders. And so if you think about those four tiers, customer,
company employees and stakeholders i look up to people who i can work with on that hierarchy on that fundamental maslov's set of needs but maslov's set of needs for a fundamentally successful technical company and i really love working with people who we can do that I also hate politics.
I hate people bringing too much emotion to the table that's false, that they're using emotion to get something done. But I love it when people bring authentic fright, authentic fear, authentic uncertainty to a situation so we can all lay it out on the table and just be human together.
Well, we talked about a mistake earlier, but maybe a little bit different spin on the question. If you could go back to the beginning, what would you do different? Or where would you consider taking a different approach?
MongoDB has had such a massively successful arc of our company, and yet it has had missteps. In the early days, we probably promised a little bit too much. Maybe we would have promised a little bit less. We got in trouble in 2013 and 2014 about maybe promising too much with transactional consistency and things like that. Then we came along and we introduced full asset transactions in 2018.
So, so that's an area where I think we could have done a little bit better than, and the company was growing and that's fine. Um, you know, I don't really have any other areas where I think that, that we have needed to take a different approach. I think we've actually executed really well. And a large degree of that is because Dave, my CEO listens.
And so people bring up problems to him all the time and he listens and we change our course regularly as a result of that. So when we say taking another approach, I mean, frankly, we take another approach all the time.
That's an awesome answer. And I really like the part at the very end that makes a ton of sense. You're taking different directions all the time because your leaders are listening to your people.
So micro changes should be embraced. What you want to do is be aware of what's going on and not have this culture where people are afraid. What's that phrase? The elephant in the room or whatever. And people are afraid to say the scary thing.
Well, Dave, again, I'm not brown nosing Dave, if you're listening, Dave often just pauses and lets the silence in our meetings go for like 30, 40 uncomfortable seconds until someone says, you know, I'm not really comfortable with what we just decided. I just really want to talk about that more.
And that helps us make those micro course corrections to avoid the macro course corrections, which are the ones that damage organizations, damage people's careers and damage companies.
Well, Mark, last question. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and can't wait to show it off to you right there on the plane. What advice would you give that person having gone down this road a bit?
The first advice, unsurprisingly, relates back to a lot of what we've talked about on this podcast, which is be human first. I mean, that's not a surprise. So I'm just going to say be human first. Be human with everyone. Don't pose. Be vulnerable. You're actually stronger through vulnerability. So that's a piece of advice, number one. And they'll all look at you and they'll all nod.
And then six months later, I'll get together with them on a conference call because I mentor a lot of entrepreneurs. And they'll go, yeah, I haven't been doing that. Okay, so that's fine because that's a lower brain thing. So the first piece of advice is be in touch with your lower brain because entrepreneurs are in touch with their frontal lobes, with the, what is the algorithm I'm writing today?
How much revenue am I going to make from it? What's my pitch deck look like? All that. So be in touch with your lower brain too. That's the first piece of advice. The second piece of advice I would give them is you're gonna think that being right is what matters as your company grows. Now, sure, when you're at five people, 10 people, 20 people, yeah, you gotta be right.
You gotta get that next round of funding. You gotta be just perfectly right because I don't know what the number is, but the vast majority of startups fail. But at some point, you're gonna pivot to what's important being you helping the people work for you to be right. And that's what your new right becomes, because you won't scale.
And so right now, MongoDB is crossing 4,000 people, and we have this wonderful senior leadership team of like 80 or so vice presidents or whatever. And we are now, as the executive team, teaching them to be right. Not us at C-levels. We're spending all our time teaching them to be right.
So the way I would package that all up, that second piece of advice, is be aware that the company you are building this month, the company you're going to have six months from now, a year from now, and two years from now are all different companies. And embrace that change. Welcome that change. And experiment through that change. Don't fight it.
Because the company you're building right now, sitting beside me on an airplane, is not the company that will be successful two years from now.
Fantastic advice. Well, Mark, thank you for being on the show today. Thank you for telling your creation story and start at MongoDB.
Thank you so much. It's been a pleasure. And I do hope that someday we get to have a physical coffee together.
Same here. And this concludes another chapter of Coat Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. Support the show on patreon.com slash codestory for just five to ten bucks a month. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.