This post by Backblaze’s CEO and Co-founder Gleb Budman is the seventh in a series about entrepreneurship. You can choose posts in the series from the list below:
- “How Backblaze Got Started: The Problem, the Solution, and the Stuff in Between”
- “Building a Competitive Moat: Turning Challenges Into Advantages”
- “From Idea to Launch: Getting Your First Customers”
- “How to Get Your First 1,000 Customers”
- “Surviving Your First Year”
- “How to Compete With Giants”
- “The Decision on Transparency”
- “Early Challenges: Managing Cash Flow”
- “Early Challenges: Making Critical Hires”
“Are you crazy?” “Why would you do that?!” “You shouldn’t share that!”
These are just a few of the common questions and comments we heard after posting some of the information we have shared over the years. So was it crazy? Misguided? Should you do it?
With that background I’d like to dig into the decision to become so transparent, from releasing stats on hard drive failures, to Storage Pod specs, to publishing our cloud storage costs, and open-sourcing the Reed-Solomon code. What was the thought process behind becoming so transparent when most companies work so hard to hide their inner workings, especially information such as the Storage Pod specs that would normally be considered a proprietary advantage? Most importantly, I’d like to explore the positives and negatives of being so transparent.
Sharing Intellectual Property
The first “transparency” that garnered a flurry of “why would you share that?!” came as a result of us deciding to open-source our Storage Pod design: publishing the specs, parts, prices, and how to build it yourself. The Storage Pod was a key component of our infrastructure, gave us a cost (and thus competitive) advantage, took significant effort to develop, and had a fair bit of intellectual property: the “IP.”
The negatives of sharing this are obvious: it allows our competitors to use the design to reduce our cost advantage, and it gives away the IP, which could be patentable or have value as a trade secret.
The positives were certainly less obvious, and at the time we couldn’t have guessed how massive they would be.
We wrestled with the decision: prospective users and others online didn’t believe we could offer our service for such a low price, thinking that we would burn through some cash hoard and then go out of business. We wanted to reassure them, but how?
This is how our response evolved:
|We’ve built a lower cost storage platform.|
|But why would anyone believe us?|
|Because, we’ve designed our own servers and they’re less expensive.|
|But why would anyone believe they were so low cost and efficient?|
|Because here’s how much they cost versus others.|
|But why would anyone believe they cost that little and still enabled us to efficiently store data?|
|Because here are all the components they’re made of, this is how to build them, and this is how they work.|
|OK, you can’t argue with that.|
Great, so that would reassure people. But should we do this? Is it worth it?
This was 2009, we were a tiny company of seven people working from our co-founder’s one-bedroom apartment. We decided that the risk of not having potential customers trust us was more impactful than the risk of our competitors possibly deciding to use our server architecture. The former might kill the company in short order; the latter might make it harder for us to compete in the future. Moreover, we figured that most competitors were established on their own platforms and were unlikely to switch to ours, even if it were better.
A Sharing Success Story: The Backblaze Storage Pod
So with that, we decided to publish everything about the Storage Pod. As for deciding to actually open-source it? That was a “thank you” to the open-source community upon whose shoulders we stood as we used software such as Linux, Tomcat, etc.
With eight years of hindsight, here’s what happened:
As best as I can tell, none of our direct competitors ever used our Storage Pod design, opting instead to continue paying more for commercial solutions.
- Hundreds of press articles have been written about Backblaze as a direct result of sharing the Storage Pod design.
- Millions of people have read press articles or our blog posts about the Storage Pods.
- Backblaze was established as a storage tech thought leader, and a resource for those looking for information in the space.
- Our blog became viewed as a resource, not a corporate mouthpiece.
- Recruiting has been made easier through the awareness of Backblaze, the appreciation for us taking on challenging tech problems in interesting ways, and for our openness.
- Sourcing for our Storage Pods has become easier because we can point potential vendors to our blog posts and say, “here’s what we need.”
And those are just the direct benefits for us. One of the things that warms my heart is that doing this has helped others:
- Several companies have started selling servers based on our Storage Pod designs.
- Netflix credits Backblaze with being the inspiration behind their content delivery network servers.
- Many schools, labs, and others have shared that they’ve been able to do what they didn’t think was possible because using our Storage Pod designs provided lower-cost storage.
- And I want to believe that in general we pushed forward the development of low-cost storage servers in the industry.
So overall, the decision on being transparent and sharing our Storage Pod designs was a clear win.
Sharing An “Almost Acquisition”
Acquisition announcements are par for the course. No company, however, talks about the acquisition that fell through. If rumors appear in the press, the company’s response is always, “No comment.” But in 2010, when Backblaze was almost, but not acquired, we wrote about it in detail. Crazy?
The negatives of sharing this are slightly less obvious, but the two issues most people worried about were, 1) the fact that the company could be acquired would spook customers, and 2) the fact that it wasn’t would signal to potential acquirers that something was wrong.
So, why share this at all? No one was asking, “Did you almost get acquired?”
First, we had established a culture of transparency and this was a significant event that occurred for us, thus we defaulted to assuming we would share. Second, we learned that acquisitions fall through all the time, not just during the early fishing stage, but even after term sheets are signed, diligence is done, and all the paperwork is complete. I felt we had learned some things about the process that would be valuable to others that were going through it.
As it turned out, we received emails from startup founders saying they saved the post for the future, and from lawyers, VCs, and advisors saying they shared them with their portfolio companies. Among the most touching emails I received was from a founder who said that after an acquisition fell through, she felt so alone that she became incredibly depressed, and that reading our post helped her see that this happens and that things could be OK after. Being transparent about almost getting acquired was worth it just to help that one founder.
And what about the concerns? As for spooking customers, maybe some were—but our sign ups went up, not down, afterward. Any company can be acquired, and many of the world’s largest have been. That we were being both thoughtful about where to go with it, and open about it, I believe gave customers a sense that we would do the right thing if it happened. And as for signaling to potential acquirers? The ones I’ve spoken with all knew this happens regularly enough that it’s not a factor.
Sharing Strategic Data
For years people have been desperate to know: How reliable are hard drives? They could go to Amazon for individual reviews, but someone saying “this drive died for me” doesn’t provide statistical insight. Google published a study that showed annualized drive failure rates, but didn’t break down the results by manufacturer or model. Since Backblaze has deployed about 100,000 hard drives to store customer data, we have been able to collect a wealth of data on the reliability of the drives by make, model, and size. Was Backblaze the only one with this data? Of course not—Google, Amazon, Microsoft, and any other cloud-scale storage provider tracked it. Yet none would publish. Should Backblaze?
Again, starting with the main negatives: 1) sharing which drives we liked could increase demand for them, thus reducing availability or increasing prices, and 2) publishing the data might make the drive vendors unhappy with us, thereby making it difficult for us to buy drives.
But we felt that the largest drive purchasers (Amazon, Google, etc.) already had their own stats and would buy the drives they chose, and if individuals or smaller companies used our stats, they wouldn’t sufficiently move the overall market demand. Also, we hoped that the drive companies would see that we were being fair in our analysis and, if anything, would leverage our data to make drives even better.
Again, publishing the data resulted in tremendous value for Backblaze, with millions of people having read the analysis that we put out quarterly. Also, becoming known as the place to go for drive reliability information is a natural fit with being a backup and storage provider. In addition, in a twist from many people’s expectations, some of the drive companies actually started working closer with us, seeing that we could be a good source of data for them as feedback. We’ve also seen many individuals and companies make more data-based decisions on which drives to buy, and researchers have used the data for a variety of analyses.
Backblaze blog analytics showing spike in readership after a hard drive stats post
Sharing Revenue (and Other Metrics)
Journalists always want to publish company revenue and other metrics, and private companies always shy away from sharing. For a long time we did, too. Then, we opened up about that, as well.
The negatives of sharing these numbers are: 1) external parties may otherwise perceive you’re doing better than you are, 2) if you share numbers often, you may show that growth has slowed or worse, 3) it gives your competitors info to compare their own business to.
We decided that, while some may have perceived we were bigger, our scale was plenty significant. Since we choose what we share and when, it’s up to us whether to disclose at any point. And if our competitors compare, what will they actually change that would affect us?
I did wait to share revenue until I felt I had the right person to write about it. At one point a journalist said she wouldn’t write about us unless I disclosed revenue. I suggested we had a lot to offer for the story, but didn’t want to share revenue yet. She refused to budge and I walked away from the article. Several years later, I reached out to a journalist who had covered Backblaze before and I felt understood our business and offered to share revenue with him. He wrote a deep-dive about the company, with revenue being one of the components of the story.
Sharing these metrics showed that we were at scale and running a real business, one with positive unit economics and margins, but not one where we were gouging customers.
Should You Share?
For Backblaze, I believe the results of transparency have been staggering. However, it’s not for everyone. Apple has, clearly, been wildly successful taking secrecy to the extreme. In their case, early disclosure combined with the long cycle of hardware releases could significantly impact sales of current products.
I will argue, however, that for most startups transparency wins. Most startups need to establish credibility and trust, build awareness and a fan base, show that they understand what their customers need and be useful to them, and show the soul and passion behind the company. Some startup companies try to buy these virtues with investor money, and sometimes amplifying your brand via paid marketing helps. But, authentic transparency can build awareness and trust not only less expensively, but more deeply than money can buy.
Backblaze was open from the beginning. With no outside investors, as founders we were able to express ourselves and make our decisions. And it’s easier to be a company that shares if you do it from the start, but for any company, here are a few suggestions:
- Ask about sharing: If something significant happens—good or bad—ask, “Should we share this?” If you made a tough decision, ask, “Should we share the thinking behind the decision and why it was tough?”
- Default to yes: It’s often scary to share, but look for the reasons to say “yes,” not the reasons to say “no.” That doesn’t mean you won’t sometimes decide not to, but make that the high bar.
- Minimize reviews: Press releases tend to be sanitized and boring because they’ve been endlessly wordsmithed by committee. Establish the few things you don’t want shared, but minimize the number of people that have to see anything else before it can go out. Teach, then trust.
- Engage: Sharing will result in comments on your blog, social, articles, etc. Reply to people’s questions and engage. It’ll make the readers more engaged and give you a better understanding of what they’re looking for.
- Accept mistakes: Things will become public that aren’t perfectly sanitized. Accept that and don’t punish people for oversharing.
Building a culture of a company that is open to sharing takes time, but continuous practice will build that, and over time the company will navigate its voice and approach to sharing.