Scale later

Starting a business is antithetical to scaling efforts.

Early in my career, 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 to do so.

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. 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. It was only later I understood: startups are optimizing a much different set of parameters.

As a young engineer that wants to hone these areas of excellence, it can be a very hard pill to swallow, intentionally setting aside engineering best practices. It's okay. 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.