Planning for the wrong kind of scale

Recently I wrote at length to my newsletter subscribers about some of the factors that went into my choice to move RubyTapas to a WordPress platform. Here’s a small excerpt from that letter:

Programmers love solving problems. The corollary is that we also love making problems.

When we’re faced with something which is obviously an old and oft-solved problem, our usual tactic for making new problems is to proclaim the existing solutions “too complicated”.

I just need to sell subscriptions, and only show content to subscribers. Simple! I don’t need one of these bloated, over-complicated pre-built systems.

Well, and let them upgrade and downgrade to different plans.

With proration, so they don’t get overcharged when they upgrade.

And dunning, so they don’t just get cut off when their credit card expires.

And I need to enable downloads for some users but not for others.

And I need to provide a way for users in countries with strict tax laws to put their VAT IDs on their receipts.

Which means I need proper receipts.

And I need categories. And tags. And series.

And an easy way to make some episodes into freebies.

And the episodes should show a nicely formatted social card when posted to Twitter or Facebook.

And… and… and…

Some people will gamely power through all of these feature adds and gotchas, one by one. And then one day, they’ll find themselves scaling up, and wanting to hire someone to do copy-editing on 400 archive posts. That exist in the form of Markdown files in a Github repo. And then they have to teach this new person to work within the constraints of a home-grown, cobbled-together system. And how to commit and re-deploy the site after each page is done.

I can easily imagine the first knee-jerk reaction a lot of developers will have to that snippet: are you seriously suggesting we should plan ahead for that scenario? That’s, like, the opposite of agile!

I sympathize, I do. I’m a big believer in doing the Simplest Thing That Could Possibly Work. I try to embrace the idea that You Aren’t Gonna Need It.

But no Simplest Thing is chosen in a vacuum. When Kent Beck, Ward Cunningham, and co. were coming up with those catchphrases, they weren’t choosing to work with raw machine code. Or a pile of transistors. They were doing The Simplest Thing in the context of a Smalltalk development environment. A Smalltalk environment is actually a rather complex thing. It operates at a higher level of abstraction than did most of the programming languages in common use at the time the Agile Manifesto was penned. The Pharo image on my desktop is a fork of a Smalltalk image that has been under constant development for over 30 years.

Yes, your next step should be the simplest thing that could possibly work. But you still have to choose your starting point. The foundation you’re building on.

What foundation is going to best support your likely future growth?

And don’t tell me you don’t think about future growth at all. We all do, even if we try to suppress the impulse and focus on the present.

Usually, when developers and developer-centric organizations plan ahead for growth, we plan for just one axis of growth: capacity. Number of users; number and frequency of requests; size of dataset.

We build with at least half an eye towards technical scaling for capacity. Even if we can’t support ROFLscale right now, we at least have an idea of what we’ll do if we ever have the need to.

But there’s another kind of scaling. One that’s a lot more pressing for most businesses: organizational scaling.

What’s going to happen when you hire someone else to administer the system? Are they going to have to edit enumerations in the code? Or ask a developer to do it for them?

What’s going to happen when you hire someone else to write copy? Are they going to have a workflow that blocks on a developer, or on an Operations person?

Speaking of Ops… what’s going to happen when you give that hat to someone else?

What about marketing? There are a lot of little tweaks your future marketing team is going to want to try out. Website copy. Email copy. Pricing. Pricing for specific types of lead.

They’re going to want to collect survey data using in-app forms correlated with user info. Are they going to have to come to you for every survey form? Or for every form integration?

How much code are you going to have to write to eliminate yourself as a bottleneck for those changes?

How about support? I know, you’re handling support yourself right now. But what happens when you turn that one over to someone new? Are they going to be emailing you every 5 minutes because they have zero visibility into the system? How will you have to modify the system to give them the insight and control they need in order to leave you alone?

As conscientious programmers we think a lot about writing code for the next developer. But how much time do you spend thinking about enabling other roles?

Markdown files in a Github repo are “simple” from the point of view of a developer. They may even be “simple” for a non-programming intern you train yourself. But are they “simple” for a marketing expert who needs to tweak copy and styling at the same time?

I’m going to say something challenging: if you’re not thinking about your code in this context, you’re not taking your business seriously.

I can say this, because looking back I can see ways i wasn’t taking my own business seriously by focusing on what was technically “simple”. And by insisting that if something was accessible and easy for developers, it was the right way to go.

Forget capacity concerns. Statistically speaking, you probably do not have an Instagram-scale unicorn on your hands. But if you experience any business success at all, you will need to scale your organization.

And that doesn’t just mean hiring more hackers.

Luckily, you can start thinking this way right now, even if you’re working solo.

I know, because I do. I’m at a point where I delegate some of my work, but I still don’t have any full-time employees. But I do wear different hats: Content creation. Project management. Business Strategy. Sales. Support. Operations. Marketing. And, oh yeah, development.

I know from experience that if I run into a roadblock while wearing the “marketing” hat, and have to put on my “developer” hat to fix it, I’m going to lose at least four hours of my day. That’s just the way it always seems to go. There’s always something that makes the code change not completely trivial. Often it’s an operational something: for instance, the other day when I realized that in order to push a new version of code, I also had to update my Heroku stack because the one I was using had gone obsolete.

There’s always something.

So these days, I’m a lot more sensitive to things that might force me to switch hats. And, conversely, I’m a lot more attracted to solutions which will enable me to keep a hat on uninterrupted. Even if those solutions are “heavier”. Or more opinionated and constraining in some ways. Or more expensive. Or more “boring”.

My advice, if you’re a tiny startup, a solopreneur, a just-established agency: Believe in your business. Believe in your capacity for growth. Believe there will be dozens of people under your roof (even if it’s a virtual roof) in a few years.

You don’t have to plan in detail for this scenario. That would be wasteful. But start believing that’s where you’re going to end up. And start thinking about your technologies and your processes in that context.

Start wearing different hats deliberately, and seeing how long you can stay in-character on before a technical problem forces you to put your hacker hat back on.

The wonderful thing is, this will make you more effective right now, even if it’s just you running the show. You’ll stop getting sidetracked so often. You’ll identify what parts of your processes vary, and what parts stay the same. As you spend more time removing programmer-you from the equation, you’ll discover early opportunities to delegate, either to part-time help or to external services.

So stop planning for capacity you might need someday, and start planning for the kind of scaling that will happen.