Product Analytics/Team norms

Jump to navigation Jump to search

Expectations for work & off hours[edit]

  • Team core work hours: Monday–Thursday, 09:00-11:00 San Francisco time (note that this varies with daylight saving time)
    • Team members should be available for scheduled meetings during these hours
    • Team members should be able to respond to questions within that time frame, though not necessarily immediately (given that people may be involved in meetings, heads down work, etc)
    • If you are not available during these hours, mark it on your calendar  
  • Time off should be time off! Block time off on your calendar, set email vacation messages, and redirect questions to the team email address.
  • Make sure to advertise when you’re working and when you're not: block off vacation days and non-work hours on your calendar, set a vacation auto-responder.
  • Keep the Office wiki contact list up to date with ways to reach you when you are not working.
    • Only use these methods to contact people if the issue absolutely cannot wait or be handled by someone else (this should happen very, very rarely).


  • Be present: avoid doing other things during meetings (unless you're presenting or taking notes, of course).
  • Text messages are the same as talking. Feel free to send them, but be aware they're just as interrupting as saying the same thing out loud.
  • If you can, stay unmuted during meetings so the conversation feels more natural. This may take some work to achieve (for example, buying a good headset to minimize background noise).
  • Be aware of how much you're talking: if you're talking a lot, consider leaving more space for others. If you're only talking a little, consider whether you have something to say.
  • Don't be afraid to eat a snack during a meeting (just mute yourself while you do!). Similarly, if you need a quick bathroom break, it's fine to step away briefly.
  • The person who requests a meeting should put it on the calendar.


  • Make it so you don’t get notifications about work communications (emails or chats) when you’re not working. That way, you can really recharge during your off hours and people don’t have to worry whether you’re working before sending a ping.
  • By default, we don’t expect emails or chats to be “urgent”; we understand people may be unavailable during heads down work or in meetings. If a message or question is urgent, preface it with [URGENT]
  • In chats, try not to send multiple messages when you can use one. For example, when asking a question, put the question in the same message as your greeting.
  • Unless you actively want something to be private, use main channels (email or Slack) for discussion and questions so the rest of the team can benefit and help.


Some of these are copied from the Technical Engagement team norms.

  • Mentor and share knowledge: Demonstrate and share lines of code, ad hoc commands, and general understanding. Don’t be afraid to ask a question, even if you think it’s basic.
  • Feedback is valuable! Offer specific & actionable praise, constructive criticism, or alternative solutions.
  • Apologize for and acknowledge behavior we seek to avoid when it has happened: A team of humans will experience being tired, frustrated, and overwhelmed. Mutual respect is the only currency we have to navigate these challenges long-term. Demonstrating that respect means acknowledging its value.
  • Forgiveness is a conscious, intentional, and deliberate decision to release feelings of resentment. Take a breath. Take a walk.
  • Practice healthy debate. Avoid petty controversies, but don’t shy away from raising problems if exposing them is helpful. Think twice before criticizing if you don’t have a different proposal to suggest, and always make sure to clearly acknowledge the necessary work that has been done.

Request Follow-up Kit[edit]

Outlined below are good practices & questions to consider when refining incoming requests.

  • What is the deliverable? Is it a report, an answer in Phab…?
  • How will QA be handled?
  • If the request involves a list of questions/metrics, work with the requester to rank them in order of importance, highlighting the ones that are required versus "nice to have"/optional. This helps us break down the work clearly, enabling us to focus on highest priority tasks first. It might mean the request is split into multiple Phabricator tasks.
  • Define acceptance criteria, definition of done, expectations, & scope. As much as our work is iterative, we do our best to plan by beginning with the end in mind. For example:
    • What do you envision the outcome of this request to be? (e.g., a list of numbers, a question to be answered, a decision to be made).
    • Requests that result in software/data/ETL management (e.g. notebook, dashboard, or dataset that’s been built to enable a request); recurrent jobs, “productionizing.”
  • How we handle follow-up requests for more data (especially for teams where there is no explicit relationship/assignment):
    • We start with an assumption that a request is ad hoc/one-time. If the task is a recurring one, that means a larger request that will need more scoping.
    • Future-proofing adds overhead, which should be explicitly considered in the task scope.