The 3x CEO That Turned MongoDB Around

Welcome to the Logan Bartlett Show. On this episode, what you're going to hear is a conversation I had with Dev Ittycheria. Dev is the president and CEO of MongoDB, his 3rd public company. In this conversation, Dev and I discussed the importance of hiring, how to build an A+ culture, the power of self-awareness, and Dev's take on artificial intelligence, as well as the New York tech scene. A really fun conversation with one of the absolute best operators in tech. As a reminder, we do not do advertising on the show, but we would like for you to subscribe to this on whatever channel that you're listening to us on. Now, without further ado, here's Dave. Dave, thanks for doing this.

My pleasure. Great to be here.

So, I wanna start out in the midpoint of, I guess, your professional career, which is you taking the job at MongoDB. So, Mongo today, it's a juggernaut. I think everyone knows it in the public markets, but at the time of you taking the job, it wasn't quite the juggernaut it is today. What did you see in the business at that time that made you say, hey, this is a job that I wanna do?

Well, first of all, whenever you get a call for a CEO role, the first question I, you know, trained myself to ask is, what's wrong? Because no one makes a CEO change when things are going perfectly well. And there were a number, you know, when you help, you know, have a successful outcome and make investors money, invariably you get called for other roles. And I typically said no to a bunch of them because the problems were quite endemic in the companies that they had asked me to consider leading. I had been a VC for a while, for a couple years, and I had looked at the next generation database space and actually I looked at some competing investments to MongoDB. I ended up passing on those investments 'cause when I did my diligence, and again, this is a lot smaller scale, MongoDB still seemed ahead of everyone else in terms of developer momentum, mindshare, and even commercial traction. So when I got the call, I was intrigued. And frankly, one of the questions I thought to myself was maybe I have a chance to invest in MongoDB. And then when I met with the board and some members of the executive team and the founders, what I saw was that the product team was in pretty good shape, but I was dismayed at their go-to-market efforts and I was a little underwhelmed with the leadership that was in place. And I thought to myself, normally that would scare people, but I thought to myself, if this company is the head of the pack, And it's clearly got at best a B team. Imagine what would happen if an A team came in. And so as I thought about that, I got more and more conviction and I decided to take the role. And, uh, that's how I ended up here.

When you came in, you can't do it all at once. You can't change everything, uh, the second you come in. What were the first things that you went about changing?

Yeah, that's a really good point because anyone who's trying to be a change agent, you can't, um, try and fix everything all at once because you'll just fail. So you have to sequence things in terms of what you need to fix now versus later. So I took the approach of starting with a customer and working backwards into the core product because my instincts told me that the go-to-market organization was not very good and candidly quite dysfunctional. I remember I hadn't actually started and I got a call saying, hey, we have this important meeting with a customer, a senior executive at Verizon. And so I said, would you mind taking a, you know, a call because they're trying to set you up when you join to meet with this customer? So sure, happy to. And so I'm on the call with this account team and I could tell like the account team didn't really, the leader of the team didn't really have all the facts. So I was starting to ask the rep more and more specific questions. And finally I asked the rep, so where are you based? I said, maybe, you know, we could just meet for coffee just to get a little bit more detail, just so I could have a one-on-one conversation with him. And he said he's based in Atlanta. I said, how can a rep who's covering Verizon be based in Atlanta? So that was one of many examples of what I saw. So was some of the dysfunction at MongoDB. So I started basically working from the customer backwards and I said, as I fix the go-to-market and in particular sales organization, then the fidelity of the feedback I get on product will be that much more clear. Then I'll know what exactly I need to fix on the product side. So methodically, we basically, actually in my first 90 days, we did a big rip of a bunch of the salespeople because they just weren't very good. And the track record also showed that. Then I brought in a new CRO, I brought in a new CMO, and then 9 months later after I started, I brought in a new CFO.

So the core atomic unit of the product was mostly working well, and you had to make some changes along the way to make sure the product had the right fidelity?

Yeah, so what we realized, and I knew this going in, was that the read performance for MongoDB was very good, but there were some limitations on write performance, or people weren't really comfortable for using using MongoDB for write-intensive use cases, and we had to fix that. And the product teams and engineering teams were working on rewriting our storage engine, but that was a pretty big lift. And in the middle of all this, we got to meet the WiredTiger team, which is a bunch of ex-Berkeley DB guys who were very, very sophisticated database architects and engineers who had 20+ years in the industry. And they had actually had a storage engine that was optimized for both read and write performance. And so we got very excited and we were actually worried because some of the customers included AWS and a few other larger, you know, organizations. So we were nervous that that technology and that team could be acquired under our feet. And so we moved pretty quickly. The company didn't have a tremendous amount of cash, you know, even though it raised a lot of capital, it burned through a lot of capital. So we also had to do financing at the same time to fund that acquisition. But we were able to pull that off. And then the WiredTiger storage engine became the core storage engine for the product, which enabled us to really broaden our use case and, you know, be on the march to be a general purpose platform.

So this was 2014?

2014, 2015.

And, and so you're making plans to go public around this time?

Not yet. No. When I came into the business, the company had raised, was actually one of the first unicorns when unicorns were actually rare. And, but that fundraise was underwritten by a very aggressive operating plan. It was clear that the company had no chance of hitting it, which is why the board decided to make a CEO change.

And you reset the plan when you came in?

Yes. And for people, again, who are change agents, one of the things I also think is very important for people to feel like they're winning, and the plan was just so unattainable. The worst thing you can do is, you know, keep feeling like you're failing. So I went to the board and said, this plan is not realistic. Obviously I have the benefit of, of not the one who actually wrote the original plan. And I went back to them and said, here's what I, I think is a more realistic plan. The board in their wisdom agreed. And then once you have a new plan and then you start beating your numbers, all of a sudden, you know, you start people feeling like they have their mojo. Suddenly they feel like they're winners again. And you just start building morale and momentum in the business.

So when you joined, how many people were there?

There was roughly about 350 people, and then with the RIF, we went down to about 250 people.

Wow. So, so laid off about 100 people to come in and then slowly built back up over the course of, uh, what, how long did it take you to get back to 350 people or so?

I don't remember exactly, but my philosophy in the first phase was just, we just had to get our go-to-market execution sound. We had to be able to, you know, do what we say and say what we do. We had to be able to forecast the business, be able to then meet and exceed those forecasts. We had to rebuild how we actually prosecuted deals. You know, you've talked to John McMahon about the whole, you know, sales process at BladeLogic. So I had a lot of experience in that way. The first CRO was an ex-BladeLogic PTC guy named Carlos Dellatorre, who helped me kind of really restructure and put the basic foundations in place. And then lo and behold, the business started, you know, growing very quickly.

One of the knocks on open source up until that point was that it was very difficult to monetize. Red Hat had been the one that had been able to make it and become a big public company, but there weren't a litany of examples of open source companies in the public markets that have been able to successfully scale in a meaningful way. How did you think about that, the trade-off between the ability to monetize, the community, all of that stuff when you came in?

It's a great question. And frankly, when I told my friends and people I trusted I was contemplating taking this job, they thought I was crazy. They said, first, a database company in New York, That's crazy.

When was the last database company that went public before you? It was 25 years.

25 years.

Yeah. Yeah.

