entangling exuberance
talks   experiments   about  
Scale your org, tech will scale.
Apr 19, 2022 • 3 minutes

Teams

Scaling org, scales the tech naturally, here are few tips to scale the org.

Scaling a startup after finding “product-market-fit” (PMF) is a sudden task; you don’t prepare yourself for it, but instead, it just happens out of the blue, one day, you wake up, and there are tons of users. No one knows how to serve them. NO ONE! Experienced founders understand that what it takes to scale the product, it takes an excellent scaled-up organization to scale the product, not vice-versa.

Scaling tech is directly related to scaling the org, we try to scale the technology, without putting proper thoughts in how to scale the org. If you scale the org, making sure that all the functions work smoothly, you need to focus on communication, collaboration and conversations. But when our teams become big, we can’t really have conversations with everyone, so we start replacing them with some processes, habits and rituals. Over the years, I learned it hardway, that scaling the org is about removing frictions from people’s daily routine life, we can do many things, but this can be a daunting task, we certainly need to make it a vocation, and we can take it as full-time responsibility, the well-oiled machine. Recently I asked on Twitter what it takes to scale up an organization, and I found some answers; I added a few of mine. Here you go…

Making a ritual is the easiest way to get everyone on board. Weave these things into cultural traditions. These become first-class tenets of your organization and thus result in a frictional less experience in scaling the org. There are many more engineering-specific, product planning-specific tips, but these are the ones I especially like. I may write more about deeper topics such as “Why we shouldn’t do PRs” or why “Engineering metrics should be business metrics” for some more time to come.

There are many more engineering-specific, product planning-specific tips, but these are the ones I especially like. I may write more about deeper topics such as “Why we shouldn’t do PRs” or why “Engineering metrics should be business metrics” for some more time to come.

Share