<aside> <img src="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/7f34524d-9389-4bb8-b803-8796988dd464/Web_logo_(256__256px)_(2).png" alt="https://s3-us-west-2.amazonaws.com/secure.notion-static.com/7f34524d-9389-4bb8-b803-8796988dd464/Web_logo_(256__256px)_(2).png" width="40px" /> What we love about this handbook section
🖤 We talk a lot at Open org about Manager : IC ratio. It’s important to many people to understand how companies approach team size, management and structure and there isn’t typically enough attention paid to this, but it’s integral to working culture, particularly so for Engineering & Product teams it seems. Giving some light to this like Posthog do can be really powerful.
****Check out their entire handbook for inspiration here: 🔗Posthog's full handbook
</aside>
Last updated:Â Jan 11, 2023
|
PostHog is structured for speed, autonomy and innovation.
Many traditional organizations have big, separate functions. You have a product team, an engineering team, customer support, and so on. This slows things down when you scale because there are more layers of communication and complex approval chains. This stifles innovation - you have to get your boss to talk to someone else's boss to get work done. It also means that people can't really see the impact of their work.
PostHog started off as a completely flat company with one big goal: to increase the number of successful products in the world.
As we are getting bigger, we anticipate that it will get harder for people to see the direct impact of their work, which reduces the sense of ownership.
We have therefore introduced Small Teams. These are designed to each operate like a startup.
_(2).png){kind=link}