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…

• Get recruitment right, put a rough outline for the process, and have metrics around response time to candidates.
• Showcase what you do. People call it branding; I call it “being a performer.”
• Write down your first principles on code, product, and documentation - what do you like?
• Have a mental model about build/buy/outsource, recommended default, buy everything, optimise for time.
• Automate everything, including QA
• Figure out career paths, objectively tell people that you must know “this” in your skillset to earn your promotion.
• Make sure your alums are your ambassadors.
• More Emphasis on written docs.
• Bring a checklist driven culture, kind of point and tell (Japanese metros are a good example)
• Metrics - uptime is a business metric, product metric - everyone must not push features and timelines if that impacts uptime. Same way, business metrics should become engineering metrics
• Publish your metrics every day; that helps everyone understand the journey, growth and progress for product and business.
• Make sure everyone in the org spends at least one week a quarter as a customer service agent, that inculcates product empathy.
• Don’t do PRs - an open-source development model operates on distributed, async, extended turn-around time mode.
• Trust by default allows more autonomy to flow through the org fabric, and more responsibility gets weaved in the cultural fabric. It means many things, including the following…
  • everyone gets to see the business performance metrics,
  • everyone gets to commit to trunk,
  • everyone gets to deploy to production,
  • everyone gets to make a call when to deploy,
  • product managers get to choose A/B testing and segmentation for users,
• Make people-friendly policies, but ensure everyone understands the difference between privilege and right. Apart from salary is a privilege - you get that because you work here.
• Be data-driven
• Stay focussed on Outcomes over output.

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.