Skip to content

Latest commit

 

History

History
58 lines (38 loc) · 3.3 KB

outline.md

File metadata and controls

58 lines (38 loc) · 3.3 KB
Raw

Summary

The operating model clarifies how to work with us and shows how we function, and increases our visibility and awareness. Here’s an outline that we can outline at Write the Docs in Portland 2023. (Our very first team offsite!)

What do we want to accomplish?

  1. Our Why? Define our strategy. Clearly define the goals that will drive the rest of the planning process. This is our mission statement, our voice and tone, and our statement of purpose.
  2. How we work. Tease out the internal team parts of our operating model. This part translates strategic intent into operational capabilities. Provides a foundation for action, and a clear guide for those who join our team, but also a window for others to better understand us. Includes who we are, our culture, our stakeholders.
  3. How to work with us. Define our external facing operations and processes. This will provide a clear guide for other teams so they understand what is expected of them, adn what to expect of us. Examples might take shape as: Process Maps, procedures, guidelines, work instructions, standards, tools, and more.

Shaping our Operating model

Strategy

  • Style guide

  • Contribution guidelines

  • Voice & tone What is our Voice & Tone?

    From the Community: Stick with it and, soon enough, you'll be able to harness the full power of dbt to achieve your data goals. Stay persistent, stay positive, and (most importantly) believe in yourself. You've got this!

    💡Gentle and wise, but also reassuring and positive.

People

  • Team structure: What roles do we all have and who should you ask what? We are OSS maintainers as well as a Docs team
  • Culture: Who are we and how do we conduct ourselves?
  • Key stakeholders: Internal or external customers include OS community, dbt Community, Townies (PMs, partnerships, revenue, SAs, Customer success, Training)

Processes

  • Important processes we use to perform our work, reviewing PRs (Townie and Community). Ideas for docs:

    How we work:

    • How we prioritize our work
    • How do we work in the docs repo and dbt community slack? (I feel like we should have a general understanding of what work we do in the repo and slack)?

    How to work with us:

    • How to request help from Docs / open an issue in GitHub. Great data team example here!
    • How to communicate with community prod docs team
    • How to learn the style guide
    • How do we work with other closely related teams like Developer experience? (Who to reach out to for what?)

  • Communication: What is our SLA (48hours?), how we handle Slack channels, what to ask in Slack vs GitHub issues vs Docs team projects, Docs Office hours (when we’re ready)

  • Information we produce and consume: Systems that we use to do our work, where is it stored, how can you contribute to it?

Data

  • Key quantitative metrics that we use to measure success.
  • Key qualitative metrics that we use to measure success and make decisions.

Tech/product

  • Technology: Where do we work and what are the systems in which we work?
  • Product: How does state of the product and changes to the product affect our team?