The Entrepreneurial Journey of mabl Co-Founder Dan Belcher

Founder Interview

Disclosure: mabl, the ML-driven test automation service, has previously sponsored Hacker Noon.

Today, we’re going to catch up on the state of this startup — and find out what makes Co-Founder & CEO Dan Belcher do what he does. Also read the other half of this interview, mabl Uses AI to Bring Software Testing into the DevOps Era

David: Looking back on your childhood, how did you find your interest in technology and kind of gravitate towards computers as they grew with you in terms of age?

Dan Belcher: Honesty, I didn’t have any exposure to computers when I was very young, this would have been in the ’80s. We couldn’t afford a computer, and I didn’t know anyone who had one, even though they were certainly out there. But when I was in high school, I got access to computers and the concepts came to me pretty quickly, so the teachers at the school gave me some freedom. They let me take these independent studies and I used one of those independent studies to build a computer, part by part, and programed on that. I loved that machine and used it for most of college. I may still have it in my sister’s basement.

David: It’s pretty cool that you started in tech by building your own computer. And then coming into college did you know you wanted to continue to work with technology?

Dan Belcher: No, I definitely didn’t. I wanted to be an English major, I wanted to study literature. And that’s what I did. Unfortunately, I found that the only jobs I could get to pay the bills were basically tech support, so I did that for a couple of years. And then I was fortunate enough to land an internship at Microsoft, and I think that’s what flipped the switch for me to focus on tech as a career.

David: From your background I found you were working in infrastructure strategy and Microsoft & VMware (2003–2009), could you just walk me through, how you see the evolution of infrastructure strategy and management in your time there?

Dan Belcher: When I started at Microsoft, every company, including Microsoft, thought that they had unique requirements for infrastructure, so we had thousands of developers building software from scratch to handle systems management, configuration management, change management, network management, etc. Even then I thought it was strange that we were spending all this time building software that was only used by one company — especially given that every enterprise needed a lot of the same capabilities

Around 2004, some teams at Microsoft realized, ‘hey, our customers are managing a lot of infrastructure on their own for email, SharePoint, file sharing, etc., and we know how to manage those things pretty well. Maybe we could just offer these as a service so customers can focus their IT on things that are more directly related to their business. So this was basically Microsoft’s first endeavor into the SaaS managed services space, and I was excited to be part of it. The idea of helping companies and teams spend less time on things that aren’t central to their business has pretty much consumed me ever since.

I went from Microsoft to VMware in 2007 because I believed that virtualization would make IT infrastructure and systems more efficient, so companies could redeploy a lot of that investment to business applications. But along came the cloud and I was following what Amazon Web Services and others were doing with their early cloud efforts, so I joined a startup, Sonian, that was one of Amazon’s beta customers. That was mind-blowing for me at the time, because I saw that we could build and scale a business with no physical infrastructure investments.

“I saw that we could build and scale a business with no physical infrastructure investments.”

In 2012, I had been at Sonian for a couple years, and I saw that there was still a lot of overhead in dealing with the cloud — we were building our own tooling for the infrastructure, just as I had seen in the early days at Microsoft. That was part of the catalyst for Stackdriver, which made it so that you don’t have to build and manage your own tools for operational monitoring, alerting, etc., and Stackdriver was part of a whole generation of tools that took a lot of the operational overhead away from cloud infrastructure. I see mabl as a continuation of that. Now, with containers — Lambda, App Engine, etc. — we’re not so worried about infrastructure at all; we’re worried about can we ship software fast, right? And so mabl is looking at the problems that are holding us back in this new world, and we think QA is one of those bottlenecks.

David: Why was this the right time to start mabl and leave Google?

Dan Belcher: Oh, a couple reasons. So, one Izzy and I are entrepreneurs at heart and we missed the thrill of building great teams, creating brand new products, and working together. And so, we were very excited to get back to doing what I think we both do best.

In terms of mabl, it was really a market-driven decision. We know the devops space pretty well, so we went out trying to figure out where there is pain in that area today. We surveyed hundreds of people, conducted hundreds of interviews, and we landed at QA as a very important pain point — and one where we could envision building a product that would have a real impact. And so, that’s how we got to mabl.

“Izzy and I are entrepreneurs at heart and we missed the thrill of building great teams, creating brand new products, and working together.”

David: Yeah, you really took a very analytical approach to looking at the problem and solving it.