So the second thing was like open source, like there's, you know, who's made money in open source? And then just the database space itself, forget about New York, there was a lot of, you know, next generation database companies that died on the vine trying to be the next big Oracle killer. So all the kind of conventional wisdom was against that. And the big one, what I worried about was how do we monetize open source? Because the traditional open source model is, you have to define the paywall between what's free and what's paid for. And to some degree, it's a Faustian bargain, because if you give away a lot of features to drive adoption, it's very hard to monetize. And if you don't give away enough features, then you don't have a lot of adoption, so there's not a lot of installed base to then go monetize. So you're kind of trapped in this Faustian bargain. One of the things I realized in actually watching AWS is that they were monetizing open source as a service really, really well, because you were no longer defining a particular paywall, You're defining monetization based on usage. So that fundamentally changed the paradigm about how open source technology was to be used. And so essentially we started recognizing that that had to be our long-term future, but you just couldn't go there overnight. Now, luckily we had been investing in management tools because that was the existing way we were monetizing the technology. Whatever the developer needed to build applications was free, but whatever you needed to kind of mon— you know, monitor and manage and back up your infrastructure was paid for. So we were starting to build tools, which ends up being the ingredients for how we actually rolled out our cloud service.

What came first, Mongo Atlas or the license change?

MongoDB Atlas.

MongoDB Atlas.

Yes.

So can you talk a little bit about that? Because you guys were one of the pioneers in coming out with a cloud-first kind of open-core model around that, right?

Yes. This was pre-Snowflake being popular, pre-Confluent, pre-Elastic, pre-a bunch of other companies trying to roll out cloud services. A lot of people thought we were crazy. A lot of people thought, how is it that you're going to partner and compete with the hyperscalers because we just didn't have the capital to go build our own data centers and then try and get all developers to come to us. We had to leverage the existing infrastructure that the hyperscalers have built, but they also offer their own competitive database offerings. So a lot of people were incredibly skeptical. One of the things that changed with rolling out a cloud service is that we felt we were really talking to the people who loved our product because the existing monetization model was while the developers adopted MongoDB, the people who bought our proprietary software were the ops folks because they were trying to solve a DevOps problem. They really viewed MongoDB as a relationship of convenience. Developers had a relationship of love. So for them it was just, oh, I guess if we have to deploy MongoDB, I should buy your tools. So it was always a very painful engagement with the customer. But once you start dealing with the development teams and saying, you know, you can get out of the world of all this undifferentiated labor, you don't have to worry about provisioning, configuring, and managing, and backing up your infrastructure, we'll take care of all that for you. All you can focus on is what really is meaningful to your business, is building amazing apps that transform your business. That suddenly got people's attention. And so what was also interesting is the launch of Atlas forced us to build a self-serve business, because initially we, you know, only offered on self-serve where we basically, you know, with a credit card, you could go provision a cluster at first AWS, then we rolled out it, rolled it out to GCP and Azure. And that also enabled us to start acquiring customers in a much more frictionless way. And even today, when you look at the Atlas business, the majority of our customers are quote unquote sales sold, but the origin of those customers, the majority of which are still self-serve. And that's a very interesting dynamic and in some ways a virtuous circle.

What was the hardest part about getting that going? Was it, was it the getting the sales reps to, to sell the product? Was it figuring out the pricing model? Was it actually building the product itself to service it?

The way we framed it was building a startup within a startup. And then we were very emphatic that this, we could not fail. And so from the board on down, this was like a very viewed as a very strategic imperative. And one of the challenges when you're starting something small, you know, when we went public, Alice was like 1 or 2% of our business. So the numbers really didn't matter that much, right? So consequently, it's very easy to ignore this little thing you're trying to do when you focus on the core business. So one of the other things I did was I disproportionately incentivized the exec team on the performance of our Atlas business disproportionately to the scale of the Atlas business because it was so important to make sure that they had mindshare. The other thing that we also really focused on was having a clear single-threaded leader who was now, was a guy named Sahir Azam, was now our Chief Product Officer. He had this unique ability of being very good on the product and technology side, but also really good in front of customers and, and kind of knew how to preach the gospel of Atlas. And changing behavior's hard. I mean, looking back now, it says, wow, this ended up being a great success. But like any success story, when you zoom into the, up into the right line, there's a lot of jagged edges. And in getting the sales force to change behavior because they were, they knew how to sell the on-prem product and recognizing that your primary customer's no longer the ops person, but now it's the development team. Getting to understand you have to sell the total cost of ownership, that getting to understand what is the true value proposition of a cloud service. takes time and you just gotta be, you know, maniacal about that execution and just constantly train and enable the sales force to do that. And that takes, that just didn't happen overnight. So we started with self-serve, then we migrated to kind of the SMB space and high-tech organizations who are more inclined to use Atlas. And then later we went into the high end of the enterprise segment.

Were you spiffing the reps? 'Cause I assume the dollars between each, the long-term value of Cloud Atlas and obviously the equity value it's created has been pretty significant, but The dollars upfront of selling Mongo on-prem, I assume, had to be more. Is that how you kind of did the incentive alignment?

It was similar in the early days because we paid salespeople on commitments on ACV. But over time we realized that was a mistake with our cloud business because a lot of the apps being rolled on Atlas were new apps. And so customers didn't really know how much would the consumption be, how big would the app grow, how many users would it have, how much data would be consumed. And so there was this a lot of friction to force a customer into a commitment prematurely. So over time, we changed incentives to encourage customers just to get on Atlas. And then once they felt like they had clarity on the growth trajectory, then they could come back and get a better discount based on some volume commitment. And we've constantly iterated on that, you know, sales incentive. In fact, now over the last 4 or 5 years has changed all the way. to where we're all in on consumption, but it started by a more traditional incentive mindset.

Were you worried at all about cannibalizing the existing business, or was it clear that this was just gonna be the long-term future when you came in?

There was a little bit of worry, but it was clear, like, our business wasn't that big that we had this, like, large installed base. I mean, remember, I joined the company when there was about $30 million revenue. When we filed our S-1, we were doing a little over $100 million revenue. And so it was not a huge business. And obviously today, now we're roughly about a $1.7 billion run rate. That's wild.

Now, now the other big change I think that was notable that you guys helped pioneer was a license shift. And so for people that aren't nerds in the open source world, can you maybe talk through the difference between AGPL and SSPL and what was a fairly controversial decision at the time and how you went about making that?

Right. So when you looked at what the cloud providers were doing, what they were doing was basically taking the free versions of very popular open source projects, MySQL and a bunch of other examples, Postgres, et cetera, and basically plugging those technologies into their cloud and offering as a service. And they were making money hand over fist on it.

This is Amazon and Microsoft and Google and all of them are—

