Sorry for the hiatus in writing. The book launch coupled with lots of travel at Butlr and helping some of my other companies in fundraising has made for a busy fall. a HUGE thanks to you all for supporting the book. As thrilling as it was to make it to bestseller on Amazon, it was as the same to learn that it’s being read at a Tufts class and in another entrepreneur’s book club.
I’ll be discussing One to Ten at TechStars Boston and at a Underscore Fireside Chat in the next couple of months and on the Revenue Engine and Purpose Driven Entrepreneur podcasts. Now on to regularly scheduled programming…
Sometime in late ‘99, or was it early ‘00, we at Live365.com were gearing up for a launch. It had started as a skunkworks project. One of our engineers was using some of our server space (yes we racked and stacked our own back in the day!) to host audio streams on the internet. He was using software from Shoutcast, whose parent company AOL had purchased, to stream the audio.
We ended up building a self-serve audio streaming service using this software, which quickly gained popularity. It was great to use the Shoutcast server but it was risky. AOL had purchased Nullsoft and we didn’t have clarity on their ambitions with regard to licensing. And we wouldn’t have roadmap control over such a critical part of the stack.
We decided to build our own server. This would be a key part of our big launch. But, as the weeks went by, it became clear that our engineering team was not up to the task. The tension built with heated debates flaring out. To no avail.
With days to go until our launch, one of the engineers on another team decided to step up. He cut himself off from the world and spent a long weekend coding up an audio streaming server on his own, eating and sleeping (but likely not showering) in the office during that time.
It worked! We shipped the product and celebrated his having saved the day. But his heroic efforts masked bigger issues in our product development process and people. Issues that we had to tackle in the ensuing months and quarters.
I can point to similar situations at every company since then. Heroism abounds at the early stages. The engineer that pulls all nighters to save the product launch, the FAE that MacGyvers the immature system to work on-site at the customer, the AE that pulls a rabbit out of her hat at the 11th hour to save the quarter.
And yet, you’ll need more than singular heroes to get to Ten and beyond. Heroes are needed when the regular team and system breaks down. Heroes should rightly be celebrated while, at the same time, be clear-eyed about the reasons that a hero was needed in the first place and what should be done to avoid this in the future.