Dan Belcher: Yeah, you got it.

David: You started your own company (Stackdriver) and you sold (2014) that to Google in less than two years, which is a pretty fast life cycle of a company and selling to one of the tech giants. So I guess I would ask you what advice would you recommend to the next entrepreneur to make the right decision when talking to these tech giants who are interested in buying their companies?

Dan Belcher: My first piece of advice would be to not focus on the exit at all when you’re starting out. Focus instead on building a great product, a great team, and a company that is going to be successful in the long run, and with some luck the exit will come. Building a company for a particular type of exit is also risky because so much of it is outside of your control — what is going on internally at your potential acquirers, what are their priorities, who is in charge, what other deals have they done, etc.

To the extent that you get engaged with a company like Google or Microsoft or Amazon, my advice would be to think about the potential acquisition as just another major stage in the journey for your team and product. And before you agree to make that leap, you should spend a lot of time working through the details of what that stage will look like, everything from the roles that each of the team members will play, how the technical integration will work, who will report to whom, and so forth. I think a lot of that is generally left to get worked out after the deal, but it’s in everyone’s interests to work this out before the close — especially considering that you have more leverage and attention during these negotiations then you’ll have after. I think it’s generally the integration, not the deal itself, that will determine whether the acquisition is a success for you, your team, and the acquirer.

“Think about the potential acquisition as just another major stage in the journey for your team and product.”

David: Yeah, that’s a great perspective… I mean if it’s not a successful company, no one wants to buy it.

Dan Belcher: Right, I think so much of this is about the people, you know the people who are sponsoring the deal, the people you’re going to work with, your team at the new company, etc. The financial side of it is one thing but boy, you really want to be sure that everybody 2, 3, 4, 5 years down the road feels like it was a career highlight after the acquisition, not the one big event.

David: Yeah, that makes a lot of sense. You ended up staying with Google for almost three years after that, so it seems like it was a pretty successful next phase. But compared to working at your own startup, how did you like and not like working at Google?

Dan Belcher: I thought that Google was an extraordinary place, it’s definitely the best job I’ve ever had where it wasn’t my company. They do such an amazing job of creating a culture where people want to collaborate, where there’s just general positivity. Throughout Google there’s a willingness to take on big risks and try to solve hard problems. There were also some downsides for me. For example, given that Google Stackdriver works across lots of other Google products, there were lots of people to coordinate with to make decisions, which meant that I spent most of my time in meetings. And given that I was based in a remote office, most of those discussions were via Google Hangout, so it was more challenging to brainstorm and be creative. Nonetheless, it was definitely a highlight for me to be able to see Google in action, if only for a few years.

“It’s definitely the best job I’ve ever had where it wasn’t my company.”

mabl also has some advantages. I like that we can make decisions very quickly, execute fast, and iterate on products very quickly in a way that is very difficult to do when you’re part of a big company like Google. I also like the fact that we’re all working in the same office face-to-face, so it’s easy to grab people and have ad-hoc conversations when we need to.

So, I see advantages and disadvantages to each. I’d say my experience with Google is about as good as it gets in terms of a place to work, if it’s not at my new startup.

David: Looking back on your career, when you’re much older, thinking about your work and your legacy, how do you hope your work is known and thought about or used?

Dan Belcher: For me personally, it’s about the people that I have the opportunity to work with, whether that’s people on my team, or our partners, or the users that we are deeply engaged with. When I look back on my career to date, it’s less about the individual project or the revenue or the outcome, much more about whether I helped put people in a situation where they were working at their best and growing and they feeling good about the experience. And so I’m not so sure I care about whether I’m remembered for that or anything else, but I certainly take a lot of pride myself in looking back and feeling like I was a part of creating situations where people and teams were at their best and doing their best work and having their best impact.

“When I look back on my career to date, it’s less about the individual project or the revenue or the outcome, much more about whether I helped put people in a situation where they were working at their best and growing and feeling good about the experience.”

David: People first. That’s good. Anything else you want to share about your company’s master plan?

Dan Belcher: Well, we’re hiring, in engineering and marketing, based out of our office in Boston. And we are excited to engage with people who see the value in making QA more effective and want to be part of that. You can join the waitlist on mabl.com or reach out on twitter if you have any questions.

Read the other half of this interview, mabl Uses AI to Bring Software Testing into the DevOps Era