Correct. And so what we were concerned about was that the hyperscalers or someone else might do the same with us, what people in the industry call strip mining. And AGPL, it has more restrictions than say GPL or the Apache license. But there's still some ambiguity in the language. And what we said is we've got the sense is as our success started to take off, we got the sense, you know what, someone's gonna try and test how strict this license is. And we didn't wanna find ourselves litigating this in court. So we made the decision that we need to come out with our own proprietary license, which adhered to all the principles of open source. You know, you can have access to the source code, you could modify the code, you could obviously distribute the code. But what you couldn't do, or if you decided to do, was to offer MongoDB as a service. You had to open source all the extensions you made to MongoDB as well as all the underlying infrastructure to offer that service. And we said, that seems very reasonable because if you choose to do that, you just need to give it back to the community. It was candidly quite a contentious discussion. We tried to socialize this and get the OSI, which was the body that approves open source licenses, and they were up in arms and said, We don't, this, this is not real open source. And a lot of people said, oh my God, we might risk our adoption because MongoDB is quite popular and our adoption might dry up because people will not want to use a non-sanctioned open source product. And I thought about this problem and I thought to myself, if you're a developer in Shanghai or Mumbai or Palo Alto or New York, yes, so long as it, you know, has remained consistent to the open source principles, are you really gonna care that much whether or not it's an OSI-sanctioned license versus a license that enables you to do what you want to do, but more importantly, the product is the best product to solve the problem that you're trying to address. And the bet was that developers wouldn't care about this. And, uh, and ultimately that bet paid off, but there were definitely some gnashing of teeth when we made that decision.

And now a lot of people have followed suit, or other people's using actually—

Yeah, a lot of people have used SSPL. There's a derivative called BSL, which kind of was the inspiration based on SSPL, where there's more protections around people strip mining open source technology.

Which is basically, I mean, one of the beauties of open source is that it allows for distribution. It allows people to use it for their own intent if they want to service, if they want to use it however they see fit. But if you want to commercially use the product, you have to be willing to give back. And so the only people this is really hurting, I think, are the big cloud providers that are trying to offer it as their own. Is that fair?

Or regional cloud providers who also want to do something like that.

Yes.

Yeah, and our belief was that when you think about what's important for the end user, the end user is not going to care. So it's only people who have mercenary interests are gonna, you know, be annoyed about this. So that doesn't bother us. And what, you know, the whole strategy was we wanna benefit from the virality and the distribution of open source while building a moat like a typical software company. And that essentially was our strategy. And ultimately that strategy has paid off.

And this has allowed a lot of open source, open core businesses to now actually monetize and be able to build themselves into big companies as well.

Exactly.

I wanna shift gears a little bit. Is this your 3rd or 4th company as CEO?

3rd.

3rd company as CEO, 3rd public company as well, right? What do you view as the job of the CEO?

I think there's different definitions for different types of CEOs. In my definition, and I'll give Mark McLaughlin from the old CEO at Palo Alto Networks, he kind of informed my thinking around what a CEO should do. And the basic point is that I can do 1,000 things. Like, I can do this podcast. I, you know, I do a lot of customer meetings. I do a lot of, employee meetings. I do review quarterly, have quarterly review sessions and QBRs to reviews, to attend sales forecast reviews, et cetera. But if I don't do 3 things well and I do another 997 things well, I failed. And what are those 3 things? First, what is the company strategy? What are we trying to do? Where are we trying to go and how are we trying to get there? 2, do I have the right people, especially at the executive level, to go execute on that strategy? And 3, have I removed all the obstacles, whether it's resourcing, whether it's culture, whether it's organizational alignment, to make sure that we can actually are set up for success? So I can do all those other things, but I don't do those 3 things well, in my mind, I failed. And so to me, that's essentially what I think is intrinsic to my job.

At some level, being CEO also means being like a super head of HR and recruiting talent and being able to get people within the org. How do you think about that and managing a team?

Well, I tell my team and I tell actually everyone at the company, we're not in the database business, we're not in the software business, we're in the people business because people are the means to an end to everything. And invariably, all the issues we're dealing with, you know, what's going well, what's going sideways, what's going really poorly is all tied to people. In fact, I had an offsite with the leadership team a couple weeks ago and I did a review of all the projects that we've done really well. and all the products that have struggled. And what was the root cause of those is that we didn't have what we call the right DRI, the directly responsible individual who had the skills and experience to either lead those projects, or in some cases it wasn't clear who the DRI was. So there was shared accountability. And as Jeff Bezos says, if you want something to fail, make it their part-time job. And so to me, having the right people in the right roles is so critical to everything. And so a lot of people, And a lot of organizations have this aspiration, I wanna do X, or I wanna go Y. That's the easy part. It's the day in, day out blocking and tackling of, you know, having the right team, focusing on what good looks like, measuring progress, inspecting deeply on how things are going well, identifying issues, whether they're people issues, alignment issues, other problems. And just, you know, doing that day in and day out is what really differentiates companies that execute well versus companies who Aspire to execute well, but just don't.

So every strategic initiative you guys have internally has a DRI that's responsible and accountable for it?

Yes. And, and that's a hot button for me. I mean, there's times when it's not clear and we say we need to have identified the right DRI. So that'll be like step one. And the, the role of DRI is to define, i.e., what does good look like in what timeframe? What is the plan to get there? And then what are, how do we measure progress? And then ultimately, That person or that associated team will then come and report. If it's an important initiative, they will come and report to me and the exec team on progress. And I would candidly say we've done some of those really well, and some of those have been a little haphazard, and we're trying to sharpen our execution there to become even better.

I've heard you say early in your career that you didn't view vulnerability as a strength, but now it's become something that you're proactive about and being willing to say that you don't know the answer to something when, when that's the case. Can you talk a little bit about that?

Yeah, I think, uh, for people listening, you probably have a lot of founders and first-time CEOs who are listening to this podcast. And I can tell you that most people go through massive imposter syndrome. You know, the investors wire them the money, now there's a team in place and you're like, holy shit, you know, this is real. And if you've never done it before, this, it's not like you can suddenly, like suddenly magically learn everything overnight. And so when I was a first-time CEO, I felt this enormous pressure to be the all-knowing on every facet of the business, whether it's product, marketing, sales, finance, et cetera. And over time, I, I realized I was really frustrating my team because I felt like I had to have my imprint on every decision, and I would micromanage some decisions, or I'd come in over the top and claim credit to decisions that other people had already come up with. And it was getting to be dysfunctional. I could sense that I was not being very effective. I could sense I was frustrating my team, and I had a, an epiphany one day. And said, I don't need to have all the answers. What I need to do is one, have the right people around me and be able to ask good questions and make sure that the most important things are being done well. And what's interesting is I also realized like, you know, being in a meeting and being the village idiot in a meeting is actually very powerful because if I ask a question that some people perceive as a dumb question, like, hey, I don't understand what you're saying, or this doesn't make sense to me, you could see the people in the room just relax and say, thank God Dave asked that question because I had the same question, but I didn't wanna look stupid in front of my peers if I asked that question. And the problem with a lot of what holds people back is shame, right? If you think about an innovative culture where people wanna, you know, experiment, and by definition it's not an experiment if you— it's a guaranteed success. So some experiments are gonna work and some are gonna fail. And so if there's a high If, if shame is very toxic in your, in your culture, then by definition you're not gonna take a lot of risk. And so being more vulnerable is really a strength because it enables people to, to really take more risk, talk about real issues, not talk about some, you know, highfalutin stuff, deal with problems as they come, and acknowledge that we don't have all the answers, but together we can, can get those answers.

How, how does that tie into being a student of the game and not a master of the game?

