Worry about scaling later

While I worked at an early stage startup, I fought tooth and nail in design meetings to apply solid engineering principles to everything we did: scalability, extensibility, modularity, generalization, etc.

I was wrong.

I was attacking the problem from a different perspective, a perspective that would fare well in a large company with massive distributed systems — a company inherently optimizing for the long run. Startups, however, are not optimizing for the long run. They can afford to worry about that later. They need to solve for tomorrow.

This doesn’t mean you should throw your engineering principles away. They’re not inherently wrong; they are simply the wrong tool for the job, if you’re at a startup. You must realize that everything is a matter of compromise, and at a startup, you will be compromising more often than not.

Murali Krishnan, my manager at the time, got this right. I was often on the other side of the table, arguing for engineering excellence. I wasn’t yet wise enough to understand his side of the story. It was only later that I understood that startups are optimizing for a different variable.

As a budding engineer that wants to hone these areas of excellence, it can be a very hard pill to swallow, to intentionally set aside engineering best practices. Do your best to understand that you’re not optimizing for the long run. Not yet.

Don’t just take my word for it, though. An essay of Paul Graham’s inspired this post. An entirely worthwhile read.