Mark Porter
Appearances
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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?
Code Story
Replay: Mark Porter, MongoDB
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
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
And frankly, it's these insights that I am most proud of as CTO.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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
Code Story
Replay: Mark Porter, MongoDB
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
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, 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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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,
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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?
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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?
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
Thank you so much. It's been a pleasure. And I do hope that someday we get to have a physical coffee together.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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,
Code Story
Replay: Mark Porter, 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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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
Code Story
Replay: Mark Porter, MongoDB
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
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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?
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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?
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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,
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
We really, really focus on listening carefully during the interviews for customer obsession.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
So scaling is is just such an interesting challenge for executives.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.
Code Story
Replay: Mark Porter, MongoDB
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.