So that saying comes into a philosophy I have around leadership, which is like, as your leaders, you constantly have to adapt. How I was a CEO at BladeLogic in 2001 and how I am today are 2 very different people. And I think one of the lessons I've learned, and we've gone through lots of leadership changes here at MongoDB as we scaled from a $30 million business to a $1.7 billion run rate business, is that the business needs different styles of leadership at different stages of growth. And You know, obviously managing 250 people is very different than managing close to 5,000 people. And when I see leaders fail is they don't adapt because they can't. And one of the signals for me on how effective leader is gonna be is can they introspect on what's going well, what they're doing well, and also what's not going well? And then can they act on that introspection? A lot of people can do the first part where they can introspect, but a lot of people just can't adapt and evolve their style because they realize the way they were doing things is just not working anymore. I mean, candidly, right after we went public, I had to, I parted ways with our CRO. And so that's a pretty, you know, if you think about it, pretty frightening thought. You're a newly minted public company and the quarter after you go public, you part ways with your CRO. And I became the interim CRO until promoting our existing CRO, who was Cedric Pesche, who was running Europe at the time. And he's done a fabulous job. But one of the reasons is that leaders just can't adapt as the business is growing. And so, and so being a student of the game is meaning that you're very curious and you're also very coachable, right? But you're curious because I wanna understand what I'm doing well, what more I need to do, how I need to adapt to different situations, domains, you know, and, and experiences. And then have the mindset that I constantly have to learn and grow.

How does self-awareness tie into that? And also the, the Steve Wolsky 2 circles point.

Yeah. Yeah, so for those people trying to figure out what that meant was, I remember I was having a discussion with Steve Wolsky, who was the chairman and CEO of PTC and—

Mentor of yours on the board.

And mentor of ours, yeah. So when I joined, when I started BladeLogic, I'd never worked at a software company and obviously I'd never been a CEO of a software company. So I very, was very clear that I had a lot to learn. So I went to my board and said, who's the best software CEO in Boston? And they all said this guy named Steve Wolsky. They said, yeah, but he eats nails for breakfast. Here's his number, but good luck. So I kept pounding the phone either every week or every other week. Finally, he returned my call. I met with him and for some reason we clicked and he decided first to be an advisor, then later became a board member, and then ultimately chairman of BladeLogic. So one day we're in, you know, having a debate and discussion about a person, and then he went to the whiteboard and drew 2 concentric circles and he says, Dave, this is the meaning of life. And I looked at those 2 concentric circles, I was like, Target? What's he talking about? And he goes, what he said was, the outer circle is how people believe they really are, who they are. The inner circle is really who they are. And the point he was saying was that people always have an overinflated opinion of themselves. Now it's fine because there's always gonna be some gap between your own self-perception versus what others perceive of you. But when that gap is really wide, that's when real damage can be done. And, you know, one of John McMahon, who I've worked with on a couple companies, one of his best lines in terms of assessing how self-aware someone is, is he asks people, what do you think people say about you when you leave the room? And the most self-aware people can be quite on point about what acknowledging their strengths and weaknesses. The most self-unaware people have no clue. They just have a completely different picture of who they are. And what I've found is that the best leaders are incredibly self-aware. Why? Because they can read the room, they can see what messages are landing, what messages are not, how they have to adapt their style. Maybe 8 out of 10 people are bought in, but there's 2 people who look pretty grumpy, are not happy. So he or she knows that they need to go talk to those 2 people to figure out what's going on with them and also, also understand their own biases, what triggers them, and also what they may kind of have blind spots to. And so being self-aware is incredibly important to be an effective leader.

Hey guys, Rashad here.

I'm the producer of The Logan Bartlett Show and wanted to take a quick second to make an ask.

We are close to 10,000 subscribers and are trying to get there by the end of the year.

If you're enjoying this conversation and these episodes, please consider subscribing to the YouTube channel.

Now back to the show. I've heard from people that you work with and even in prep for this that you all have built a very transparent culture here. How do you go about building transparency within the culture and honesty and all of that?

I think it's also tied to vulnerability. One of my pet peeves, I started off my career at at a larger company. I started, I came outta engineering school, I went to AT&T and Bell Labs division. And AT&T had some amazing people, but what the culture there was very passive-aggressive and it's quite endemic. When BladeLogic got acquired by BMC, the culture there was very passive-aggressive. And to me, passive-aggressiveness is a form of duplicity. You know, imagine you're in a meeting, the senior leader's running the meeting, you're, they're debating and discussing a topic. The senior says, I think we should do this. And everyone nods politely and say, yes, that's the right thing to do. The meeting ends, everyone walks out of the conference room, and then they roll their eyes and say, that'll never work. That to me is a form of passive aggressiveness. Like, I wanna create a culture where we can have fierce conversations and debates constructively about what to do or what not to do. But at the end of the day, the best idea wins, not the most senior leader's idea wins, right? And that is amazing because it creates a culture of meritocracy. So no matter who you are, if you have, you know, an insight, that you think is incredibly valuable, you should feel comfortable sharing it. And people will buy in if they think that that idea has merit. And so, that's super important. And also, transparency also means talking about the bad stuff. A lot of companies, and actually when I got here, the joke was the management team before me would only talk about good things, would never talk about bad things. And I always found when I was a younger employee that it insulted my intelligence when senior leaders kind of basically, you know, communicated in a propaganda kind of way. Like, I was like, okay, come on, that's not really true. And I think most people can see right through you. And so I always felt it's really important to build credibility is to really talk about both what's going well and what the real issues and problems are in the business and how we are gonna talk about them. Because once, what was interesting, and I do that with the board as well, and I mentor younger CEOs saying, when you tell an experienced board member that everything is going fabulously well, they either will immediately think one of two things. Either you don't know what you don't know, or you're lying to them. Because every company, even the best-run companies, have something blowing up somewhere, right? And so I start my meetings always talking about problems. Here's the issues and challenges I'm struggling with. Here's what's going on, team dynamics. Here's, you know, people I'm worried about. You know, when the team comes in, this is where I encourage you to probe, blah, blah, blah. And what's interesting is the more My commitment to the board is they should— will typically never hear any bad news. You know, they'll typically hear bad news from me first. What it does is it disarms the board because the board never feels like I'm trying to hide information, and then they're leaning in to help me. And in fact, the board has commented, I give them a lot of access to people, multiple levels below me. So I have teams come in based on, say we're talking about a particular project or a particular function. So they love that they have visibility many levels, layers into the organization. For, you know, one, more transparency. Two, they can see the, the depth of our bench and get a sense of, you know, the culture that we have. And I find that incredibly powerful.

I spoke to one of your former board members and he said that you are one of the best people he's ever worked with on doing what you say you're gonna do and holding people accountable so that they actually execute on whatever said is actually gonna be done. How do you go about building a culture of accountability and actually making sure people follow through on what they say they're gonna do?

