×

Dwight Merriman,
Chairman at MongoDB

2013-11-19

Co.Labs

Founder Of MongoDB Has Only One Wish

Dwight Merriman has started three billion-dollar companies: DoubleClick, Gilt Groupe, and MongoDB. Here’s why he’s putting it all aside to get coding again.



Dwight Merriman is a developer who has founded not one, but three, enormously valuable companies. DoubleClick was acquired by Google for $3.1 billion; Gilt Groupe’s last round of investment valued the company at more than $1 billion; and until recently, Merriman was the CEO of MongoDB, worth approximately $1.2 billion. His idea of a side project? Starting news site Business Insider.

Now that Merriman has moved from CEO to chairman of MongoDB, he may finally get what he wants most: more time to do technical work. Co.Labs talked to him about databases, cofounders, and staying technical—even as his management roles expand.

You moved from CEO to chairman at MongoDB partly so that you can do more technical work. Why do you still code?

I enjoy it, so it's slightly selfish, but also I've implemented significant pieces of the product historically so it's both useful and I like to do it. My background is software and development. It isn't being a pure business person. I don't have an MBA or anything like that. The company is around six years old. For the first five years I was CEO but also coding a significant amount, not 10% but 35%. When you are small you can do that. Then we tripled in size in three months and there's so much to do and the percentage of my time that I spent on development just started tailing down toward zero. The goal was to get back to what I was doing a few years previously as CEO. Because we are growing so fast, I still don't get all the technical time I want.

Is there pressure on developers to move into management rather than staying on a more technical track?

This is a classical conundrum for developers. At some point there's a fork in the road. There's engineering management or technical lead and I think a lot of times people feel pressured to go on to a management track. Just because you are the best engineer in the building doesn't mean that you are even a competent manager. You also have to ask yourself even if you are going to be good at it, will you like it? People shouldn't feel forced to go down the management track. Often it feels like there is more headroom in that direction. My advice would be don't be afraid to resist that kind of pull. People default in that direction so, if anything, bias a little bit in the other direction.

At the margin, I've tried to avoid having too many direct reports by hiring VPs of engineering at certain times in the past or when Max (MongoDB’s current CEO, Max Schireson) joined, by setting up a very vertical reporting structure where basically Max reported to me and everyone else reported to him. A slightly less extreme example might be Facebook where Mark Zuckerberg has product report to him and then all the other business stuff is off on the side.

You have an interesting working relationship with your long-time business partner, Kevin Ryan (currently CEO of Gilt Groupe). What’s your advice for developers choosing a cofounder?

We met in DoubleClick in January 1996. He was president for a while and then CEO and I was CTO and cofounder. I'm technical and he's a great business person but there is some overlap when you think about business strategy and high-level decision making. We were on the same page, philosophically aligned. We virtually would never have a big dispute about anything.

If you are really good technically, I would look more for a partner with business domain skills. Is he or she awesome at what they do? It's easier for a technical person to interview a business person rather than vice versa. It's very hard if you don't have a technical background to interview a software engineer and know if they are good or not. Does the person have good insights and thoughts? Are they smart? And then regardless of how good they are, are you on the same page? Are you tending to agree on things? You can have two smart people who are perfectly amicable but there's two of you—there's no tie breaker—and you have to reach a consensus. It's just going to be inefficient if every time you have to make a decision you have to talk about it for eight hours to get to the decision.

A considerable chunk of MongoDB’s new round of funding is earmarked for R&D. What’s next for the product?

Part of the R&D is just perfecting the product—it's still young—and part of it is making it very easy to operate for dev ops and DBAs, and then part of it will be adding new stuff. Databases are not simple and it takes them a long time to reach peak maturity. With relational databases the theory was invented in around 1970, the products came out in 1980, and about 15 years later is when you really got to the point where you said, "I don't need the next release because it's going to be pretty much the same." It takes time.

I really want to see us doing a lot of work on performance and parallelism of the system and then also on wrapping it in software to make it very easy to operate and manage at scale with large clusters. If you have a thousand servers, on average one will die every day. We build in automatic failover, recovery nodes, that kind of thing, but there are a lot of other things which just could be made easier like upgrading the software on the entire cluster. Today that would require some scripting on the part of the operator.

Is the rise of data science influencing the direction of the product?

There's quite a lot of usage of MongoDB and Hadoop together where MongoDB is either the source or the sink or both for a MapReduce job and you are using Hadoop to do the modeling or analytics that you are doing. That's getting to be pretty common. The way that the data model works in MongoDB, it's a good place to capture information for later for data science purposes, this notion of store everything or speculative storage. You don't know a priori what's going to be important. A good principle for IT is store first and ask questions later. If you go back 15 years that would not be a best practice, that might be a path to disaster. So that's a big change. If you have it in your hand, store it instead of dropping it on the floor. Maybe most of it you don't use, but if there's a minority of it you do use, the only way you will have it, is if you have kept all of it.

What are some of your own favorite applications using MongoDB?

It's pretty cool what (insurance firm) MetLife has done. They have created a 360-degree view of the customer. When you call them the person you talk to actually has all the information required. This may seem like an easy problem for a small company, but when you get to that scale and you have so many divisions and products, it's actually really hard to do. They take data from 70 different data sources that are being updated in real time. How often does the schema change on one of those 70 input databases? If it changes once a year then you have got a change in the aggregate store daily, and it changes more than once a year. They were able to build it quite quickly and have had phenomenal success with it internally.

One which is interesting, just because the use case is interesting, is Craigslist. They used it to create their archive database. Their online database, that's the database of current listings, since the beginning has been MySQL. Then there's an archive of every listing ever, which is obviously gigantic, but they need that for various purposes including if they get a subpoena for a listing. The neat part is how elegant a solution it proved to be to transfer the relational into this non-relational MongoDB thing. If you archived it into a relational database, first it's pretty big, but there's another problem which is that your schema changes in your online database over time and the archive needs to have everything from schemas in the past. It used to be that we had this column which we don't have anymore. It has turned out in that case to be easier to archive a relational database in a non-relational database. I find that fascinating.

Where do you think database technology is headed?

I do believe for database tools that one size fits all is over, but I don't think you want a dozen different tools that you have to be an expert on. You want three of four and some of those are your existing tools: an RDBMS and maybe some data warehousing technology. You're going to add a NoSQL database to that toolbox. We are seeing a lot of usage by big Global 2000 companies now. NoSQL in general and MongoDB is getting to be something that's used by companies of all sizes if they write any apps at all.

[Photo by © Luca Sartoni | Heisenberg Media]

Article Tags: databasesmongodbNoSQL





Add New Comment

0 Comments