A guide for admins setting up Hamster at a 10–50 person product org. Post-PMF, multiple product teams, engineers all using AI coding tools. Covers connecting a richer Context Graph, setting Direction with Goals, shaping the Initiatives that move them, and steering the Briefs Hamster drafts beneath each Initiative.
Under 10 people? How to use Hamster: Small teams is the right starting point. Want to try Hamster on a single Brief first without the setup? See Just ship.
Running Hamster across multiple teams
~3 minutes
Video coming soon
At this stage you typically have one Hamster workspace with multiple teams underneath — for example, "Growth", "Core Platform", "Mobile", "Marketing". Each team has its own Briefs, Plans, and deliveries; integrations and Cloud Agents live at the workspace level.
Walk through onboarding once with the founding admin, then invite the rest of the org. Invites start as Creator; switch non-builders and stakeholders to Reviewer when you invite them. Reviewers can view Briefs and Plans, comment, and vote on alignment. See Roles & permissions for the full role model.
Top tip: Send the Joining a team on Hamster guide to everyone you invite. It gets ICs (engineers, designers, stakeholders) oriented in 10 minutes.
A richer Context Graph is the single biggest difference between this stage and the small-team setup. The more your team has accumulated in real systems — Linear tickets, Figma frames, customer-call recordings — the more grounded the Blueprint Hamster generates and the better every Brief gets refined.
Connections worth investing in here:
.fig files and Figma URLs to Briefs so Hamster can use the designs while shaping the Plan.See Connections overview for the full list.
At this scale, most of your engineers already use Claude Code, Cursor, Codex, or similar. The biggest unlock for adoption is exposing your Context Graph, Briefs, Blueprints, and Methods inside the tool they already use.
Have each engineer install the Hamster plugin. Their AI coding tool then reads all of that directly, so they can ship a Brief from its slug or ask Hamster what's in an Initiative.
This is the path that makes engineers happy. They stay in control, ship from where they live, and get the team's accumulated context for free. Make sure it's a step in your engineering onboarding.
A Cloud Agent is the configured environment Hamster runs deliveries in when nobody's hands are on a keyboard — repo URL, env vars, build and test commands, runtime.
Cloud Agents complement the IDE flow rather than replacing it. They're how:
If your team has multiple repos shared across product teams, configure one Cloud Agent per repo. If you have multiple environments (e.g. staging-api and production-api), configure a Cloud Agent per environment.
Top tip: Creator, Admin, and Owner roles can change Cloud Agent setup and start deliveries; Reviewers cannot. Invite stakeholders as Reviewers and use the roles and permissions appropriate for each workspace.
At small-team scale, one Blueprint covers most of the product. At 10–50 people, you'll typically have multiple product surfaces — a web app, a mobile app, a public API, an internal admin tool — and each deserves its own Blueprint.
Hamster drafts first Blueprints from what you share and can draft new ones in chat. Spend a sprint reviewing and editing them. Each product team owns the Blueprint for the surface it ships into and treats it as the answer to "what is this surface today?"
When a Brief is marked done, Hamster proposes updates to the Blueprints it touched. Ask Hamster to fold in a new architecture document and it proposes the edits for your team to accept.
At 10–50 people, "what are we optimising for this quarter?" stops being obvious. Goals is where the answer lives, in a framework your team already speaks.
Pick the framework your team already uses — OKRs, North Star, HEART, OGSM, V2MOM, or AARRR — and Hamster speaks its language.
Attach a Metric to each measurable Goal — unit, Direction, target, optional baseline. Log Results per period; status (On Track, At Risk, Off Track) makes "off track" visible without anyone curating a deck.
Shape the Initiatives that could move your Goals — a quarterly bet, a launch, or a discrete strategic project. Where your framework supports Initiative links, connect them to the Goals they support. Initiatives become the middle layer between the outcome and the work.
Initiatives matter at this scale because:
Examples of Initiatives:
The pattern is Goal → Initiative → Brief → Plan. Once the team agrees on an Initiative, Hamster drafts each related Brief. PMs, leads, designers, and engineers steer the Brief, then Hamster generates its Plan; execs can stay at the Goal and Initiative level rather than reading every Brief. With Linear connected, bring Linear Initiatives into Hamster alongside that work.
The Discovery → refinement → Plan → Delivery loop is the same as it is for small teams. Spike code, ideate in Figma, ask Hamster to research a topic on the web, or whiteboard with your team; bring what you learn back to the Initiative and its related Brief. Each Brief aligns the team on one deliverable, then feeds its Plan.
What changes at this scale:
Hamster is the harness and automatically applies relevant Methods while shaping Briefs, generating Plans, and delivering work. Methods are optional components for customizing that harness with your team's conventions; they are not a setup gate.
When shared conventions emerge across teams, add them at the workspace level rather than maintaining a separate set per team.
Common additions teams make at this scale:
Top tip: Add "How we test" and "How we deploy" Methods when those conventions need to differ from Hamster's defaults.
Once you have multiple teams writing Briefs, the Brief list view is too noisy for status. The Initiatives view and the per-initiative timeline are the right surfaces for execs and stakeholders.
Every Brief has an activity timeline — every change to the Brief, every alignment vote, every Plan revision (including AI-driven revisions), every Delivery run. It's the audit log for one piece of work.
For non-builder stakeholders (sales, CS, ops, designers who aren't in Hamster every day), the Slack brief side panel renders the live Brief inline. They don't need to log into Hamster to stay in the loop.
When you cross 50 people or start running multiple product orgs, see How to use Hamster: Enterprise and scaling.