This is tied to something else. I always believe bad news travels very slowly up the organization, but very quickly down the organization. Good news will find me anywhere. I could be on a beach in the South of France, I could be in Hawaii or Tahiti, and good news will find me. And, but bad news I have to go looking for. And so whenever I hear bad news, I assume, immediately assume 2 things. One, I'm the last to know. And 2, it's far worse than what people are telling me because invariably people always modify or shave a little bit of the truth to be a little bit more diplomatic. And in, you know, in a simple example would be, you have a customer who's threatening to throw you out. The sales team tells their sales manager, we have a problem at Acme Company, you know, over multiple layers. The way it comes to me is, oh, we're dealing with a slight problem at Acme Company, but then 2 months later the customer churns and you're like, how the heck did that happen? Now we don't do that here, but that's an example of what happens in most companies. So we try to really encourage sharing of bad news. And we try not to shoot the messenger. Sometimes we're, you know, some people are not good at that, but that's really important because you can't get people to share bad news if they feel like they're gonna get punished for it. And then what that also does is that it elevates problems quickly. And I always believe that people don't perform, always perform to what you expect, they perform to what you inspect. So if you have a high culture of inspection, how's this project going? What's happening in the forecast? what's happening with that person or what's happening with that team, you end up invariably finding out what's going on. And the more inspection you have, not micromanagement, inspection, and you do part of your operating rhythm, the more quickly you can identify problems. And so, and this is back to the DRI thing. Like if you have a good DRI who's very clear on what good looks like, has buy-in from key stakeholders, and you're clear on the measurements, then when they come and report, it's very easy to now report on progress against the metrics that we think we defined as success. And when things are, you know, say falling behind plan, then you start escalating that and saying, I have a problem, you know, we need to fix these issues.

Feedback loops, keeping those very tight. It's super important with companies in general, but certainly fast-growing companies so that you can be held accountable to what you say you're gonna do and also be able to iterate pretty quickly. How do you go about keeping feedback loops tight within Mongo?

I think feedback is a gift. I think in every facet of life, feedback's important, whether it's feedback in your personal life. If your partner's annoyed at you, you wanna hear that feedback because then you don't know what's irritating or upsetting them. And then in the business side, the shorter the feedback loops, the more responsive you can be, especially to customer needs or market opportunities. You know, and the classic example is look at government functions. The feedback loops are very long. Imagine going to the Department of Motor Vehicles. You know, you wanna pull your hair out because they're not that attuned to customer feedback. And so to me, feedback is very, very important. And that again, it's created by a culture of high trust, being comfortable sharing bad news, having positive intent, and then actually acting on it. Because the worst thing you can do is give feedback and no one does anything about it. And so then you say like, this company doesn't care, or this person doesn't care. So you have to have a bias to action. Now, sometimes you can say, I hear you, but this is not as important as some other things we're trying to do, and we're gonna sequence this later. And make them understand that in the overall scheme of things, it may not be as important as you think it is, but it's important to have that discussion and align on what to do now versus later.

You guys maintain hybrid as a work environment today. How have you thought about that? How do you make it work?

Yeah, so I don't believe— well, what's happened, especially here in New York a couple years ago, there's a notion of quiet quitting, or people believe that anyone who's working from home is not working as hard as someone in the office. I don't believe that. I think that, you know, how the productivity of someone is defined by how aligned they are to the mission of the company, how aligned, how clear are the objectives of what they're trying to do, and how closely, you know, how well they're held accountable. And so I also, when I talk to employees, they value the flexibility, you know, in a world where the boundaries of when work stops and when your private life, you know, begins in the day is now blurred, right? So, people value. I had an employee tell me, the most important part of my day is being able to pick up my child from school. That's a very important moment for me. But this person works incredibly hard and is a high performer. But that flexibility, you know, makes her much more committed to MongoDB because she has that flexibility to be there. Other people love the fact that, hey, in the middle of the day, I've gotta go see the dentist or have a doctor appointment or take care of an errand. Now, we do also believe in the importance of in-person meetings. But I think, you know, it's not like people are talking to each other every minute of the day. There's times of this burst of activity, and then you come in to calibrate whether it's a QBR planning session, you're kicking off a project, or you're coming in and assessing the state of the project. So I don't think you need to be in the office 4 or 5 days a week. I think the toothpaste is out of the tube with the pandemic. And I think it's the way you hold people accountable is through their leadership. And if you have a high bar and high standards, you can still drive high productivity even if people are working at home or in the office.

We touched on, you did a RIF when you first got to MongoDB, but during the pandemic and when everything kind of reverted back over the course of as interest rates went up, you did not do a broad-based RIF. And I think philosophically you're against RIFs in general, not for some moral reason, but because it masks a bunch of performance and management-related considerations. Can you talk about that?

Yeah, that's a good one. I think, I think RIFs have a place if there's suddenly some structural cost structure problem you have in the business. Imagine if 50% of your customers disappeared overnight. There's no amount of performance management that can right-size the business quickly, and you have to make some hard decisions. But I, the reason I am allergic to RIFs in general is because to me, And this happened here at MongoDB when we got a sense in 2022 that the world was changing and, you know, and things were gonna become very different. A lot of people came to me and said, why don't you just do a RIF? You know, that'll be so easy to do that. And we're, you know, we'll be all good and it'll probably be even more quick and more efficient than just doing this performance management process. And what I said to them is that, but you're not teaching anyone any muscles, right? And we're not teaching people. One of the biggest weaknesses of new managers and even existing managers is knowing how to hold people accountable. And I have a 3-step process on how to hold people accountable, but we, I'll tell you that later if you're interested. But we want to develop the muscles of knowing how to hold people accountable. And what was interesting is that I had people who came up to me after the process and said, you know what, Dave, it was surprisingly easy to find the bottom 5%. And I said, what did that tell you? It said that either we hired the wrong people or we didn't develop them, but we clearly had a problem. And it was the impetus of me pushing you is you caused you to deal with that problem. You weren't dealing with that problem proactively. And that there in itself is a problem. And we need to be much more proactive in dealing with performance issues because the best people get very frustrated when they work with people who are either not as committed or not as competent as them because now you're actually penalizing all the good people who are working hard to cover for the people who are not producing at the rate they should be.

Now I wanna hear your 3 steps for holding people accountable.

Yeah, so the first step is you gotta be very clear on what you want, right? And so, you know, for a project, for the role, in this period, whatever, you gotta be very clear, here are my expectations. And so a simple example would be, say, I expect you to send me a report every Friday on the week's activities. I'll just make a trivial example. And the first Friday you don't send it to me. And then I see you on Monday and say, hey, where, Logan, where's that report? He goes, oh yeah, I forgot about it. I'll get it to you. And I'll, you know, and then you send it to me and I go to you and say, Logan, listen, I may not have been clear why that's important to me, but I use those reports to really understand what's going on in the business. You and your team play a really critical role and it's not just makeup work. This is really important to me. So the, what I'm really doing is I'm making the prompt That was my fault in not clearing, making clear to you what the importance was for why I'm asking you to do this. And then I say, now are you clear, Logan? Does everything make sense? And you go, yes, I got it. Now the next time you forget to send me that report, now I can hold you accountable. So you can't hold someone accountable if you don't do steps 1 and steps 2. So most people get terrified of holding people accountable because one, they're not clear on what they want and if they've not been giving clear feedback on when there's been missteps. And when you don't give feedback, you're basically sending message not just to Logan, but to everyone else. You know, what I want is not really that important. There's not a really a culture of discipline. I am okay to let people cut corners. And that by itself is sending a message that maybe this is not as a high-performance organization as it is. And so going to that 3-step process, at least for me, makes it much more easy to, to hold people accountable.

I've heard you say that recruiting is like pipeline management. Once you stop it, even for a bit, it dries up. How much of your time do you spend recruiting today?

