Mark Porter, CTO of MongoDB - Making Databases Faster

(Joel Beasley at 00:00:05) Hello, my friends. Today we're talking to Mark, the CTO of MongoDB, and we discuss MongoDB's fresh take on making databases faster, more efficient, and easier to use, the importance of always being a student of life, and how to make space for open and honest conversations with your employees as a manager. All of this right here, right now on the Modern CTO Podcast.

(Joel Beasley at 00:00:34) Here we go. This is the Modern CTO Podcast.

(Mark Porter at 00:00:46) Yeah, so I got started. I got a 4K Model 80, sorry, 4K TRS-80 Model 1, and I started programming. I just loved puzzles, and I've always loved puzzles. And frankly, I still love puzzles. And I'll get into that a little bit more with leadership because leadership is just another kind of puzzle. And then I started noticing that people around me thought it was interesting that I could program, and so I've always been kind of fed by other people. And I'd love to solve problems, and I noticed that computers could solve people's problems all the way from gradebook programs to jog-a-thon programs to sum up all the money. And then eventually, I got into my first real cool program was a heating program where contractors would go to people's houses in Alaska. They would write down in a calculator all of the glass and walls of their house, and then this little tiny calculator running at 10 kilohertz would crank over an hour or two what the energy savings could be if you upgraded this window or this insulation or this wall. And then they would take that receipt to the State of Alaska, and the State of Alaska would actually pay for them to improve the energy efficiency of their house. It was the first public good program I ever wrote, and number one, I got paid for it. And number two, it actually helped human beings, and it made me so happy.

(Joel Beasley at 00:02:09) That is super cool. Wow, that's such an awesome use case. It actually just ran on a calculator?

(Mark Porter at 00:02:18) It ran on an HP-41CVX, the one that had, I think, 10Ks of memory.

(Joel Beasley at 00:02:23) Oh, that's amazing, man. Yeah, I think that's the definition of writing some code that's immediately impactful. Yeah, so that's awesome. Where did you go from there? What was your first major job in tech?

(Mark Porter at 00:02:37) So my first one that I'll tell you about was actually interesting. I got a contract from the Department of Education that helped me pay for Caltech, and what we did is we wrote courses in accounting and legal. And I wrote all the course authoring software. I wrote all the course delivery software. I wrote all the grading software on a 64K Apple II. And then what they did is they would take these courses, these computers, and they put them on carts with generators because a lot of these remote Alaskan villages did not have power. And they would fly them out to Alaskan villages, and they would teach these natives. They would teach them paralegal and accounting so that they could then go to the cities and they could actually have gainful employment. And it was totally awesome. And then I went at Caltech, I got really nerdy, and I worked on semiconductor chip and a little bit of space stuff, whereas I was just a computer person. I don't know anything about chips or about space, but I was running the computers for some teams there who were doing really cool space science and chip science.

(Joel Beasley at 00:03:46) That's awesome. Yeah, and I know that you spent some time at NASA. What about that?

(Mark Porter at 00:03:53) So that was at NASA. That was at JPL. Caltech runs JPL for NASA, and it was awesome. And what we did there was I ran this one megabyte MicroVAX. By the way, we're up to a megabyte now. I ran this one megabyte MicroVAX, which had, this is going to blow you away, up to 30 concurrent users, and we all loved it. And now the concept of running 30 concurrent users on a one megabyte machine, I think, is a joke. Yeah, but yeah. And so we ran all the software which ran this lab. It did all the science. It did all the bookkeeping. It did all the grant writing. And I got to be the system administrator for 30 scientists, and I really just loved it. Again, you know, helping people out. I really, really liked helping people out. And along the way, databases came into my Department of Education contract and came into my JPL work. And I just love the promises that databases make to customers. In my very, very, very biased opinion, there is no other piece of software in computer science which makes the same promises of consistency, durability, correctness, availability, when we can do it, in all of computer science. And that has always fascinated me about databases.

(Joel Beasley at 00:05:12) That's awesome. So you were working with databases throughout all of these, or when was your first job that you were 100% focused on the database side of things?

(Mark Porter at 00:05:23) So when I was 100% focused was I left Caltech and I went to get a job at Oracle. I was the 11th member of the Oracle kernel group, which was a group that wrote the database. And for those of you Oracle users out there, I was involved in 5, 6, 7, 8. And it was such an amazing team. It was the first team I'd ever been in. And if we get into talking about leadership a little while later, we can talk a little bit about why it was an amazing team. But it was just this great team that developed the Oracle database. And I was running the part of the database which was the lowest part, the service layer, the processes, the memory, the files, you know, all this other stuff that was basically like the operating system for the database. Now for those of you people listening, this was long before Linux, long before even Unix had taken off, and at one point we ran on 86 different operating systems. And I had to learn to write software at that lowest level of Oracle so Oracle could run on 86 different systems, only about 30 of which were Unix-based. Wow. Now over time, obviously, Unix took over.

