« swipe left for tags/categories
swipe right to go back »
Every successful startup goes through it. I got a note from a friend yesterday in response to an email I sent him about one of his startups where I said “feature X should be a no-brainer to implement.” He responded “One of my concerns is that much of the focus at YYZ for the past three months has been on reliability and scalability and that has caused them to get behind on features.”
Every single successful (and many of the unsuccessful) web-based companies I’ve been involved with have had this experience. You come out of the gate strong with a cool new web service, get some users, add features, hit a seam and get popular, and then spend almost all of your time and energy trying to build out your infrastructure so you can scale. There’s nothing new about this phenomenon – I can cite plenty of examples dating back to the mid-1990’s.
Your now very popular system falls over regularly. Feature constipation sets in and for a while new feature development ceases. All of your engineering discussions are about “scale.” If you’ve raised VC money, your board meetings are increasingly annoying as your VCs keep asking silly questions like “when are we actually going to have have neat feature X, Y, and Z.” If it goes on for too many months, VC frustration sets in, your CTO and VP Engineering (or VP Ops – or whatever title you gave him) gets increasingly stressed out, and you (assuming you are the CEO) start to feel your head spinning around in circles.
It’s a curse and a blessing (at least you’ve got a popular child.) I’ve met very few CEO’s and CTO’s that know how to build scale behind the scenes in parallel with the growth of their business, especially since the slope of one of the curves (user adoption) is an unknown until it happens.
Occasional constipation is a reality of life.