D & I planning proposal

[fuziontech]

Proposal for how D&I team does planning

The primary goals planning for what we work on in the next sprint are:

• Unblocking ourselves and other teams
• Working towards company goals

Priorities for how this team wants to conduct prioritization.

Our process should promote:

• Autonomy
• Ownership
• Responsibility

Our process should avoid:

• Diffusion of responsibility
• Duplication of work and effort
• Ambiguity internally to the team and externally

Guidelines for what you should have done before our planning meeting (Wednesdays)

• All issues you own have a priority (if not sure propose as a meeting topic)
• All issues you own are in appropriate sections on the project board (backlog, priorities, in progress) you think they should belong to (again you can propose it as a meeting topic)
• Read the context for all unowned issues, so we're all ready to discuss it in the meeting. Feel empowered to claim the issue. If someone else wants the ticket then hash it out in the ticket or propose as a meeting topic
• Propose discussion/meeting topics in our team's sprint planning ticket (currently manually created on Mondays by Tiina), so others can prep if they want to & maybe close some of them async

Owning a ticket means that it is assigned to you. If there are multiple people assigned to the ticket work with the other owners to split it into smaller tasks so that you take ownership of a chunk of that ticket.

What makes a good ticket?

• One owner
• Prioritized relevant to the current company goals/priorities
• Does not include work that extends beyond one sprint. If it does it should be labeled EPIC and have sub tasks with owners
• Is on the board in the appropriate sections on the project board (backlog, priorities, in progress)

How to communicate team's priorities and commitments

• The project board should be the source of truth for what we are working on and what we are committed to working on
• Any other team or team member should be able to check out the project board to see what is currently getting worked on and who is working on it. Please feel encouraged to tell us if we got our priorities wrong by commenting on the tickets.

How do we know what the company priorities are?!

• This should be a product of the PostHog News / Monday morning meetings with Tim and James. If there are any pressing priorities or changes in priorities they should be communicated & documented from there.

Discussion / Motivation

I am a believer in autonomy and honestly the netflix style. We hire the best - I trust that everyone here is able to manage themselves and their work. This also fits better with our remote/distributed team topology where autonomy will enable people to move faster vs wait for context from a team member or team lead in another timezone. I also believe the best engineers do their best work when they are in control. This should also scale well as we scale out. The scope of work will be different, but the process should still be relevant based on the charter, scope, and goals of the team.

[macobo]

Q: What will we do with epic tickets on our board? I consider delight X an epic.

Currently they all sit "in progress".

[macobo]

This process sounds nice, but...

I am a believer in autonomy and honestly the netflix style. We hire the best - I trust that everyone here is able to manage themselves and their work.

I agree with this.

However one thing we really struggle with is passing context on within the team. E.g. how was cloud set up, how to do clickhouse cluster large-scale changes, how helm was set up for a specific client, how was metrics stack developed etc. In deployments often the context is implicit, in one persons head and not available in any sort of code.

Since prioritization is a function of Complexity x Pain, holes in context can lead to being unable to prioritize.

I think all of the following is true:

• We want team members to be as autonomous as they can
• I think we don't want people to always reinvent the wheel
• Being 10h remote makes scheduling sync conversations a no-go
• We take too long to answer (or never answer) questions about context asynchronously

IMO something in that formula needs to change - as-is this is a huge source of frustration for me and a blocker for this sort of process.