It has happened to nearly every technology leader. A project that seemed like an excellent idea when you started it either drifted off course, proved too ambitious or not as useful as originally thought. What do you do when you're in the middle of a project that you realize is not going well?
Eliot Horowitz, CTO and co-founder of open source database company MongoDB, knows this problem first-hand. In an interview with The Enterprisers Project, he explains what happened when he and his co-founder realized they had to pull the plug on the original version of their technology.
The Enterprisers Project (TEP): Tell us what happened when you realized your technology project started to head in the wrong direction.
Horowitz: MongoDB started out as a component of a much larger, more ambitious project called 10gen. When my co-founder and I got started on that, it was 2007, and we both shared a powerful intuition that the world was moving towards a serverless model. We'd had started tons of projects together by then, and we were having some pretty lofty conversations about new architectures that could address many of the problems we saw with building modern applications. App-deploying containers like Heroku were starting, S3 was becoming popular, AWS was starting to get interesting, and client-side apps were just about to come into their own. But there wasn't a system that took away all the burdens that companies faced; there were just piecemeal solutions.
So we built 10gen, a platform-as-a-service for handling everything but the business logic. 10gen managed CDN, elastic scaling, polyglot execution engine, and a data storage layer where application objects could be stored as rich JSON documents.
TEP: Why did that go wrong?
Horowitz: In our case, the wrong direction was trying to do too much, all at once, before the groundwork had been laid. Eventually, it became apparent to us that we had bitten off more than we could chew. And after all, it's now 2016 and even though some cloud providers are offering serverless computers, most teams are still using a cloudy version of a data center infrastructure.
Deciding what to do next was a bit painful but clear. We were most excited about the database component, and from talking to other developers, we knew that databases were the most painful part of application development. So we carved out the database, open sourced it, named it MongoDB, and went all-in on building a community around it.
TEP: What did you learn from the experience?
Horowitz: The lesson there was that trying to solve all problems at once may not be what your users want. They may only be ready to address one or two issues at a time. A readiness to pivot is mandatory for a startup team, and if you do have to pivot, you stand a good chance of doing so successfully if you isolate your best innovation, throw away everything else, and focus on that.
TEP: Do you have any strategies for delivering bad news? How do you effectively communicate when a project needs to be refocused or killed?
Horowitz: I'm about as matter-of-fact as it comes, so I just deliver it unvarnished. People don't appreciate being sold a pile of spin, so why waste your time coming up with a nice story?
Perhaps the most important advice I have about delivering bad news isn't actually about delivering the news; it's about creating an environment where failure is understood to be a consequence of trying, and how you conduct yourself day-to-day. Put in the work, lead from the front, and set a good example, and if you have to deliver bad news, you'll at least deliver it from a position where you're respected.
TEP: Many times after a project gains inertia, people are afraid to speak out against it. How can you create an atmosphere where it's OK to be critical in a constructive way?
Horowitz: At MongoDB, we've made intellectual honesty a core value of ours, and it's not uncommon to hear colleagues extol the merits of Kim Scott's Radical Candor. As a leader, you can foster this environment by soliciting feedback yourself, by being frank in your criticism, and by publicly acknowledging the positive impact of specific instances where constructive criticism led to real improvements.