(Joel Beasley at 00:06:31) Yeah. Man, that is crazy. I've had very limited database coding experience, but it was probably much easier. In fact, the most frustrating thing about it to me was that it was easy because I had, before, I had experience coding in Java, just, you know, writing every line of code. Every time you need anything to happen, you have to write the line of code for it. But I worked for a while on a database in FileMaker that had the database on the back end and then a kind of OS layer that anyone could work with it normally. And in FileMaker, they have their own kind of retrofitted coding language that you have to do a lot of clicking around and selecting options in it so that it's easier if you don't know how to code. But when you know how to code, it can be frustrating, just wanting to type out and make it work. But a lot of times things are hidden behind menus so that it's easier for you to click through and navigate. I'm not really sure where I'm going with that, but that was just my experience.

(Mark Porter at 00:07:46) I'll take it somewhere. I mean, if we're going to have fun, I'll take it somewhere. So databases have been doing that their whole lives. In fact, SQL was a language that was explicitly created to bend developers' heads around how the database worked. And by the way, it was great. It was invented in 1970, which I think is 51 years ago this summer. Wow. And which is kind of amazing to think about, too. And, you know, there's a lot of people listening who might not know a lot of this stuff. You know, databases first really came of age in the '60s with some IBM stuff. SQL came out in the '70s. The first implementation of SQL was 1978 by a company known as Relational Technology Incorporated, which would later be known as Oracle, by the way. And it was created where Larry Ellison got the CIA to fund him for a project to build a database, and he got to keep the rights, and they used SQL to build it. And then as soon as they were done with the project for the government, they then went and commercialized it, and that's what became the Oracle you know of today. Wow. And that's kind of cool. It's kind of a cool story. And that was in 1978, and the company went public in 1984. I mean, that's amazing, right? What a crazy story. And the reason that story is incredible is because it shows how much the world really, really wanted this technology.

(Joel Beasley at 00:09:09) Yeah. Wanted it enough to adopt it so fast to have a six-year turnaround going public.

(Mark Porter at 00:09:17) Right. Now, however, we kept building those FileMaker interfaces. We kept building SQL. MongoDB came along 40 years after the database had been created and took a very different approach. And it's one that I actually didn't know about that much when I was at Oracle, obviously, because it was before it. MongoDB believes that developers should just write in the language they want to write in. Save the structs you want to save. Save back the structs you want to save. And just write in your native language. And so that's really, if you were to look at why MongoDB has been so successful, and there's a lot of reasons, and I'm not going to pin it to just one, but I would say one of the top three is this concept of just letting engineers be engineers and not making them twist their heads around the technology.

(Joel Beasley at 00:10:03) Yeah. So let's take a quick step back before we get into MongoDB. You're the CTO of MongoDB. We haven't said that yet. But...

(Mark Porter at 00:10:14) I am indeed.

(Joel Beasley at 00:10:15) So can you give me, and for the listeners, a brief overview of what MongoDB does?

(Mark Porter at 00:10:22) Sure. MongoDB is a company which produces technology. So for those of you who might not be technologists, the main piece of technology we produce is the MongoDB database. We also produce analytics software that helps companies, you know, analyze their data. We produce a mobile solution called Realm, which lets people have a mobile solution that ties all the way back into the cloud and do things together. We have a search solution. We have charts. So we're kind of an entire application data platform. And our goal as a company is to help companies build applications faster and more efficiently, and it's that simple. And over time, we might change what tech we bring to the forefront, but our one North Star is making it easier for developers to build great applications.

(Joel Beasley at 00:11:13) That's awesome. So you said that earlier that MongoDB allows developers to code in whatever language they want for their databases. Is that your main differentiating factor? Is that what makes you guys the best? What else makes you the best?

(Mark Porter at 00:11:27) No, there's, don't get me started. There's a lot of things. But the first thing I'll tell you is we looked deeply, and the founders, not me—I just joined a year ago—but the founders looked deeply at relational technology and how relational technology involved tables, which involved things all talking to each other across many, many tables. And while what E.F. Codd did in 1970 was mathematically pure, it turns out it's not performant. If you have to have a computer go look seven different places to get the information about you and your shopping cart, it's just going to be slow. So what our founders did is they tried to push relational databases. This was in 2007, 2008, 2006 as well. They tried to push relational technology as far as they could, and they ran out of steam at 400,000 transactions per second. And so they decided to go write their own database that stores the data you use near each other and retrieves it and stores it together, and that's called the document model. And it is a far more natural way for databases to store data, and it's actually a far more natural way for developers to store and retrieve data. So those two things put together, which is bring the computer the way it works best in sync with the way the developer works best. Now in 1970 and the '80s, computers were slow and hard. Computers are so fast now, it's the developer productivity which is the limiting factor. So if I was to say, what is it that we do best? The document model, scaling out to massive systems, and just really delighting developers. If listeners were to walk away with those three things—natural documents, high scalability, and delighting developers—I'd be really happy.