Today, not as much. Obviously, for senior-level recruiting, I spent a lot of time. We just hired a new CTO, so I was obviously intimately involved in that recruiting process. And I was pleased that I actually had beat my own ambitious goal by a month. But that's a different subject. But obviously recruiting, it all starts with recruiting. And If you can't hire the best people, then nothing else really matters. In my mind, a leader has to essentially do 3 things. One is recruit the best team possible. 2, develop them to get them to do what you want them to do. And 3, make sure they consistently meet and exceed their commitments, right? So recruit, develop, and execute. But it all starts with recruiting. And, you know, I think McMahon has said this before, if you hire mediocre people but do a great job on development, and really monolithically focus on execution, you'll still have a mediocre outcome. If you hire great people and do an okay job on development, an okay job on inspection, you can still have a pretty good outcome. So it all starts with recruiting. The point about the pipeline is that like a sales pipeline, a recruiting pipeline dries up pretty quickly. So you're talking to candidates, you're screening candidates, but then if you say, you know what, I'm not going to put focus on recruiting, those candidates will slowly wither away and go somewhere else. So then you say, oh my God, I need to hire 100 people next quarter. You can't suddenly like magically produce 100 candidates, 100 qualified candidates very quickly. So constantly being in the market and talking to people, even if you don't have roles to fill, and getting a sense of who's great, who's out there, you know, selling the message and the value proposition of MongoDB is important for us because we're planting seeds. Sometimes we need to harvest those seeds very quickly. Sometimes we're planting seeds because we know In the future, we will want those people to consider joining us.

One of the things I heard you say in your interview process is that you inspect how thoughtful everyone was in switching between jobs. Why is that important? How do you go about thinking about it?

To me, the most important professional decision you can make is what company to go to, right? So, so when I look at a resume, I try and understand why did they go from Company A to Company B, or why did they even start at Company A? Why did they go to Company B? And then maybe C or D. I'm trying to understand the decision process. And what I'm really trying to assess is how thoughtful were they in making that decision to go from company A to company B? Because as I said, that's a very, very important personal decision for that person. And if that person is pretty cavalier, oh, I followed my boss, oh, I got a call from a recruiter and they offered 20% more, then I'm thinking to myself, you know, okay, those might be interesting signals, but that's not a very thoughtful process. And then I'm thinking to myself, how thoughtful are they gonna be when they're in that job making day-to-day decisions about what products to build, what marketing programs to execute on, how to prosecute, you know, sales deals, et cetera. And so that to me is a really high-quality signal about the kind of person they are. Whereas conversely, if they're incredibly thoughtful in saying, I was really happy here, but I saw this new emerging trend, I was really intrigued by this new technology trend. I talked to 5 or 6 different companies. Of those 5 or 6 companies, this company seemed the most interesting. I cold-called them, got a bunch of meetings, and then they ultimately offered jobs. And now that's a person who's incredibly thoughtful.

Mm-hmm.

I automatically assume if someone's been in a job for 2 years and less, they failed. Unless there's clear evidence that there was another reason why they left. You know, I either got married and had to move to another city, or there's some personal event in their life, or the company got acquired and they shut down that operation, whatever. Why 2 years? Because in most companies, it takes about a year to figure out that someone's not working out, and then another year to get rid of them. So, if you've been at a company for less than 2 years, you know, unless you can convince me, clearly convince me why, I've automatically assumed you failed.

Any favorite interview questions or things you try to tease out in an interview besides the thoughtfulness by which they switched jobs?

Yeah, I would say understanding both why they switched jobs. The other thing I like to probe on is, Give me an example of something you're really proud of. You know, what is what is a really proud accomplishment? And they'll tell me they closed this deal, they got this product out the door, blah blah blah. Then I'll start drilling in and tell me more and go into excruciating detail. And if they have the details at their fingertips, that tells me they were directly involved. If they were like a tertiary team member or some project that was successful at a company, then very quickly I can figure out that they weren't really involved, but they were just you know trying to. essentially get credit for that, you know, that project or that initiative that the company undertook. So that tells me again how intimately involved they were in those, in quote unquote, their most proudest moment, right? If it's your most proudest moment, it's gotta be something that you should be directly and intimately aware of.

If a job opens up internally and you have an internal candidate versus an external candidate, obviously you have a disproportionate amount of information about the person you've worked with in the past and you're comparing them to someone externally. How do you think about evaluating those 2 people for the job? And how do you think about discounting or maybe factoring in how much you know about the internal candidate versus the external one?

Yeah, so just stepping back, I always, and with the thing I've said here at MongoDB, and I said at BladeLogic, was I want people to come here to build a career, not to come here for a job. But the problem, here's the problem that most leaders run into, is that they have their own existing team, now they have a job opening, You know, Joe or Sally are interested in that job, but you have a very nuanced opinion of them because you see what they're good at, but you also see some of the things that maybe they're not so good at in some of the wards. But it's a very nuanced perspective on Joe and Sally. Meanwhile, John shows up with a pristine resume, you know, comes in, presents the best sense of him, of himself. And now all of a sudden you're like, wow, John's got all these credentials. He's got this track record. He's got all these results. Maybe I should hire John. What happens is you end up hiring John because you have an asymmetry of information. You only see the good stuff about John, but you have a much more nuanced view of Sally and Joe. And then 6 months later you realize, well, you know, John can't, doesn't walk on water either. He's got things that he's good at and he's got things that he doesn't good at. But what you've done is now you've demotivated Sally and Joe. And now all of a sudden they say, maybe this is not the place for me. Now all of a sudden they say, maybe I should contemplate going somewhere else. So I, I'm not suggesting that you never hire from the outside. Of course we've hired from the outside, but you wanna make sure your people inside the company, especially the people who are performing, are given their fair shot for growth opportunities. You, what you also don't wanna do is just have blind spots and say, I'm only gonna, you know, promote someone internally. You wanna make sure that you assess the talent pool in the marketplace. And that to me is the best way to really make the right decisions for the business. But ideally, if push comes to shove, I'd much rather promote within because it creates a meritocracy. You retain the culture. And you basically know what you're getting far better than anyone from the outside.

In a fast-growing company, uh, the, the slope of the business oftentimes will outpace the slope of the individual in that role. How, how do you make decisions about if someone's been good for up to that point in time, but it is time to maybe move on and bring on someone from the outside? How do you think about the, that, that balance and trade-off?

So my philosophy on that is you can usually fool the people above you. You can sometimes fool the people around you. You can never fool the people below you. And the biggest tell for me if a leader is not scaling is how frustrated is their team becoming? Are good people starting to leave? Is the quality of the new people that the leader's recruiting is now no longer A's, but now like B's and B-minuses and C's? That to me is a huge tell about whether or not a leader's scaling because the people who work for you clearly know how effective you are, clearly know the quality of decisions you're making, clearly know if you're being a hindrance. or an asset in terms of enabling them to get their jobs done. And so that will show up very quickly to them. And so that to me is the best tell. And in fact, when I joined MongoDB, one of the first things I did was review all the organizations and I tried to understand, you know, who was in these teams, what the level of turnover was, and the quality of the people in those teams. And that gave me a great map about where the problems were in the organization. And that also informed my decision of where to focus first.

Mm-hmm.

