Marketing is often tasked with communicating bad news well. Unfortunately, sometimes people try to hard to make bad news good. I remember one executive at one of my previous employers presenting a chart of his team’s output that showed declining output over time as resources increased. Incredibly, he spoke excitedly about how well the team was doing, never bothering to address the downward trend on the chart. Unsurprisingly, the CEO noticed and the episode did not help this executive’s career.
In the making bad news into good news department, I recently read this article extolling the benefits of their deadly smog (which is estimated to cause hundreds of thousands of deaths per year). Incredibly, they are talking about how the smog would be an advantage on the battlefield. Is Chinese smog the new Russian winter? I could try to come up with other environmental catastrophes that might have “defensive value” but it would be in poor taste.
Some free unsolicited advice to anyone who has to market the excessive smog in China: don’t try to make it good news. People will think the smog sucks and you are a liar. If you just say the smog sucks, at least they won’t think you are a liar.
Many companies measure their progress by some indicator of sales. In the end, product, market, and execution have to come together and how much money customers are willing to pay you is a pretty good indicator of how you are doing. But how to measure that?
In SaaS/recurring revenue models there are lots of detailed metrics. But what is that one summary metric – not for the wonkish analyst trying to analyze every detail of each month’s result but for Joe or Jane employee in engineering or marketing to see how the company is doing?
In early stage companies you almost always hear about “bookings”. Bookings are a measure of raw sales, how many orders we got. Which sounds simple and correct. But it is not always so simple. If a customer orders 10 widgets, one a year for the next 10 years that is very different from an order for 10 widgets right now. Now lets think about that order for 10 widgets, one per year for the next 10 years. Are they paid up front or on delivery? If the first widget doesn’t work are they still committed to the other 9? If they are not committed to all 10 is it really an order for 10 widgets or an order for 1 widget with an option on the other 9?
Unfortunately there is no universal standard for what is and is not a booking. I might have a strict policy that only counts firm commits that are paid up front. My competitor might have a lenient policy that counts orders that are paid later and are at risk of being cancelled, so it is very hard to compare bookings numbers across companies.
Revenue is different. There are very detailed standards for when you can recognize revenue. Revenue requires not just that you have an order, but that you have delivered the item and you expect to actually get paid for it. If I have an order for 10 ultra-widgets but haven’t yet figured out how to build an ultra-widget that is zero revenue until I actually ship the customer some ultra-widgets. Conversely, if I ship some widgets that were ordered a long time ago I recognize revenue today. So revenue is not purely a measure of sales, it can be increased or decreased by how the product is delivered to customers.
Which is better? As usual, it depends. Large companies typically report revenue. Reporting revenue is required for public companies and it is what outside parties look at because it is comparable across companies. Smaller companies typically report bookings because it is simpler to calculate and a purer measure of sales especially when other areas of the company that impact revenue recognition are not yet mature. Sometimes small companies don’t know the difference and say “revenue” when they have not followed any of the rules for recognizing revenue properly and they are reporting something that looks more like bookings.
Bookings numbers are typically higher than revenue numbers – it is hard to have revenue that is not bookings, but easy to have bookings that are not revenue. Sometimes the difference is enormous. If I get an order for 50 Dreamliners that might be a multi-billion dollar booking but until I deliver some planes that is no revenue. If a subscription service gets an order for a 3 year subscription to their product with one month remaining in the quarter they recognize 1/36 of that revenue in the quarter. It is not unusual to have revenue be half of bookings or less at a fast growing company.
This morning MongoDB announced that we raised $150 million in growth capital. Some notable new investors include leading public market investors Fidelity and TRowe Price along with Salesforce.com. I am also excited to welcome Altimiter Capital (where partner Kevin Wang is actually a MongoDB user) and happy to see that NEA, Sequoia Capital, Intel, and Red Hat all increased their stake in the company.
I wanted to talk a bit about why we raised so much money, what we will do with it, and where I see the company heading.
The database market is very large and until recently had not changed much in the last few decades. When I joined Oracle almost 20 years ago, in practice your choices were Oracle, IBM, Sybase, and Informix. Since then, IBM bought Informix, Microsoft wound up with much of Sybase’s intellectual property, and Oracle, IBM, and Microsoft are the 800 pound gorillas of the database world.
Open source relational databases had an impact on developers and startups, but not much impact on the enterprise and have met with limited commercial success. Certainly open source has not impacted databases in the way it has impacted operating systems.
I think the industry is ready for change. I think database users want a technology which is more agile than relational, better suited to cloud-style deployment, and a better fit for the type of application development we do today. At MongoDB we see the passion developers have for the ease of use of the document-oriented model and we see the impact it has on businesses like MetLife, Telefonica, Goldman Sachs, Salesforce.com and Criteo.
We’ve seen the potential, but we are in a market dominated by technologies with over 30 years of engineering in them. Their designs may not be as well suited to modern applications, but they are very mature, very feature rich, and have huge partner ecosystems and big companies that understand the needs of their enterprise customers behind them. They have way more tooling – and decades of refinement of operational tools.
This is why we are raising $150 million. We know that it will take a large and sustained effort to build the maturity that many users expect in this market. Building out our management suite and enhancing the core product will be a ton of work. We have made great progress on security, management, stability, and scalability but we still have so much to do.
It took tens of thousands of person years to build each of the leading relational databases, billions of dollars of R&D. Standing on the shoulders of giants in commercial databases, open source databases, and academic research our task will be easier and we will get there faster. But we need to make very large investments in MongoDB over many years and we need our users to know that we have the capacity to make those investments.
We are excited to partner with IBM, who is making DB2 compatible with MongoDB, and Microsoft, who is working with us to ensure that a top-quality MongoDB service is available in Azure. We are excited about the industry leaders like Intel, Red Hat, and Salesforce.com who have invested in MongoDB. We are excited about our many partnership including established leaders like Informatica, Qliktech, Amazon and Rackspace and emerging leaders like Pentaho, MongoLab, and MongoHQ, all of whom have worked hard to build offerings that work well with MongoDB.
We are excited to build the database of the future in an open source model. The community has contributed over 20 drivers, tripling the language compatibility of MongoDB. With over 5 million downloads, open source has helped adoption skyrocket. And with the freedom to use the product for free, customer relationships become more equal and more collaborative. I like that we have to earn our customers’ business every year.
Offering a viable mainstream alternative to the relational database will be a lot of work but we think the benefits to our users will be worth it. I know that the team is excited about the work we have ahead of us and appreciative of the funding that will enable that work.
The old joke in Silicon Valley is that you can tell the extroverted engineer from the introverted engineer because he is looking at your shoes instead of his own shoes (and yes, it is always told about a “him”, which will be the topic of another post). But what happens when an introvert becomes CEO?
I’ll start by sharing a bit about myself and being an introvert. Being an introvert does not mean that I don’t like people or interacting with them. For me it means that
- While I enjoy talking to people that I know, I find it difficult to initiate conversations with people that I don’t know well
- While intellectually I know that usually I will enjoy getting to know a new person, meeting new people consumes a lot of mental and emotional energy for me
- I need a fair bit of quiet time to rest and recharge
- While some people find the ideal of going to a big party with 300 people that they don’t know exciting and energizing, I find it intimidating and exhausting
I love my job running MongoDB. I am incredibly excited about the technology we are building, how we are helping our customers, and the team and culture we are building. I cannot imagine a better job for me; I have the opportunity to take advantage of everything I have learned in my career to date and the rare opportunity to reshape one of the largest markets in software and build a truly great company. But I often feel that my job would be easier as an extrovert.
While getting to know new people takes a lot of energy, I do care a lot about people, in particular the employees of MongoDB. I want them to love their jobs and to grow from them – as people and as professionals – as I have from my favorite jobs. I also recognize the symbolic role of the CEO. If I am interested in what someone is doing, it energizes them. If I am uninterested, it saps their energy. If I remember someone’s name or say hello to them in the hallway, it makes their day a little bit better.
I watch our ratings on glassdoor and I am proud that they are very high for an enterprise software company. Recently I saw this comment in what was overall a 5-star review titled “Incredible talent, meteoric company”:
Also, the higher executives should probably engage more with employees on an everyday level – execs can often be seen moving throughout the office without knowing many of their employees names or even saying hello. As the company grows, it becomes less feasible to know most people, but it didn’t even seem like there was much effort to personally connect with employees. A nitpick, no doubt, but worth mentioning nonetheless.
It rang true, and the blame for this lies largely with me personally. And I don’t think its a nitpick, I think it is important.
To the anonymous author and to all employees who feel that way (and I am sure there are many), I am sorry. It does take me more effort to connect with new people, but I need to make that effort, I know how much it matters to you. I do hope that writing this post and sharing why this is hard for me helps people to take this weakness of mine in context – it is not a lack of effort or not caring but rather something that has been a challenge to me throughout my life.
As the company grows, an additional challenge for me is some loss of anonymity. People sometimes recognize me at my kids sporting events, walking down University Avenue, or coming out of my once-a-year-religious-observance on Yom Kippur. The privacy of big crowds is beginning to disappear, which is a loss for an introvert.
As for my effectiveness in running the company, perhaps I would be more effective if I were more gregarious with the team. Certainly they would like it day to day. On the other hand, I do think there are advantages to my style. In larger groups I often like to hang back and listen. One of the hardest things for a CEO as a company gets large is having good data. While I am not a magnetic outgoing leader, I think I can listen well and I have high empathy. And I think we have built a strong team and they are pointed in a good direction.
I hope to build a company where people feel good about the decisions we make and how we make them, the product we are building and the impact we are having for our customers, and the team and culture we are building. I know they won’t feel great that their CEO is always energetically saying hi to them in the hallway, but hopefully they feel good knowing that their CEO does care about them and is making an effort despite his introversion.
Recently I was asked to give a short talk on balancing delegating vs doing at a CEO forum. I thought I would share some thoughts here as I prepare. Mostly from the CEO viewpoint, but many of the ideas here could apply to managers in other roles.
I think there are four types of tasks a CEO needs to do:
1. Core job. Building the exec team, keeping money in the bank, pointing the team in the right direction, and guiding the culture.
2. Tasks that come with the title. Some big customers want to meet you. Investors want to meet you. Employees want to hear from you. Just because someone else can do those meetings just as well or better doesn’t make it the same. As a company grows there could be 200 hours a week of tasks in this category so you will need to prioritize.
3. Personal growth. First, you need to ensure you are constantly refreshing your understanding of the business. Do you know what is working and what is not? How customers and employees feel? If not, how can you make decisions about company direction or executives? Getting good data is hard. You also need to be constantly building your skills, and in many cases you need to be building your network and public profile. It is easy to neglect this category. Don’t.
4. Skillset based. Stuff that isn’t really for the CEO, but you are the best person to do it. In a small company there will be a lot in this category. As the company gets bigger there will be less. This is often the area where balancing challenges arise.
There is no right answer for every situation. Some of the factors that will lean towards more delegating are:
1. Larger organizations. Unsurprisingly, as your team gets larger your impact will be primarily through leadership and your individual contributions will be smaller.
2. Volume models. At facebook with over a billion users, the CEO doesn’t personally recruit each user. But at Boeing, the CEO might be very involved in a sale of 100 dreamliners.
3. Status quo is working well. If there is a good product market fit, the team is executing well and the culture is working, let the team do its job. If one or more of those is broken, you need to roll up your sleeves and fix it.
Of course the absence of these factors will lead towards more doing. Some other factors that lead towards more doing:
1. Inability to hire those who can do critical tasks better than you. You’ve heard 100 times to hire people that are better than you. But probably you got your job (either hired as CEO, or your startup was funded) because you are very very good at what you do. Finding people who are “better” than you is not as easy as it sounds. Of course they don’t need to be able to do everything you do, but for roles that demand breadth it can be very hard to let go. This can be particularly challenging if your company is struggling and your ability to hire is limited (either because you have limited budget, or because great people don’t want to join).
2. The success of the company is particularly dependent on one task and you are extraordinarily good at that task. For example, you are a great sales person and the company must win a critical deal to make it to the next stage. Or you are the company’s product visionary and the market is changing significantly.
3. Spiky skillset. If you are a generalist (like many hired CEOs), it probably makes sense to delegate more because you are unlikely to be the best person in the company at any particular task. If you are awesome at one or a few things (like many founding CEOs) it make make sense to hang onto some tasks for longer. Some conventional wisdom would say that maybe you should focus on those tasks rather than being CEO, but CEO transitions are risky and founder leadership is important, so you may be in a tricky situation for a long time. High class problem.
Most important is to be realistic in assessing your own skills and the company’s needs. If you have a good board, they will understand both well enough to help and you will trust them well enough to accept their help.
Today 10gen is changing its name to MongoDB, Inc. I wanted to share my thoughts on the change with the MongoDB community.
The short version: the company is completely dedicated to building and supporting MongoDB, so it made sense to have a name which clearly communicates that focus.
The long version, for those who want more context, starts with some history. When Dwight and Eliot founded 10gen they were building an open source cloud computing stack. Of course with multiple products under development the company had a name and an identity separate from any of the products. Fairly early on, Dwight and Eliot decided to focus the company 100% on MongoDB. This left a company named 10gen that was completely focused on building and supporting MongoDB.
There are pros and cons of 10gen and MongoDB as names. 10gen sounds more serious and alphabetizes better. MongoDB is catchier and easier to spell. In the end, the decision to change was not a decision about which name was better, but a decision that one name/identity/brand was better than two names/identities/brands.
Why one name versus two? Simply put, with two names the name of the company failed to communicate what the company’s mission was. With unified naming, the company’s name clearly communicates who we are and what we do. Furthermore, we wanted to continue building awareness of MongoDB; building awareness of both MongoDB and of 10gen would be more complex and more expensive than focusing on MongoDB. We felt it was better to invest that incremental spend in making MongoDB better (ie, hire more engineers) than making 10gen more recognizable (lots of marketing spend required).
Over the coming decade, we have tons of work to do on MongoDB. We will continue to invest in the product, the community, our partners and making our users and customers successful. We believe passionately that the world needs a database which is better suited to modern application development. We are excited that so many of you are choosing MongoDB and committed to making that choice a success.
Our new name clearly reflects our total commitment to MongoDB. We look forward to working with the community to help MongoDB realize its potential.
Sample bias is a simple concept. If you do a poll about the economy standing outside the unemployment office people will probably say its bad. If you do it inside the Gucci store you might get a different answer. Reality might be somewhere in between.
In many businesses, we don’t get to talk to all our customers to understand how satisfied they are. We might talk to a couple each day, and over the course of a few months feel like we have a large sample and a good handle on customer satisfaction, having talked to 150 customers.
Imagine two executives, the COO and CTO, each meeting 150 customers. Lets look at their samples.
The COO flies all around the globe meeting customers. When he is going to Japan, he calls the head of Japan two weeks ahead and asks to have some customer meetings. The head of Japan thinks a little bit. I could take him to customer A who is really mad because we screwed up their project. Or I could take him to customer B, who loves how their project went and wants to buy more. In most companies, he sees customer B. That pattern repeats itself the world over. The head of sales sees a lot of happy customers, and thinks that customer satisfaction is great and the team is doing a great job.
The CTO stays at home. Besides working on the next version of the product, he is the final escalation point for complex technical issues. The company has 20,000 customers. Each of them has some form of issue roughly every 3 months, so each day there are 200 issues logged. 90% of those issues are resolved quickly by the support analyst assigned to it. 10% of them – 20 a day – need some extra attention from an engineer. Again, 90% of them are resolved fairly quickly. The other 10% are somehow problematic: the engineers can’t figure it out either. No problem, enter the CTO. He solves the 1% of the support cases that the support team and engineers can’t solve, which ‘only’ amounts to two issues a day. Not so many for a base of 20,000 customers, but a lot for the CTO to deal with. Now ask the CTO about customer satisfaction and how the support team is doing. Not so well.
Same product, different sample. One selected for satisfaction, the other for dissatisfaction. Completely different conclusions.
Shortly I will be participating in the March for Innovation, in support of liberalizing our immigration policies. I wanted to share some of why I favor a more open approach to immigration, in particular for highly skilled immigrants.
I will start with the counter-argument. In an environment of high unemployment, fears that immigrants take jobs from Americans are heightened. Why should we bring in immigrants to do good jobs when there are plenty of out-of-work Americans? To many, this argument is compelling. I don’t agree.
As the leader of a rapidly growing technology company, I am looking to hire the best talent I can get. I am a patriotic American and I want us to have a strong economy and plentiful jobs for all members of our society. At the same time, we live and work in a globally competitive environment. When we find someone with exceptional talents, I want to us hire them. I need us to hire them. We must make our company strong, so that it can grow and thrive and continue creating jobs and innovating.
While 10gen is still small – under 300 employees – we are growing fast and we have offices around the world. We’ve found talented people all over the world. When we found a talented engineer in Iceland, we hired him. We hired him initially to work in our London office, and eventually he moved to the US. His visa to come to the US took a while, but he was productive in our London office while it was being processed. When I found a talented HR executive in France, we hired him, again initially in London. Again he eventually moved to the US.
Some would argue that these hires cost American jobs. I don’t agree. If our immigration policies didn’t allow us to move these employees to the US, they would still be working in London. They would be paying taxes in the UK and their salaries would be contributing to the UK economy. I think the American economy is stronger with them here, paying taxes and contributing to our economy.
Moving beyond anecdote, studies have shown that for every 100 foreign born workers with and advanced degree in Science, Technology, Engineering or Mathematics from an American University an additional 262 jobs are created for US natives. Adding 100 H-1B (skilled immigrant) workers created 183 jobs for US natives. Perhaps more surprisingly, adding 100 H-2B (less-skilled non-agricultural) workers added 464 jobs for US natives.
Many of the jobs tech companies hire immigrants for are engineering jobs. They are often very high end engineering jobs designing complex products where hiring the best candidates in a global labor pool can make the difference between success and failure for the company. If that engineer is successful and builds a good product, many more jobs follow. The company will hire sales people and accountants. It will hire human resources people, marketing people, administrative assistants, and cafeteria workers. Those workers will buy cars and houses. They will go to the doctor and to the dentist. They will pay property taxes, send their children to school, eat out at Denny’s, and shop at Home Depot. We don’t associate those jobs in sales, accounting, dentistry, food service, and retail with a foreign-born engineer but we should. It is engineering excellence and innovation that power the tech industry and much of our economy.
Not only do immigrants help with employment, they also help balance the budget. In 2009, the average foreign-born adult with an advanced degree paid over $22,500 in Federal, State, Social Security and Medicare taxes. Their families received welfare, unemployment, medicare, and other cash benefits of less than one tenth that amount. More skilled immigrants will help balance our budget.
Finally, as I alluded to above, immigrants are huge contributors to innovation. They found companies and invent things. 44% of silicon valley startups are founded by immigrants. And its not just startups – 40% of the Fortune 500 were founded by immigrants or their children. On the patent side, at the top 10 patent-producing US universities, more than three quarters of patents have at least one foreign inventor.
Economic relationships are complex. It is easy to see a foreign worker as taking an American job. It is harder to see how that engineer who build something innovative creates jobs for Americans selling that innovation, servicing those customers, and indirectly building houses and cars, educating children, and serving meals for those employees. In the end, the choice is not whether that highly talented foreign-born engineer takes a job from an American. The choice is whether that highly talented foreign-born engineer innovates here or elsewhere. I choose here.
For most of the last 20 years that I’ve worked in databases, the industry has been pretty boring. Proof? It has been 10 years since Gardner group bothered to update a magic quadrant for operational/OLTP databases. You would think a $20B+ market would be worth some analysis, but not much has been going on.
20 Years ago your options used to be Oracle, IBM, Informix, and Sybase. Then Infomix hit financial troubles and was scooped up by IBM. Sybase did a deal with Microsoft that didn’t quite work out as planned and, after diversifying their remaining business, eventually was bought by SAP. 20 years later, your options were Oracle, IBM, and Microsoft.
Things have now gotten interesting. Looking at a ranking of database popularity, MongoDB is ahead of Sybase. Rewinding a bit further in database history to Ingres (ranked #30, and the last major RDBMS to fall away before my story started 20 years ago), some of the systems that have become more popular than Ingres include Cassandra, HBase, CouchDB, Netezza, Riak, Vertica, Neo4j, Couchbase, SAP HANA, and Greenplum (in that order).
The good news is that the market is waking up. All these new entrants are have created innovation. Customers are thinking differently and asking questions. And analysts are answering the questions: Gartner will do another magic quadrant.
Two interesting questions for the audience:
1. Will they call actually call it OLTP or will they describe it, more accurately in my view, as “Operational” database? I think there is still a split between operational and analytic workloads, but I don’t think OLTP is the correct way to describe many important operational workloads. I am optimistic that they will broaden the focus.
2. Any predictions on who is included and who is not? How many “traditional” databases vs NoSQL databases? If I were making the MQ, I would include:
Oracle (Oracle RDBMS and MySQL), IBM (DB2 and Informix), MSFT, SAP (both Sybase and HANA), Postgres
MongoDB, Cassandra, Couchbase, HBase, maybe Neo4j and Riak
MarkLogic (XML) and Intersystems Cache (Object)
For a total of 16 databases, half of which are relational. For open source technologies I believe Gartner will look at vendors and vendors with multiple products will only get one entry, so my actual prediction is 5-6 relational vendors and 6-7 non-relational.
I won’t try to predict who winds up where, but I’d love to hear opinions on who will and won’t be included and where folks will end up.
Sales compensation is often a controversial topic. Big checks invite jealousy and second guessing. The best way I’ve found to calm down the jealousy and second guessing is to encourage the team to view sales compensation as being a lot like lottery tickets. Let me explain.
When you pick the right numbers for powerball, you might win $80 million. Do you “deserve” $80 million? It depends entirely on what you mean by deserve. Did you provide that much value to society in any direct tangible way? No. But if the winner doesn’t get paid, nobody would play the lottery. And the rules say you get paid, so at least in that sense you “deserve” to get paid.
I remember a story of an old time texas gambler who went to an illegal poker game. Something set off his danger sense so before going into the room, he asked the security guy at the door a question: “If I were to win a lot of money in this game, would I be able to leave with it?” He didn’t get the answer he wanted, so he didn’t play. Good decision.
I view sales compensation a bit like playing the lottery. You have to be able to count on being paid when you get lucky, or the whole system breaks down. When a sales rep earns a big commission, I pay it. I don’t think about how much they really deserve it. They may have gotten lucky by having the right account at the right time with the right supporting team, but somehow they showed up with the winning numbers. Occasionally someone who actively screwed up a deal gets lucky and closes it anyway. And they get paid. They may get fired if they screwed up badly enough or often enough, but even then they get paid.
I hear a lot about companies that find ways to not pay their sales reps. Almost every sales compensation plan has an escape valve where the company can decide not to pay. Some companies use it liberally. I know not because I do it but because I hear about it – in interviews of top performing reps whose employers found a way not to pay them. Once you’ve hit the winning lottery numbers and not gotten paid, it makes it hard to buy another ticket for that lottery. I sleep easier at night knowing that none of my sales reps are interviewing because we didn’t pay them what they earned.
How about jealousy? I have talked to a lot of technical people who are jealous of the big check their sales colleague got when a deal closed. I grew up on the technical side and only took on responsibility for sales teams later in my career so I have great sympathy, having felt that jealousy myself. Having now lived on the other side, my response is in two parts.
First, I explain that the sales team is, metaphorically, paid in lottery tickets, and this rep just got a winner. I remind them that being paid that way, and held accountable in the way sales is, has some downside too. When the deal closes they’re a hero and make a lot of money whether they “deserve” it or not. When the deal doesn’t close their income takes a hit and their job is at risk whether they “deserve” it or not. It’s not fair to have the downside without the upside.
Second, I ask if they would like that job. I do believe that’s the truest test: if you wouldn’t switch places with someone, don’t complain about them being overpaid. Heck, when I was a college student making $9 an hour doing tape backups on a VAX at night I was jealous of Alaskan fishermen making $2000 a week, but not jealous enough to quit school and do that. Not only does this usually end the jealousy, but sometimes we discover a hidden sales talent – I’ve had some hugely positive experiences with technical people migrating into sales roles.
Finally, one corollary is that if a rep always gets paid on the deals they close whether they “deserve” it or not, then a rep shouldn’t get paid on deals that don’t close whether they “deserve” it or not. It may sound obvious that a rep shouldn’t get paid on a deal that doesn’t close, but from time to time I am asked. Of course there’s always a good reason: the customer would have bought if the product had shipped on time, the customer would have bought if we’d fixed their bug faster, they would have bought if the company had agreed to xyz terms, the deal would have been bigger if xyz, etc. Often they are right, but I don’t care. To be precise, I care but not as much as I care about something else. What’s more important is the process being objective, so that the sales rep who does close a big deal doesn’t have to worry about whether they’ll get paid. Because once subjectivity and whether they “deserve” to be paid enters the picture, the whole system falls apart.