(Joel Beasley at 00:13:20) That's amazing. So what would you say are some misconceptions that people might have about MongoDB, outside of maybe they don't understand those three things or, I don't know, just any kind of misconceptions that you hear about?

(Mark Porter at 00:13:36) So MongoDB was started in 2007, and there was this massive uptake of the technology, and it was awesome. And then people started comparing it to the relational engines that had been around for 30 years. And MongoDB was a new database, and it wasn't mature at that time. And so some of the misconceptions about MongoDB are that it's not mission critical, not secure, not multi-cloud, not enterprise ready. And while a lot of those things might have been true within the first 36 or 48 months of the company's founding, we're now 13 years in, I guess 14 years in, and that is not even vaguely true. We run mission critical workloads for banks like Barclays, Morgan Stanley, enterprises like 7-Eleven. We run travel sites. We run banks. We run trading desks. And so the biggest misconception is whether or not we're ready for the enterprise workloads of today, and that's just not there. The other thing that people might be confused about is whether or not we run everywhere. So we started out running only on your laptop and then only on your data center. And now we run in not only the three major clouds and not only in your data center, not only on your laptop, but we also run in all the other clouds, like Tencent and Alibaba and all the other clouds. And so literally, MongoDB is the only database that you can't point someplace we don't run on, and we're really proud of that.

(Joel Beasley at 00:15:07) That's crazy. How did you manage that? Was it really challenging to maintain all of those relationships with different partners?

(Mark Porter at 00:15:17) I do spend a lot of time on those relationships, and they're really good. MongoDB's culture has always been just one of directness and candor. And so when we work with these partners, we just say, we want to work with you, and we're not going to play any games between you and other partners. We're just going to have a great relationship with you. And that pervades our culture internally, this culture of candor and context and empowerment. And I just got to tell you, as a CTO who's been in a lot of companies, and I'm not going to throw any companies under the bus, this way we work with our customers and our partners is better than any company I've ever been at.

(Joel Beasley at 00:15:59) Wow. That is a big compliment for the company.

(Mark Porter at 00:16:03) And I'm learning, by the way, because I've been trained by working at other companies. So I've had to unlearn some behaviors. Let's just take that one.

(Joel Beasley at 00:16:10) Okay. Well, so let's get into it a little bit. Without naming any names, what are some of the bad habits you picked up throughout your career, and what are you learning right now?

(Mark Porter at 00:16:21) So the one that I'd start with is customer obsession. And there are companies out there that really focus on, hey, we think we know what's right. We think we do this, and they don't listen to their customers enough. And I learned at Amazon—I'm going to give a compliment to companies all over the place, I just won't do it first—Amazon starts with the customer first, and so do we at MongoDB. We start with what is the need, we work backwards through the needs, we see if we have a product to direct it. So that's thing one. And it has to go all the way back to the developers. So we write these things called initiative briefs that turn into initiative plans, and they go all the way back to the developer where right there in their design doc is the needs of the customer. So that's thing one. Thing two is, and I talk about this in a lot of blogs, is technical debt. There's this very weird balance between writing the right product and making it perfect and getting it to market. And that balance is something which I talk about in a lot of blogs about. I think it's time that developers stood up for themselves more. I think developers need to say no. I know the quality of the product has to be this.

(Mark Porter at 00:17:36) So sometimes you want to release the product right now. Get it out there. Let customers play with it. Tell customers it's not done. See what they learn.

(Mark Porter at 00:17:44) Other times, if it's like software for a bank, well, no, it's just got to be perfect. And that dynamic, I find, is often lost on developers who are early in their career who don't know when to stand up and take a stand for the correct quality of their product.

(Joel Beasley at 00:18:02) Yeah. I mean, that's really hard, especially early in your career, to have the kind of confidence to say no to someone that's your superior at your company. So how do you create a culture at your company where you can encourage people to have that kind of confidence to take a stand when they need to?

