The magic of small engineering teams
Small engineering teams at PostHog operate autonomously, focusing on specific products or functions. Each team has a leader, encourages collaboration, and aims for a flat hierarchy to enhance individual impact and innovation. Challenges include communication management and hiring alignment.
Read original article
The article discusses the benefits and structure of small engineering teams at PostHog, a startup aiming to maintain agility and innovation as it scales. The company organizes its 47 employees into 15 small teams, each focused on specific products or functions. These teams operate autonomously, running their own sprints and making decisions on features without external control. Each team has a leader responsible for performance, and team members are encouraged to take ownership and collaborate across teams. The small team structure aims to maintain a flat hierarchy, with minimal management layers and a focus on individual impact. While small teams offer speed and flexibility, they also come with challenges such as managing communication between teams, ensuring clear ownership, and hiring individuals who align with the collaborative and autonomous nature of the setup. The article emphasizes the importance of hiring the right people who can thrive in this environment and the need for transparency and clear communication to mitigate potential issues like overlap and fuzzy ownership.
Related
The 10x developer makes their whole team better
The article challenges the idea of the "10x developer" and promotes community learning and collaboration in teams. It emphasizes creating a culture of continuous learning and sharing knowledge for project success.
Software Engineering Practices (2022)
Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.
A dev's thoughts on developer productivity (2022)
The article delves into developer productivity, emphasizing understanding code creation, "developer hertz" for iteration frequency, flow state impact, team dynamics, and scaling challenges. It advocates for nuanced productivity approaches valuing creativity.
Bad habits that stop engineering teams from high-performance
Engineering teams face hindering bad habits affecting performance. Importance of observability in software development stressed, including Elastic's OpenTelemetry role. CI/CD practices, cloud-native tech updates, data management solutions, mobile testing advancements, API tools, DevSecOps, and team culture discussed.
The magic of small engineering teams
Small engineering teams at PostHog, a startup, operate autonomously in 15 groups, focusing on specific tasks. Teams have leaders, encourage collaboration, and prioritize individual impact, despite tradeoffs like potential overlap.
12 commentsThe post starts out by assuming this but I am not convinced this is true along the entire graph, if the x axis is amount of people on a team and the y axis is amount "shipped". As a company scales output, at some point in this graph the output per person from the large team should overtake the small team, otherwise why do we even have large teams in the first place? How do large teams form if not from necessity? Seems they are advocating for small one pizza teams working together in tandem at scale? Because that's essentially the way I've seen it done everywhere I've ever worked and it isn't a new idea, and what you have at the end of that is a larger unit that definitely constitutes a "department" and a "large team" even if the large team consists of several small teams. The communication overhead there can get extremely complex as well.
This is … interesting. I can hear every scrum master course leader crying but I like it.
On the other hand, measuring impact in the real world is a vital task - but yeah it’s a lot easier to say “Inwill build a car” than “I will drive the user to a football game once I have built a car”
Not Posthog is a technically much more challenging product and is more geared towards developers and yet in terms of ARR it is at 10 million whereas Stan.Store which is basically link in bio + a very basic store is doing 25 million ARR.
Goes to show, selling to developers is really hard. Hopefully Posthog makes it in the long term, but graphing time spent vs returns, something like Stan.Store will make the founder + investors a lot more money in a shorter time period.
But I’m also sick of hearing how these teams can “ship” so fast. Yeah you can ship, you have no customers. No users, no SLAs, no employees. Good work, you just did whatever you wanted and then typed “git push” to a repo you control, with standards you control, and a build process you control. Wow those stodgy big co’s could learn something from you!
This is a similar convo to “why use Kubernetes”. Do you have one binary and one database with one password? Go nuts with your single VPS and bash scripts and keep telling yourself that everyone is over complicating it. But are you scaling? You’ll probably need some orchestration. You’ll probably need some managers, a ticket system, on-call, standard build tools. Documentation.
Scaling to billions with a team of 20 is a fantasy achieved only by the select few. As always it is a fine line companies should tread lightly. Don’t rush to hire, but don’t be afraid of it either. Focus on scaling intentionally and carefully.
Yet the image has 6 gophers.
Related
The 10x developer makes their whole team better
The article challenges the idea of the "10x developer" and promotes community learning and collaboration in teams. It emphasizes creating a culture of continuous learning and sharing knowledge for project success.
Software Engineering Practices (2022)
Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.
A dev's thoughts on developer productivity (2022)
The article delves into developer productivity, emphasizing understanding code creation, "developer hertz" for iteration frequency, flow state impact, team dynamics, and scaling challenges. It advocates for nuanced productivity approaches valuing creativity.
Bad habits that stop engineering teams from high-performance
Engineering teams face hindering bad habits affecting performance. Importance of observability in software development stressed, including Elastic's OpenTelemetry role. CI/CD practices, cloud-native tech updates, data management solutions, mobile testing advancements, API tools, DevSecOps, and team culture discussed.
The magic of small engineering teams
Small engineering teams at PostHog, a startup, operate autonomously in 15 groups, focusing on specific tasks. Teams have leaders, encourage collaboration, and prioritize individual impact, despite tradeoffs like potential overlap.