And I think that just remains. And it may seem awkward to say this, but we've gone through many leadership transitions. I've been through 3 CMOs, I've been through 2 CFOs, I've been through 3 CROs, I've been through 2 chief product officers, I've been through 3 CTOs. And this is just a function of the business scaling very quickly, but not everyone scales at the same rate. Now, some people left on their own volition. They were tired and they, you know, wanna take some time off.

Yeah.

But in many cases, the people just couldn't scale to the next level.

Now, your parents gave you 2 options professionally. You could either be an engineer or a doctor, right? And ultimately you found your way, uh, finding religion in sales as well. How, how did you discover sales as something that you, you had passion for? And what would you tell the CEOs that maybe view it as a, a black art or something unbecoming?

Yeah, well, my dad was a, a rocket, a true rocket scientist. He designed, uh, rocket engines and satellites. And so he always viewed sales as like a bunch of used car sales guys and thought it was not a very honorable profession. So what was interesting is when I started working, I was in this rotational assignment at AT&T where they gave me exposure to different functions. And the functions that were closest to the customer where I could see the intersection of business technology coming together was where I got really you know, interested and excited. I personally knew that I didn't wanna be like a hardcore developer or some engineer in a back room designing, you know, circuit boards or something like that. So I felt like I wanted to be where the business and the technology came together. And then as I started learning more and more about business, I realized sales is so important to the success of any business. AT&T being, having its monopoly roots, didn't really actually have a great sales force. And I went to a smaller telecom company called Teleport, which is a CLEC, they also had an okay sales force. So one of the reasons I reached out to Steve Wolski is because PTC had this reputation of having a great product and then also an amazing sales force. And Steve and I talked about that, and as he framed it, which I live today, is like if you marry a great product with a great go-to-market engine, obviously in the old days only sales, for us it's now self-service and various different sales channels. Uh, you, that's where the magic happens. And what I tell people is that as much thought as we put into product, we also think about very hard about how we're thinking about how we go to market, how customer buying behavior has changed. And I believe that if you can make product and go-to-market a competitive advantage, that really differentiates you from other companies in the industry.

Now, I, I, every job I, I've heard you say, and I agree with, has something that you hate about it. Uh, I think we live in this culture of people looking for this perfect thing out there and job hopping and all of that. Is there— can you elaborate on that point? And what advice would you have for young professionals that are maybe trying to find the perfect job with nothing that they hate in terms of their profession?

Yeah, I don't think the perfect job exists. I think there's things you can find that you love to do, but there's always gonna be facets of that job that are maybe not as enjoyable. And I find when I— the other thing, when I talk to people why they move from, say, company A to company B, what I'm also trying to understand is, are they running away from something or are they running to something? And what I find is a lot of people, especially this younger generation, they don't necessarily have the skills to deal with adversity. So their inclination is to run away from adversity and go to somewhere else where they think the grass is greener. And I tell my own boys, happiness and success is not the absence of problems, it's the ability to deal with them. You may have a boss that you don't get along with. You may have, you know, you're dealing with a difficult customer and they're very unreasonable. You know, what are you gonna do? You may have a product that doesn't always work and, and you're frustrated because it's awkward, it's embarrassing you in front of, if you're a salesperson, in front of your customers who trust and respect you. There's gonna be always situations and difficult things. You can choose to run away or you can say, how am I gonna fix this problem? Or how am I gonna elevate this issue that someone who can fix this problem fixes this problem? To me, those are really important life lessons. Now, obviously, If a company's in like a death spiral, no one's suggesting you keep staying there. But I think it's important for people to learn how to deal with adversity. You know, obviously grit is something that we think a lot about. And, you know, one of the characteristics we look for is, are these people— these people have grit? And one of the things, or as some people call it, do they fight or flee? I'm a fighter. And I hope to find other people who have that orientation to— to buckle down when things get tough.

Now we've referenced McMahon and Wolski, but I wanna back up to the, uh, to the original days of BladeLogic. So can you tell the story of how BladeLogic came to be and then maybe the fortuitous timing of the fundraise and that journey?

Sure. So I had been at a company called Breakaway Solutions, which, and I'd started a company called Applica, which is the corpus of their cloud computing business. So we were like a first-generation cloud computing, being telco guys, we called ourselves application service provider. So it was a very sexy term.

Yes.

And being telco guys, we thought it was all about the sophistication of the network, not anything to do with the application. So while Benioff was launching Salesforce and thinking about a radically new multi-tenant architecture, we were thinking about it's all about the network. And because we were data broadband networking guys, the network could solve the whole problem. Obviously we were wrong. We ended up taking that company public and then 70% of our customers were dot-coms. And then obviously we saw the rise and fall of the first bubble.

What was the peak market cap of that?

About $5 billion.

Wow.

And so that being said, we were, we had essentially like 11 data centers around the world. They were colo sites, but we were provisioning and managing all the infrastructure. And as the business was scaling, I was constantly throwing people at that problem to provision, manage infrastructure, because with the first generation of internet architecture, the complexity was moving from the desktop to the backend with thin clients. And I was like shocked when things started getting tougher. I said, there's gotta be tools to automate this because we just can't keep throwing people at the problem. And I was shocked to find out that there were no tools. Most of the tools were desktop tools that just didn't really work in a server-oriented world. So then I left Breakaway, actually ended up being an EIR at Bessemer, and I kind of worked on this idea. And my co-founder was an EIR at Battery, and we both decided to work together. We basically worked on this idea, and that was the corpus of starting BladeLogic, was coming out with a new server-based orientation to provision and configure servers in data centers. And so this was in the summer of 2001. And, you know, we had done a bunch of market research and obviously the bubble had just burst. So investors were quite skittish about like funding new companies because they were just dealing with the trauma of all the companies that were basically struggling. So the bar was quite high and the valuations were not great. So it was quite expensive to raise capital. We ended up raising our first round 5 days before 9/11.

Oh.

So you probably would not be talking to me today if I'd waited 5 days longer, right? Because that deal probably would've fallen apart.

Nir Jagarwal wrote a blog post, Who Let the Servers Out, after the bombing. Baha Men, Who Let the Dogs Out. I think it's still somewhere on the internet if you can, uh, if you can dig it up. But going through that journey, you guys competed head-to-head with, with Opsware, which, uh, for, for people that don't know, was run by Ben Horowitz.

Um, and there was— And Marc Andreessen.

And Marc Andreessen. And it was a legendary, uh, uh, battle, I would say, uh, that, that I don't know if there's anything that's even quite like it today of, of the culture. And, and you had John McMahon, they have Marc Cranny. It was a very—

Well, it's interesting. So actually, so I competed with LoudCloud, which the first version of Opsware when I was running, you know, at Breakaway.

Oh, right.

So, so they were another cloud computing company, and then they decided to repurpose their software provisioning tool into a software company where I decided to start from a clean sheet of paper. And by definition, I felt we always had the better product, but Marc and Ben are great marketeers. And so what was interesting is that they had a flagship account in EDS, and then they started trying to go after other customers. But they kept running into us and we were beating them everywhere. So they realized, what are these BladeLogic guys doing that, you know, we just don't know? And they realized we had a PTC guy running. Actually, it wasn't McMahon then. It was a guy named Steve Srahan who was another PTC guy. So then they decided to basically follow the same playbook. They actually did reach out to John, but they ended up hiring a guy named Mark Cranny who also kind of took the PTC playbook. And at the same time, Steve Turhan, again, another example of who did great work in the beginning, but then I realized wasn't scaling to the next level. That's when I recruited Jahan. And so yes, it ended up being 2 PTC sales guys running 2 very aggressive sales teams going after the market. And, you know, obviously Mark and Ben ultimately sold out to HP, and then we ultimately got bought a year later by BMC Software.