(Mark Porter at 00:18:23) So I'm going to speak generally because MongoDB, we're still working it out like everyone else, and I don't want anyone to think that, you know, we're perfect. What we've done recently is we've added some questions to our quarterly planning, which a lot of people participate in. We do quarterly planning of the next quarter for our products. And some of those questions are, hey, does anyone want to say we're moving too fast or too slow? We've actually added that to the list of questions we will answer in every quarterly planning.

(Mark Porter at 00:18:52) And we've noticed that if we don't ask those questions, no one will volunteer. But when we ask those questions, people start saying, yeah, I think we're actually producing a product which maybe doesn't have the right level of quality this quarter. Maybe we should delay it till next quarter. And so where I think leadership plays a role is in creating open conversations where everyone gets to say their piece in a productive and psychologically safe way.

(Mark Porter at 00:19:22) And that requires vulnerability on the part of leaders. Because sometimes you're going to ask, is this the right thing for us to do? And in the next ten minutes, you're all going to find out that you're doing literally the wrong thing this quarter, and you should probably replan. We actually had that happen about three months ago with one of my teams where quarterly planning just went wildly off track, and we replanned the entire quarter. And that requires leaders to be able to go, wow, we were just wrong. And that's really hard for leaders because we're held up on some kind of pedestal where the reason we're your leader or your manager is because we're smarter than you are. And I just want to say to anyone listening out there, we're not smarter than you are. We just have a different job. And our job is to help steer the ship, and our job is to help you feel psychologically safe.

(Mark Porter at 00:20:17) We're not smarter than you are. And so help us do our job just like we're helping you do your job.

(Joel Beasley at 00:20:23) Yeah. That's it. At the end of the day, the only difference is that's just what you're spending your time on. Someone has to do the steering the ship and spend their forty-hour week on that. And someone else has to spend their week on writing the code.

(Joel Beasley at 00:20:37) Someone else has to spend their week on the marketing. Everyone's just doing their thing. The hierarchy doesn't represent your value. It's just your job, and someone has to be there to say what's what and steer the ship.

(Mark Porter at 00:20:54) Right. So hierarchy should not represent power. Hierarchy should represent assistance. So my boss, Dave, assists me. He starts our one-on-one with, how can I help you this week?

(Mark Porter at 00:21:06) And hierarchy should represent assistance. So I think of an org chart as a tree that grows up out of the ground with branches, which is the reverse. It's vertically flipped. And I think of myself as being one of the branches or maybe even near the root, I guess, since I'm a C-level. And I think of myself as supporting the rest of the tree.

(Mark Porter at 00:21:27) And it's those actual branches and the actual leaves which type the code customers care about, which answer customer questions. They're the ones which should get the nutrients. They're the ones which should see the sunlight, and we're just here to support them. And companies which have it the reverse, it's a very uncomfortable environment for everybody because the employees are like, hey, I'm doing the work customers care about and not getting recognized for it.

(Mark Porter at 00:21:54) And the managers are actually being put in this unnatural position of being held accountable for doing something other than helping employees. So do you get my tree analogy versus the other pyramid analogy?

(Joel Beasley at 00:22:07) No, that's an excellent analogy. And it actually makes me think about another concept that I've heard come up over and over again. So a little while ago, we had on this guy Sebastian Grady. He's the president of a company called Rimini Street. They do enterprise software support for SAP and Oracle and stuff. And he was an excellent leader as well. And I say as well because I'm loving your advice and I think you are an excellent leader. But he was talking about how it can be challenging to stay close to the customers, especially the higher up you get in management. And your tree analogy is fantastic in terms of explaining how the management needs to be supporting the rest of the org. But I think it highlights how it can be difficult when you're the roots and the leaves are the ones talking to the customers. It can be challenging for you to get in there and talk to the customers and have a good understanding of what they want. So how do you do it?

(Mark Porter at 00:23:11) The analogy falls through. The analogy doesn't. So yeah. But in terms of supporting people, the analogy works. But let me tell you how we do it.

(Mark Porter at 00:23:20) So we have a Slack channel which has tickets in it, and I make a promise that once a day, I will click through on one of those tickets. It's just a Slack channel that streams by with the customer tickets. I click through on one ticket a day. Period. End of story.

(Mark Porter at 00:23:38) I look at the case. I look at the case comments. I'd say a third of the time, I follow up with somebody and say, wow, this is really interesting. What happened here?

(Mark Porter at 00:23:47) That's thing one. Now that's an on-the-ground kind of thing, which might not be appropriate for a C-level to do all the time. The other thing we do is just this quarter, actually, we now have support bring us our most important customer issues every week, and they bring them to the executive staff meeting that occurs every Monday. And it is right at the front of the staff meeting where we read about our most important customer interactions. And that's how we keep customers front and center.

