Building your own storage startup: Whatever you do, don't let lead dev be CEO

Part Two You like the idea of “doing” a startup, but what about actually starting a startup? You can see the end point - success, hopefully - but what of the hoops and hurdles?

In part one, I looked at funding, executives and staff. But now you’ve got the money and the people, what happens next? What about team composition and product?

The subject of who should comprise your core team is a hotly debated one. It's worth pointing out that I'm just a Canadian nerd and I haven't gotten rich doing any startups. Other people who have actually played the game (and won!) disagree and their views should be considered.

Jeff Ready, CEO of Scale Computing, offers the following thoughts: "On your original startup team of three, there is no sales person. Perhaps this is implied in your Gladhander, although you already have them doing quite a bit. I would take a salesperson over a tech marketer in that initial group all day long. One, because I can write the marketing stuff myself if I need to, but more importantly because customers are the key to the future funding."

John Smith, (pseudonym I'm using in this series for the marketing director of the largest tech companies in the world) offers similar advice: "The biggest one is that I am not convinced of the criticality of the tech writer in the formative stages. In my experience, the key is the Kickass Developer and the Gladhander, the latter of whom serves as the tech writer early on. In order to keep things skinny, the Gladhander typically does the schmoozing and creates the messaging and similar related content for the investors while the Kickass Developer focuses on the plumbing."

Here I feel I must poke my head in to these excellent comments. They aren't wrong: sales is absolutely critical. In fact, I view this as a key function of Gladhander: schmoozing those as need to be schmoozed and gladhanding the high rollers.

I think a CEO who can talk Venture Capitalist, sell things and crack the whip over the employees is a much easier-to-find combination than a CEO who can talk Venture Capitalist and write decently. I've encountered plenty of CEOs who could sell snow to an Inuit. On the other hand, I literally wouldn't have a roof over my head if most CEOs (or marketing VPs) were intelligible at the keyboard. Converting CxO into human is my day job.

An anonymous senior vice president at a one storage startup, who I will call John Johnson, had this to add: "There are almost always at least a couple developers. The other key to the early core of the company is you need people with cross-functional skills. Product manager / developers / content creation (slide decks are critical) / pitch person / business development (relationship person with the rolodex) / channel expert (most startups these days work with channel partners) skills all need to be included in that core team."

Ugly babies

Do not let Kickass Developer be CEO. Do not do. By this I am not advocating that CEOs can't be engineers or developers, but rather that the CEO can't be the lead developer of the product this startup is working on.

The problem is that a huge part of the early life of a startup is seeking and incorporating feedback. Many experts I reached out to pointed out that they would seek out potential early customers before ever considering putting together money for a startup and this must continue for years if success is to be achieved.

This process of engaging with customers will lead to changes in the design of the product. If the product is the CEO's baby, there's a problem. Nobody likes being told their baby is ugly and when the person in charge is emotionally invested in a specific solution, startups usually fail.

Again, there are exceptions. Dheeraj Pandey, CEO of Nutanix explains, "I couldn’t relate to the Gladhander. As a CEO, I wrote a ton of code. Every partnership is different, you know. Just like a family – parents, siblings, etc, and making money is the last reason why people build sustainable companies. The biggest reason relates to the “right brain” – autonomy and an elusive desire to change the world."

As one storage VP puts it: "the delicate balancing act of early startup life. Too much passion and there is an argument and a critical team member leaves. No enough passion and the plane flies into the side of the mountain. Too much debate and the product never ships. Not enough debate and the plane flies into the side of the mountain."

With the who and how of starting our startup sorted, let's take a break from people and politics and dive into what the potential technology of our startup might look like.

Tech 1.0

Before any of the funding or shenanigans above, you need an idea for a product. As we're designing a storage startup, I'll lay out a storage product. To design this product, I'm mooshing together ideas from dozens of storage startups alongside my own, so I'm sure lots of folks will see something of their own startup reflected in this design.

In a perfect world we want to build a storage solution that meets all needs for all people. Everyone else will simply stop using the competition because ours is so awesome. Boiling the ocean, however, never works as a starting proposition, so we'll focus on one primary problem.

NVMe is all the rage, and faster is typically better, so the core goal will be to build a storage product that goes really fast and takes advantage of what NVMe has to offer. NVMe is good for fast storage primarily because of high queue depth.

Let's start with the new Intel Broadwell-based Xeon-Ds with integrated FPGA. Customize the FPGA for your high I/O workloads. This can help get around the part where NVMe is really, really CPU intensive. Get a NIC that can handle offloading without imploding in order to also drive CPU usage down. Pack it all into one of Supermicro's 48 drive NVMe chassis and slap your brand on it.

As part of your sexy software you build a scale-out storage solution similar to Coho or Solidfire so that you can handle not only failure of the device, but failure of (at least) a node. Let's say it's object based and allows for n copies of an object.

Qualify a good switch as part of the solution, one that can handle multicast really well. Use multicast for transmitting reconvergence data and other inter-node communications. This makes rebuilding of nodes easy and low-impact, even with huge NVMe setups. The rebuild stress ends up shared equally across the cluster, but the whole of the cluster doesn't have to play silly buggers trying to figure out who is doing what. The good switch is necessary because cheap switches are pants at multicast, and you're going to need every scrap of networking you can eke out.

Build locality awareness into the storage platform and make sure any node can serve up storage. If you have a 32-node cluster, use 16 virtual IPs so that when you assign storage to a requestor they can not only manage to load balance requests across the whole of the cluster, but the cluster can make sure that the assigned storage has replicas physically on the nodes responding to the storage request.

Most of this can be done by welding together various open source projects. As a 1.0 to prove viability to an angel investor that very well might be good enough, assuming you can demonstrate that you have identified pain points and have a solid roadmap for replacing some (or all) components by A round. You need something to patent, and the investor doesn't want to pay you to make a startup anyone can come along and clone.

Be wary of other startups! As I discussed above, this design – like every storage startup – is taking elements from various existing companies' products*. Make sure you know who has patented what, and you work around that. Get Gladhander to earn their keep!

Knowing what you want to build, however, is not enough. You need to be able to build it in stages, monetize it at different points, and have some idea of how you will handle investors, staff, partners, community and politics.