And got bought what, right before Lehman collapsed? You sort of booked it in both crises?

Yes. So the day we closed our deal, was the day JP Morgan bought Baez-Strengs for $3 a share.

And the culture of BladeLogic, the sales culture, like the number of people that have come through there, I mean, not just Mongo, but Datadog and Snowflake and Okta, and we can sort of go down the list of other people that are Zscaler that power enterprise selling in Silicon Valley. Did you recognize at the time how talented the sales folks you had within the organization were, or is it sort of a fish in water and you didn't totally? Like these are just the people around you?

No, I consciously wanted to build, I remember I believed in Wolski's philosophy that if you marry a great product with great distribution, that's when the magic happens. So I was very conscious, which is why I ended up chasing after McMahon because he was already even then a legend and saying, would you consider joining Blay-Lajic? And some people were actually shocked that I was able to get him. And then I would say the credit goes all to John because the, what John makes, what makes John really unique is I think one, he's an amazing listener. You know, if you talk to people, when he interviews people, people feel like they, he looks into their soul. Second thing, he's a fabulous recruiter. So his eye for talent is off the charts. So that's why the team was so good because he could really pick out the best people, even if people with limited track records, but figure out they had something really special about them. Third, he's an incredible developer of talent. So it's not just recruiting them, but constantly training them. And John and I would, work together. What do we— what does the sales floor need to learn, you know, this quarter versus next? Some of them would be sales-specific issues, other would be product and market issues, how to differentiate, you know, BladeLogic versus Opsware and all the other tools out there. So developing talent was something that he was really good at, and then he was maniacal in execution. And so again, recruit, develop, and execute, right? And John was A+ in all those categories.

Now, what about Wolski as a mentor? How did he influence you? And, uh, yeah, why was he so good for you along the way?

Wolski, I, you know, I give him a lot of credit for informing my leadership philosophy all the way from product and go-to-market and bring the two together, how to think about like leadership, how to think about like fundraising, how to think about like managing the board. You know, it was so, because as a first-time board member, this was all new to me and you just can't learn that quickly on the job. Now there's a lot more data, you know, in those days the data was quite sparse and so you really had to talk to people. So I do encourage first-time founders, you know, whether or not you have a board member or not, but find mentors who you can talk to because the CEO role is a very lonely job, right? Because everyone's advocating for something. It could be your team, and not that they're being malicious, but they're advocating things that are important to them. Then you have your board and there are things that they care a lot about too. So when you are thinking about things, if you wanna run something by a board member, how it affects them, or maybe, you know, their equity position is gonna have some function of how they respond to that idea.

Yeah.

Similarly, if you're thinking about restructuring the organization, if you wanna socialize it with a few people, if it's gonna potentially marginalize some people, they're not gonna be very happy with that. So the CEO role is a very, very lonely role. And so having people you can go to where you can just get unvarnished advice, be very comfortable, you know, laying out what the issues are and baring your soul and not worrying about it being used against you is so, so important. And Wolski played that role for me.

I wanted to ask about the topic du jour right now, which I think is on everyone's mind, artificial intelligence. And you guys are playing an important role in that. How do you think about AI? How does it compare to past trends that you've seen along the way and what role?

Yeah, the risk of being a cliché, I definitely think it's the next big profound platform shift in our industry. I think that what's interesting is I would say AI 1.0 is all about focusing on data scientists. I think AI 2.0, where you'll see much more broad-based adoption, especially around developers who have to build smarter applications and incorporate these new smarter technologies. We feel like we are well positioned because it will unlock a lot of opportunities where a lot of people have been okay with keeping these legacy platforms in place. But now with the advent of AI, it may, it might be the catalyst for them to rethink about modernizing a big part of their infrastructure. We obviously have announced some capabilities around vector and so on and so forth where people can obviously leverage RAG to marry public data with private data to build these smarter applications. But I think, you know, it's very, very early days. What I'm really interested in understanding is how does the developer workflow change with the advent of AI? And I think we're just at the early days of figuring that out. And obviously we want to play a big role in enabling that developer workflow.

Now, you've been in New York City tech for a long time, right? Now, were you up in Boston for BladeLogic and then moved down?

No, I lived here. You were here the whole time? I actually, we had our first child who just graduated in May. in July of 2001. And so, moving was impractical. So, I was commuting up to Boston, which wasn't easy, but basically, you know, I figured out a way to do it. I tried to start BladeLogic in New York, but it was just too difficult because the ecosystem wasn't in place and the culture, you know, you try to talk to Wall Street people, they say, yeah, I'll work for a startup, but they wanna keep their salary and still get a big equity, you know, position in the company, which obviously wasn't practical. Now I think it's very different here in New York. But yes, I commuted up there and then obviously have always lived in the New York area.

So what's been your perspective of how New York's changed over the last, what, 22-some-odd years working in tech and ASP way back when and now software today?

Yeah, so I went from the lone B2B guy to now surrounded by, you know, companies like Datadog, which I'm on the board of, and, you know, companies like UiPath and even—

I'm glad you retired from being a VC, by the way. Yeah. Datadog is one of your only investments As a VC, pretty good one. Yeah.

Yes. Well, Olivia and the team there get all the credit. And Etsy obviously has also been a very successful company. So to me, New York is a fabulous place, right? Because one, your customers are literally outside your front door. You have these amazing large companies, financial services companies and other types of companies all in your backyard. 2, New York is a gateway to really anywhere in the world. You can get to Europe very quickly. It's like a West Coast flight. You can get to the Middle East, you can get to Asia. And going to Asia is not that much longer from New York than it is, say, from San Francisco. So I think, um, there's obviously a whole other dimension of New York in terms of culture. Not everyone's in tech. There's so many other things. To me, New York, I've been to almost every major city in the world and I still think New York's the best city. So I'm, I'm, I'm, I'm stoked that, uh, New York is such a big tech center now.

Yeah, that's great. That's great. Uh, last one before I let you hop. Is there a piece of conventional wisdom, Silicon Valley wisdom that you adamantly disagree with that you hear get, uh, shared quite a bit?

Well, the one thing I think there's a pejorative perspective on professional CEOs, but what's interesting is if you look at like Nikesh Arora, look at like Frank Slootman, I think I've done reasonably well.

I think so.

Like professional CEOs have had major impact. Mark McGlocklin before Nikesh have some major impact. Now the founder-friendly kind of orientation makes a lot of sense. Obviously, you know, these companies don't start without founders who think differently and see problems that Or opportunities that other people don't see. But I think most people have this very pejorative view. They almost think, oh, the company's lost its way, whether they have to bring in a professional CEO. But when you look at some of the biggest companies in the world and some of the most successful companies in the world, you know, having the right professional CEO is not exactly a bad thing.

Yeah. Good. Well, Dave, thanks for doing this.

My pleasure. It's great to be here.