(Mark Porter at 00:24:17) Now in quarterly planning, which occurs once a quarter in the middle of the quarter, product managers also bring in—and what we're doing is we did this at AWS really well, and we're bringing that to MongoDB as well—is product managers actually bring in customer examples for each of the features they want us to work on in engineering. And they'll say, this customer needs it for this reason. This customer needs it for this reason. And those customer anecdotes, I find so powerful. And so we're trying to bring that light of the customers in to every part of the organization.

(Joel Beasley at 00:24:54) That's awesome. So I imagine if you're working with so many customers and with each customer, you need to have a somewhat customized solution for them so that their database works for exactly their needs. And you have teams working on that specific solution, and you have another team working on another specific solution. And each team is learning very specific things that are valuable learnings for the whole organization. How do you make sure that those learnings are dispersed throughout the organization in a way that everyone can grow from the learnings of individual teams?

(Joel Beasley at 00:25:34) Does that make sense?

(Mark Porter at 00:25:36) Yeah. You know, and it's a struggle. So we have reading groups. Some of our teams have reading groups where they read. Some of our teams have discussion groups.

(Mark Porter at 00:25:44) One company I was at had a twice-a-week voice of the customer session, which anyone could attend. And that was kind of fun, but attendance trailed off on it. So we do all-hands where we do customer spotlights and things like that. And I think when you talk about learnings, we do these quarterly all-hands, at least in R&D and research and development slash engineering. And we try to share not only roadmaps of what we're working on, but more general topics.

(Mark Porter at 00:26:14) But I'm going to tell you right now, I mean, I've had some pretty good answers, I think, for some of your questions. We're still learning on how to do that one. I don't really know how to do it.

(Joel Beasley at 00:26:23) I mean, it's a big challenge.

(Mark Porter at 00:26:27) One of the things you'll hear me talk about in a lot of talks is the Dunbar number and Conway's law. And so Conway's law is that you kind of ship your organization. If two leaders don't like each other and they're far apart in the org, then I guarantee you their products aren't going to work well together. Right? And you know, even Satya has talked about this law and how it affects Microsoft, which I was very amused by.

(Mark Porter at 00:26:49) And then the second rule I try to keep into consideration is the Dunbar number, which is typically for most humans around 70 to 75 people, which is the number of people you can trust or keep in your social circle comfortably. And what you really want to do in today's world is you want to have teams and interactions which are within the Dunbar number. You want to work with teams you trust. Teams you're like, hey, let's go out for dinner or let's have a Zoom chat, I guess, this year or whatever. And so you don't want to build monolithic thousand-person teams where people don't trust each other.

(Mark Porter at 00:27:26) And so when I talk to customers, I talk to more than one CTO a day, by the way. My EA keeps track of it for me. My average since I've been here is I've talked to 500 CTOs in 400 days. I talk to them about how they structure their teams and how they structure their software, and I try to detect if those two things are in sync or not. And that, I think, is one of the goals of leadership that is often overlooked.

(Joel Beasley at 00:27:58) Wow. So you're engaging with these CTOs, not just on a product level, but also you're helping them steer their company a little bit and lead their teams?

(Mark Porter at 00:28:11) Quite frankly, I would say one-fifth of my CTO conversations are product conversations. I would say that CTOs and executives in general, CTOs aren't a special branch. We live at the top of that pyramid I talked about, right? Which means the buck stops with us. In most other jobs you'll have in your life, there's someone above you, someone who can give you advice, someone who's been there before.

(Mark Porter at 00:28:40) As a C-level executive at a public company, there's no one. So we all reach out to each other, and we all learn from each other regularly. And we counsel each other, and we berate each other, and we learn from each other constantly. And that's actually one of the most rewarding parts of my job right now is learning from these other executives who've all been through so much. And that's another thing I'll say.

(Mark Porter at 00:29:05) Learning never stops. If you ever think you're the master of the game, you have failed. You are always the student of the game.

(Joel Beasley at 00:29:12) Absolutely.

(Mark Porter at 00:29:14) Yeah. And I don't care what role you're in. I don't care how high you are. I don't care if you're a CEO. You are always the student of the game.

(Joel Beasley at 00:29:21) For sure. Yeah. I mean, continuous learning, I think, is one of the most valuable traits you can look for in a person. Whether you're looking for an employee or a trusted advisor or even a friend, you always want someone that's willing to always continue to learn and change because, yeah, as you said, you're never the master of really anything.

(Mark Porter at 00:29:48) Exactly.

