Why all startups should embrace Small Teams

[jtemperton]

Summary

We've got a great handbook entry on small teams and this social post from James did well and got some good comments. Idea is to have an upcoming issue of the newsletter that explains the what and the why. basically: what are small teams, why do they work so well, what we've learned. Working on research and reading now and starting a draft.

Where will it be published?

select any that apply

• Blog
• Founders Hub
• Newsletter
• Product engineers Hub
• Tutorials
• Other (please specify)

Why type of article is this?

select any that apply

• High intent (i.e. comparisons and similar)
• Brand / opinionated (how we work and why, etc.)
• High-level guide (concepts, frameworks, ideas, etc.)
• Low-level guide (step-by-step guide / tutorial)
• Other (please specify)

Who is the primary audience?

Select any that apply

• Founders
• Engineers
• Growth
• Marketing
• HackerNews
• Existing PostHog users
• Potential PostHog users

Will it need custom art?

• Yes
• No

[andyvan-ph]

+1 to a post on small teams as a concept, but I'd reframe it around how our small teams work and why we chose that structure. Saying "all startups" should it. If we wanted to be a bit baity we could go with something like "the secret to shipping really fast" and then hook that on the small teams structure.

[andyvan-ph]

Moving this priority as I think this is an obvious one we should do. 👍

[jtemperton]

Got it! Will work on a more detailed outline and share that soon.

[jtemperton]

A bit more of an outline based on that feedback...

The secret to shipping really fast

The pitch

Startups ship more stuff per person than big companies. At PostHog, we ship fast even for a startup. How? Small Teams. Each Small Team is designed like its own startup. This is how it works, why it works, and why it's important.

The sections

Each of these will cover the who, what, where, when, why, with specific examples and takeaways.

• Teams are actually small
• Each team has a leader
• Each team is totally transparent (responsible for its own retros, standups, sprints)
• Each team is responsible for for what features go into production (no need for external QA, approval, buy-in, etc)
• Each team is responsible for its own metrics and is able to set pricing
• Each team is responsible for talking to users and documenting what they build publicly

[jtemperton]

@andyvan-ph draft of this is here for feedback, no rush unless we want it for the next newsletter slot in which case there's a moderate rush: https://docs.google.com/document/d/1L53dTooJur8j5QXRSTmdulnZ2seVg3RXjAek5uBMIG8/edit?usp=sharing

[jtemperton]

Draft here for feedback #8550