True or false: You’ve failed at something in your career before. If you answered false, well that’s a bit hard to believe, but it just means there is still plenty of time to fail. And that’s a good thing. At Commit we celebrate and support failure, as it is HUMAN and it ultimately means you have an opportunity to learn and grow.
To showcase that failure is not that big of a deal, we talked to three incredible technical wizards, Gokul Rajaram, Ivan Yuen, and Armon Dadgar about their failures at Facebook, Wattpad, and Hashicorp, respectively, and what they learned in the process.
Lesson #1: Don’t fixate on ideas or solutions—make sure you understand the “why” of the problem first.
Gokul Rajaram is currently a Board Member for Coinbase and Pinterest and acts as a Product and Business Helper at Doordash. He told us that one of his most interesting fails was at Facebook, where he was leading the advertising product team.
In 2012 they were feeling a lot of self-imposed pressure to ship products that grew revenue ahead of Facebook’s IPO. A large source of advertisers was FB Pages; he was doing Pages in addition to Ads when he realized Pages was not getting paid! This was an issue, as it could be a very simple and lightweight way to drive revenue and grow advertisers.
Gokul explains: “So, we said, ‘Well, to make it really simple, let’s build a subscription product.’ Because we felt that small businesses that liked Facebook Pages would pay a certain amount of money without having to worry about running campaigns. We focused on the subscription piece, and I think we got it wrong. As soon as we launched our product, our subscription product failed. I think out of the 20 million or 50 million pages back then, only 500 or maybe 5,000 used it.”
Within a month, most of them had turned it off and they realized it was a failure. They had been too focused on a very specific solution with this subscription, instead of the opportunity to make it simpler.
So, Gokul and his team said, “What are other ways to make it simple, without making it a subscription? We made a much simpler product, without a subscription. We recommended a budget, and we showed customers the impact, but they didn’t need a subscription.
The key lesson here is that when you fail, you have to operate in a hypothesis-driven way, and make sure you try to understand the ‘why.’ Many of us product engineering people get fixated on ideas or solutions.”
Learn more about Gokul’s career and advice in this article.
Lesson #2: Buy readily available technology that can help solve your problem so that you actually have the time to focus on building technology that differentiates you.
Ivan Yuen, founding CTO of Wattpad, said that in hindsight he would have made different technology decisions, but at that time his choices made sense.
Let’s get to the failure. Ivan explains:
“Wattpad has a pretty data-driven culture. Data collection, and being able to make an informed decision based on that, is very important. We realized early on that the analytics systems that were available at the time did not meet our needs. At the time the gold standard—and it’s still popular today—was Google Analytics, but it was very limited in terms of how it tracked users.”
They wanted to track a user through their lifecycle. To be able to capture information down to when they started reading, how quickly they were reading, where they started reading and where they stopped. There was nothing off the shelf available to do this six, seven years ago. So they thought, let’s build it.
Initially, building it wasn’t too difficult, Ivan says. “But the mistake we made was underestimating the effort to maintain that system and to update it based on their needs, to keep it state-of-the-art.” To make sure they could get value over a sustained period of time, they had to invest a lot of effort and continue to build and maintain that. They only looked at the upfront costs.
“Nowadays if we wanted the same thing, there’d be a number of off-the-shelf solutions,” Ivan says. “I think the lesson here is that if it’s something that’s readily available elsewhere, then they lean towards buying because we want to build things that are unique differentiators for us. If we were to build then we would have to maintain it, which adds to the operational burden over time.”
Find out more about Ivan’s journey and favourite technology in this article.
Lesson #3: Be diligent about asking all the right questions of the team you are leading before starting, otherwise things can get messy.
Armon Dadgar, co-founder and CTO of HashiCorp, told us that his biggest technical fail involved the company’s first big on-premise Terraform Enterprise customer. They were making the transition from a SaaS version, where they managed Terraform Enterprise until they wanted a self-host and on-premise. And it was a total cluster. There are so many different layers.
Armon explains: “There were product-level challenges and a huge amount of people-process issues—people ended up getting fired afterwards. There was an intermediate manager that he wasn’t managing directly anymore. So there was him, and a manager, and the team working on it—and he didn’t stay close enough to that team.
Every week we’d meet and do the readouts, and every week it was green, green, green—up until the week when we were going to go do the install at the customer’s site and it went red. How did we go from green every week to red?”
Once Armon investigated a bit further he realized the manager had not done a good job breaking out all the work items. They were making unrealistic assumptions about how much progress they were going to make. “You know, a classic 80-20 rule: 80 percent of the stuff takes 20 percent of the time and all of the hard stuff was back loaded to that last 20 percent. It was a huge flaming mess.”
They ended up having to push out the install for the customer. It took them two days to get the thing up and running on the customer’s site, as opposed to two hours. They ended up having to fire and reorganize that team, reset the entire product direction for how it worked.
There were a bunch of lessons in it, Armon says.
“One is that going from on-prem to SaaS or SaaS to on-prem is not trivial. Two: it was the first time I was in a director role. It was hard. I wasn’t close enough and hadn’t done enough diligence with the person I was managing, asking questions like, ‘Show me your timelines, show me the Gantt chart, show me all the sub-projects and how they’re tracking.’ I trusted that they had broken it out and were executing against it and I didn’t click one level deeper to verify that.”
Find out more about his ups and downs as a new founder in this article.
Part of failing is getting back up time and time again and learning from others along the way. Find out more about the Commit program and see how we can help you along your engineering journey, both the failures and triumphs.
###