(Joel Beasley at 00:29:48) It reminds me of in music. I always think it's funny when people try to debate whether, like, which instrument is harder to play. I think that's a really funny debate because at the end of the day, every instrument is impossible to master because there's always people that are putting in an exorbitant amount of effort to get the most possible out of any given instrument. And the difficulty of an instrument and the level of mastery is relative to the other quote-unquote masters of the instrument. And so when you're comparing yourself to the other people that are just pushing beyond the limits, it's all impossible—and not impossible, but it's all incredibly challenging. There's no easy one because, yeah, a level of mastery is just extremely difficult in a continuous journey that never stops.

(Mark Porter at 00:30:49) Yeah. I think that's insightful. So if you think about a graph that had, you know, mastery on one axis and time on the other axis—or effort maybe, maybe effort on the other axis—visible mastery of instruments could go up really high like drums. I can hit a rhythm within five minutes. But piano might take longer or, god forbid, the wind instruments like, you know, saxophone, which my son is learning, the learning curve.

(Mark Porter at 00:31:14) But then there's the real mastery curve, which is, are you really good, which is probably different. And I think the thing that's interesting is in an orchestra, everyone has a part to play. We've already talked about that at work. You know, the marketing person and the CEO and the developer and the person who runs the front desk are all just as important to the company in terms of them playing their role. And an orchestra is the same way, and mastering job skills is the same way.

(Mark Porter at 00:31:40) And so when you think about the world of tech today, I think it's really interesting because there's all these frameworks out there, and you can master some of them. Like literally, you can write an app against MongoDB in VS Code in ten minutes and be putting data in and taking data out. And as much as I would love it to be the case that that makes you a master of databases, it doesn't. And so it's kind of like the drums. We've made it easier to acquire these skills.

(Mark Porter at 00:32:09) But the one thing that I feel so passionate about is that becoming the best person you know at something should be something we all strive for, whether that is in facilities or marketing or code or running podcasts like you do. What I try—I have five children, and what I try to train my children or what I try to nurture my children is learn that feeling of being, oh my god, I was good at that. And I don't want my children to become addicted to all the different things people can become addicted to today, but I do want my children to become addicted to that feeling of I was good at that combined with the feeling of I helped somebody. And if we could all keep that as our North Star, even as companies, my company helps people, and even as individuals, which is I'm really good at something, I think a lot of questions get a lot easier to answer.

(Mark Porter at 00:33:10) And I really am not going off the rails. You asked me ten minutes ago about culture. The companies which I have found have the best culture are the companies who really focus on doing things well and doing good in the world to some definition of good.

(Joel Beasley at 00:33:27) That is amazing. Yes. Yes. So you are clearly very passionate about this. And as we discussed at the beginning, you're working from your home office.

(Joel Beasley at 00:33:37) And I know how challenging it is when you're working from home and when you're especially working on something you're passionate about, where to draw the line of when to stop working and how to draw that balance because it's so easy to just work and wake up and work until you go to bed. So how do you create that balance? Especially, I mean, I know you just mentioned you have kids. Like, how do you do it, man?

(Mark Porter at 00:34:07) So it's been a struggle for me. I will tell you I'm a little bit unique. I love working. I always have loved working. I don't work because my boss makes me work.

(Mark Porter at 00:34:15) I'm just one of those people, but I've learned that that has detrimental effects on the people around me. And so just in the last year, I started doing things like after 6 PM, I set the email in Gmail to deliver at 9 AM the next morning. Slack just this month delivered a feature where I can now delay sending Slack. So I think that if we all start respecting each other's time—and my Slack mood, for those of you who use Slack, my Slack mood is, please disregard the time or way I sent you this note, and please respond in a way and at a time that is natural for you. So as we've gone into this pandemic, it's become more and more important for us to respect each other.

(Mark Porter at 00:35:05) That's side one. But it's become just as important for us to understand ourselves and know what works for us and stand up for ourselves. And so I think that as time goes on, cubicle farms are going away. Eight to five programming is going away. You know, meetings where we all sit around a table for some reason while one person talks are going away.

(Mark Porter at 00:35:32) I really think we're gonna open up lots of doors. And so I think I drifted off your question a little bit. But the net net is that I think that we all have a lot of ownership. And while I will never say that COVID is any kind of blessing in any way, what it has done is slapped us upside the head and made us reevaluate our family life, our personal value, how we get along with people at work, and how we use our time. And if we can take that positive from all of the negatives, I think that'll be really cool.

(Joel Beasley at 00:36:04) Yeah. And I think something that I've seen that's incredibly encouraging on top of that positive is when you look at companies that are implementing tactics to respect their employees' time more. I mean, just for one, work from home. And also, I was just talking, I can't remember the company I was just talking to, but they've implemented a five and four work week. So they have a full five day work week, and then the next work week, Friday's off every other week. And the coolest thing is when you get to hear about these initiatives that are going on and they study productivity before and after, and there's not a change or as was the case with a lot of companies going to work from home, productivity actually increased. And it's really, really cool to get the numbers to back up: Hey, treating people better is actually better for your company.

