Learning to Experiment; Learning to Fail; Learning to Lead

Yoav Shapira - V.P. of Engineering at HubSpot By Yoav Shapira, Vice President of Engineering, HubSpot
December 23, 2009

At HubSpot, a three-year-old Boston-based software firm that primarily builds Internet marketing tools, each month the engineering teams publicly commit to building a specific product. This, in itself, may not be so unusual. But what is unusual is that not only do the teams decide for themselves how they will build the product, the team—and the team alone—decides when it will be ready for customers. Then, and only then, do they release it.

As HubSpot’s Vice President of Engineering I believe that the process is working. I don’t know if it will scale forever, but we have a couple of thousand of real paying customers and our customer satisfaction is high.

After I graduated from MIT’s System Design and Management (SDM) program in 2006 and began working at HubSpot, I needed to confront what I believe to be a basic truth learned in my SDM Systems Engineering class: Even though I have the experience and the responsibility, I’m not always going to be right. So, instead of saying to my team, ‘This is the decision and this is how we’re going to execute it no matter what,’ I’ve learned to develop a culture of experimentation and to trust the team.

The results have led me to believe strongly in the value of experimentation. At HubSpot, as at many start-ups, bandwidth is limited and resources are scarce so prioritizing is hard. Nevertheless, we’re still willing to pursue projects we know might fail, even though they are significant projects for us and can last from one week to a month. Our purpose in doing them is not solely to ship something to customers but for our teams to share with each other what they’ve learned from failure, as well as success, and strengthen HubSpot’s capabilities.

If this sounds like an engineering-centric culture, it is. When I was a Senior Software Engineer at Millennium Pharmaceuticals, I began doing a little unofficial mentoring. I enjoyed it and decided to learn to become a manager. However, I didn’t want to leave engineering. I also didn’t want to stop being creative or stop building things, which I knew was the fate of many engineers who got their MBAs and went into management.

From what I’ve observed, in most traditional MBA programs it’s sort of expected that when you graduate you don’t go back to building stuff. That’s not only unfortunate, it’s also a widespread problem.

This is complicated by the fact that in order to advance in most companies – and to get more status and more money — you must manage people. This means spending time writing performance reviews, focusing on HR policy, and doing PowerPoints and Excel. The sad thing is that you’re probably still a terrific engineer and your organization is losing out by not utilizing your technical talents.

One of the sad consequences of this is that although companies hire young engineers who are really very good, after a very short time they say they want to be managing a team because they know that’s the only way to advance.

The SDM program was good for me because it taught me how to stay creative and keep building stuff while also being a manager. It’s part of the culture. Pat Hale, SDM’s director, shows it by example. He’s the director of an academic program, but he’s also President of the International Council on Systems Engineering. He’s hands-on; he’s not a pure academic, so he’s a strong power of example.

The SDM culture is also enhanced by the backgrounds of the students admitted into the program. They are early-to-mid-career engineers from a wide range of industries around the world who want to build as well as lead. These SDMs can create value at the intersection of engineering and management by leading, by doing, and by creating a culture that can advance by learning from experimentation, failure, and success.