The Constipation of Scale

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.

  • Implementation and scalability of customer service (the area where I tend to focus) also suffers from this phenomenon and for essentially the same reasons. Sometimes it’s even tougher because of the challenge of scaling the human factor involved in providing service and support.

    Although no cure in itself, I find one mitigating factor is to think through the scalability issues early on rather than waiting for the pain to set in.

    Of course it’s not justifiable to build out infrastructure too early. And it may not be predictable exactly when the infrastructure is needed. It IS possible to reasonably predict what the markers look like for when it’s time to get started and to have a rough plan already in place for how to proceed.

    I figure it’s sort of like predicting the weather (another specialty, albeit ‘former’) – it’s usually timing that’s challenging, not the sequence of events.


  • Jason

    Do you think these companies should have worked on scalability earlier? Or should they just have been more upfront (with themselves perhaps) about the high cost of making their product/service scale after it became popular?

    Obviously the situation is different for every startup, but it seems like a popular product that doesn’t scale yet is better than a high-performance product that nobody uses.

    If you can have both, that’s great, but I’m not sure it’s even a good idea to spend that much time on scalability and performance until you absolutely have to. Any additional features or design refinements that are developed early in exchange for deferring scalability could make or break the demand for what you’re building.

  • There are two strategic technical problems that companies face when dealing with scale.

    The first is that all the chatter about a Multicore Crisis is true, but it is much worse. We don’t have 10 years to figure out the right tools and techniques for multicore because most people have already encountered a Multicore Crisis and just didn’t know it:

    The second strategic technical problem is the tremendous waste that goes into most programming. At least 70% of the code that is written is wasted because it contributes no proprietary advantage. Instead, it is just reinvention of wheels. There are a lot of reasons for this, but if you can free up even a little of that 70% it allows much more focus on things like scalability and features:

  • Adam Messinger

    I’ve observed that part of the frustrations around this are that the scaling factors change when widespread customer adoption begins. Product development effort, which scales with the number of features, becomes dominated by customer related effort which scales with the number of users.

    VCs should see this as a good sign because it means that the thing is actually getting used. The effect of it on development cycle can be ameliorated by dividing the engineering team into two groups, one focussed on customer care and the other on new product development. It is the context switching between the two costs which really eats into productivity.

  • The only way I’ve been able to manage this is to add features that aren’t dependent on the core architecture, whilst the underlying changes are going on in parallel.

    Can you add more content to the site? Change the graphical look? Add more cosmetic doodads? Chances are that there’s some changes that are so cosmetic that from an engineering POV they don’t seem like features, but they sure seem like improvements to the user.

    That buys you some time, and helps you avoid ‘going dark’ to your users, or all the other new stakeholders!

  • @Jason – there is no easy answer. There are very few young companies that manage the tension between scale and functionality well. As companies get more mature, they tend to figure it out with an occasional major burp. As I said in my closing, “occasional constipation is a fact of life.”