(Mark Porter at 00:37:05) Yeah. Yeah. To get actual numbers. So I'll tell you this. Our executive staff, me not included because I've just been following their lead, has been so good at coming up with what, you know, used to be the future of work, but is now the now of work.

(Mark Porter at 00:37:19) And so we let people work remotely or flexibly in office or not. And even our in office model is only three or four, three or more days a week. Right? So it's not five days a week anymore. And we let people move between those models as is appropriate for them and their lives and all that.

(Mark Porter at 00:37:37) And this concept of focusing on do the work, be creative, get along with your coworkers rather than these other metrics we used to use, which is, hey, I don't see you at your desk very much. It is so wonderful. Now, by the way, to be really clear, engineering was already there mostly. But for a lot of the other parts of the company, it's really refreshing to see these things happen. And I think that's a good thing.

(Mark Porter at 00:38:07) And by the way, one thing I'll point out to you and others is a lot of people say how hard it is to get to know people over Zoom. And I'm just gonna challenge that. I mean, I'm staring at you. I see your face. I moved your face right beside the camera.

(Mark Porter at 00:38:23) You probably feel like we have eye contact. I feel like we have eye contact. I haven't been typing on my keyboard. I believe that with a little bit more effort, we can make almost as close connections over these new mediums as over the old mediums. Now, of course, getting together in person has its own set of awesome dynamics, but I think this is good because someday there'll be colonies on the moon, and I'm gonna wanna form close relationships with those people, and I won't be able to just, you know, go down to Starbucks.

(Mark Porter at 00:38:54) And so I wanna challenge anyone who says you can't form close relationships over these new mediums and say, why don't you put a little bit more work into it?

(Joel Beasley at 00:39:06) Yeah. That's a big challenge you're issuing there. I mean, I know, one day, if my kid goes to college on the moon, I wanna be able to stay in touch. So I wanna talk a little bit about goal setting in general for you personally and also how you structure goals for your team as a leader. So I'm just curious, how do you structure your personal long term goals? What kind of time frame do you think in, and how do you measure those?

(Mark Porter at 00:39:40) So my long term goals are very, very simple, which is to have a wonderful relationship with my wife and children. Full stop. Everything else is there to help that. Now you might go, wait, he didn't mention work. My wife found out that when I retire, I retired once about twenty years ago, and she found out that I am not a pleasant person to be around when I'm not working. So part of me having a good relationship with my wife and kids is actually working. So, and there was a little bit of vulnerability there. My wife is probably laughing if she's listening to this. I review my goals regularly. I have a project in my to do list manager, and this is a bit vulnerable, called Better Mark. And in that, there's probably 70 to 80 items in that list, all from don't interrupt my wife to, you know, promote my people when they deserve to be promoted and all those things. And those things tickle me once every thirty days, ninety days, sixty days, whatever. So there's no particular cadence to them. But there is this constant reminder of Better Mark.

(Mark Porter at 00:40:47) Every single morning, there's a couple things from that project which have now retickled me on my list, and I decide, do I snooze them for another thirty days or am I actually gonna do something about that today? So that's my personal mechanism.

(Joel Beasley at 00:41:02) That's really cool. I think that's also, it sounds similar to the benefits of journaling, like when you're just writing every day, and it just keeps those things that you want to keep at the forefront of your mind at the forefront of your mind. That's awesome. That's a really cool tool. I might try that out myself.

(Mark Porter at 00:41:23) And I do it on the computer because then it reminds me. I don't have to go back and review my journal or anything. It reminds me. And some of these things pop up out of my journal, and I go, oh my god, I've literally not only not done anything on that, but I think I've backslid. And those are the ones where I go, no, I'm gonna double down and put more effort into those. Now in terms of the company, this is an area where I've evolved from, and I'll say some company names here. Oracle had the relentless pursuit of technical elegance and still has it today. There are a lot of unbelievable engineers producing great software at Oracle today.

(Mark Porter at 00:42:00) Amazon had a different point of view. Goal setting in Amazon was about getting stuff out there as quick as possible, cut some of those corners, get stuff out there, iterate on it. And Amazon's goals were about throw spaghetti at the wall repeatedly. And sometimes that had some bad outcomes where you're like, wow. Why do we have three things that are very similar to Elastic Beanstalk, as an example? Well, because three teams had a great idea. And there's advantages to that iteration. At MongoDB, we do something a little bit different. The company produces our fiscal year objectives once a year. And this year, they fit on to four pages, I think.

