PostHog Handbook Library / Company

568 words. Estimated reading time: 3 min.

# Team changes

There are three key principles here:

1. Anyone can propose a change by creating an issue suggesting the change.
2. Decisions should be made quickly – i.e. less than a week.
3. Team Blitzscale ultimately own the decision to make a change or not.

Complete consensus isn't necessary, but there should always be time for people to share feedback, and alternative solutions, before a decision is made.

We should never run lengthy consultations, or individual meetings with all those affected by a proposed team change, but a group meeting to make a final call can be useful provided you follow the process below first.

### How to propose a team change

Follow this process whether you're proposing creating a new team, splitting up an existing team, or even closing down a team.

#### 1. Create a team change proposal issue

You can use the team change proposal template in company internal to do so. A good proposal should:

- Tag all those directly affected by the change, and the Blitzscale Team member directly responsible for this area of the business.

- Include context about why you're suggesting the change and the goals you think this change will help us achieve.

- Be as concise as possible. This isn't an RFC, our goal is to make a quick decision.

#### 2. Share your proposal widely

Please share the issue in the relevant team Slack channels, the #team-blitzscale Slack channel, and any relevant public channels, requesting feedback.

It's generally best to post once and then forward that message to other relevant channels to keep things tidy.

Include the deadline for the decision in your message and tag the directly affected people.

Our goal is to make the best possible decision as fast as possible. When giving feedback, consider the following:

- Are there considerations the proposer isn't aware of that could impact the decision we make? Please share them and suggest solutions. Often these relate to feature ownership.

- Is there a better or alternative solution? Disagreeing with a proposal is fine, but it's always best to propose a solution than to just disagree without an alternative. If you think no change is necessary, explain why.

- Be direct and clear about how strongly you feel. If you're strongly against a change, explain why and make that clear. Likewise, if you're unsure about a change, but don't feel strongly, articulate that. Consensus is not our goal and decisions being blocked by people who are less invested in the outcome will slow us down and lead to worse decision-making.

#### 3. Share the final decision in Slack

The final decision should always be made by the relevant member(s) of the Blitzscale Team in a timely fashion.

Once made, they should share their decision in #tell-posthog-anything and the relevant team channels, alongside a short summary of why we're making that change.

#### 4. Execute the change

Once the decision is shared, the team lead kicks off execution by running `/org-change` in Slack and selecting the relevant change type. This creates a tracked issue with the right checklist, assigned to those involved.

### FAQ

#### What if I want to move teams?

This process exists purely for making larger changes to existing teams, or forming new ones, that impact multiple people. If you are personally looking to change team, see the small teams handbook page.

#### What happens after a decision is made?

This is covered on the small teams handbook page.

Canonical URL: https://posthog.com/handbook/company/team-changes

GitHub source: contents/handbook/company/team-changes.md

Content hash: `c9a1499c5e9b05d4`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: CalloutBox.