(Mark Porter at 00:42:40) All of our company objectives fit on to four pages. And then what we do is we tell the teams to look at those. And instead of inheriting them, like take objectives three B one and inherit that, and here's your objective, instead, read them together as a team, put them on the back burner, and then decide what you wanna accomplish this year. And then what happened is we had an all hands meeting where people said, well, yeah, but what if I wanna do something that's not on the objectives? Or what if I think one of your objectives is, shall we say, not so smart or not a high priority for us this year?

(Mark Porter at 00:43:17) And they asked Dave and I and they said, so should we align what we came up with with your objectives? And Dave, bless his heart, said, no, if you wanna do something over and above our company objectives, go for it. And if there's something on our company objectives that you think is not a priority that we thought was a priority, fine. We only ask you one thing: tell us about it so that we can understand where we went wrong in drawing up our company objectives. Now if that isn't bottom up empowerment, I don't know what is.

(Joel Beasley at 00:43:52) Yeah. That sounds amazing. It sounds like you have some great people at your company to really take advantage of that bottom up empowerment and make the most of it.

(Mark Porter at 00:44:03) Now the reality is there's probably a good solid 80% connection between the company objectives and what teams wanna do.

(Joel Beasley at 00:44:10) We don't wanna inflate.

(Mark Porter at 00:44:14) Right. Right. We're not taking the Google 10% to a 100%. That's not what's happening. But what is happening is it's different when it's someone else's idea. For those of you who have children, it is so different when they decide to go up to their room and do homework because they wanna get a better grade than you telling them, hey. It's after dinner. It's time to go do homework.

(Joel Beasley at 00:44:39) Right.

(Mark Porter at 00:44:40) The exact same homework might get done, but the attitude, feelings, and growth and quality of the product is significantly different.

(Joel Beasley at 00:44:50) Absolutely. And I think that also just comes back to, as we were talking about before, how working on increasing your employee happiness increases their productivity. Because when they want to be working on it and they're passionate about it, they're going to do better quality work and have a better time doing it. And then you're positively impacting their lives.

(Mark Porter at 00:45:14) Yeah. So people ask me what my goals as a CTO are, and I say my goal is to delight customers, fulfill employees, and respect our shareholders and stakeholders in that order. And if you structure a company like that, I have found a vast number of other prioritization decisions get made within that framework very easily.

(Joel Beasley at 00:45:40) That makes a lot of sense. That sounds like that makes leading easy. Just follow that.

(Mark Porter at 00:45:46) Well, yeah, then you get into the details of revenue and companies and customers and bugs and all these other things. But yes, it is kind of a north star that I like following.

(Joel Beasley at 00:45:58) Amazing. Well, before we wrap up, is there anything that we didn't get to touch on that we wanna make sure we touch on today?

(Mark Porter at 00:46:06) So I guess there's one thing I do wanna touch on, which is this concept of how companies should be working today, which is companies should have these small empowered groups where they know what they're doing and there's a connection to the customer. And leadership's role is to enable those groups to do what they need to get done. At the same time, of course, leadership's role is to guide and create psychological safety and all those things. And just because I'm a technologist, I have a very biased opinion that if you choose the right technology and you give your teams the ability to choose, all your teams don't have to choose the same technology. If you resist mandates from on high, be they technological mandates or, God forbid, even process mandates, and you let your teams have the empowerment and context and candor, you will find that most teams want accountability.

(Mark Porter at 00:47:12) And so what I find is the thing that I talk to a lot of CTOs about is they're trying to have their teams take accountability. And what we find is if you just step back and you give these people the freedom and the candor and the empowerment, they actually start taking accountability faster than you could have forced it on them. And so that's my parting thought for how to make a company successful.

(Joel Beasley at 00:47:36) Awesome, man. Well, I'm sure a lot of people listening might wanna come work for you. You seem like an awesome leader. Seems like a great place to work. Are you guys hiring? And if so, where can people go to find that?

(Mark Porter at 00:47:50) We are hiring like crazy. In fact, we have almost doubled the company during COVID, which proves that you could do a lot of things over Zoom and over remote. And we are hiring all over the world. For me, personally, I am hiring engineers in places as diverse as Berlin, Dublin, Barcelona, New York, Austin, Seattle, Vancouver, Sydney, Delhi, Singapore. I mean, that's just the list of places I personally am hiring.

(Mark Porter at 00:48:20) So yeah. And by the way, we take remote employees now too because of what we learned during the pandemic. So yeah, come talk to us. Maybe we're the right place for you. Maybe we're not. But yeah, come talk to us.

(Joel Beasley at 00:48:34) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn, or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.