diff --git a/.github/ISSUE_TEMPLATE/offboard-from-role.md b/.github/ISSUE_TEMPLATE/offboard-from-role.md index 8a254d19..3a90e238 100644 --- a/.github/ISSUE_TEMPLATE/offboard-from-role.md +++ b/.github/ISSUE_TEMPLATE/offboard-from-role.md @@ -1,18 +1,18 @@ --- -name: "đŸ‘‹đŸ» Remove a team member from the Support Steward Team Role, calendar and rota" +name: "đŸ‘‹đŸ» Remove a team member from the Support Triager Team Role, calendar and rota" about: Steps to follow to remove a team member from our Team Roles calendar and rota # labels: "type: offboard" -title: "Offboarding from Support Steward: " +title: "Offboarding from Support Triager: " --- ### Checklist -- [ ] Remove them from the `@support-stewards` [Slack usergroup](https://2i2c.slack.com/admin/user_groups) -- [ ] Delete all upcoming events for the Support Steward using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#delete_events_bulkpy) - - Command should look something like: `poetry run delete-bulk-events support-steward` +- [ ] Remove them from the `@support-triagers` [Slack usergroup](https://2i2c.slack.com/admin/user_groups) +- [ ] Delete all upcoming events for the Support Triager using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#delete_events_bulkpy) + - Command should look something like: `poetry run delete-bulk-events support-triager` - Use the `--date` flag to tweak when to begin deleting events from -- [ ] Regenerate upcoming events for the Support Steward, without the specified member in the roster, using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#create_events_bulkpy) - - Command should look something like: `poetry run create-bulk-events support-steward` +- [ ] Regenerate upcoming events for the Support Triager, without the specified member in the roster, using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#create_events_bulkpy) + - Command should look something like: `poetry run create-bulk-events support-triager` - Use the `--date` flag to tweak when to begin creating events from, and the `--team-member` flag to indicate where in the team to begin cycling through from :sparkles: **Congratulations! This person is no longer on the rota for their role. Thank you for all your hard work!** :sparkles: diff --git a/.github/ISSUE_TEMPLATE/offboard-team-member.md b/.github/ISSUE_TEMPLATE/offboard-team-member.md index 2c0f0c0d..8d8ebc0f 100644 --- a/.github/ISSUE_TEMPLATE/offboard-team-member.md +++ b/.github/ISSUE_TEMPLATE/offboard-team-member.md @@ -45,7 +45,7 @@ Remove 2i2c accounts and remove from team accounts: - [ ] Remove from our [bitwarden organization](https://vault.bitwarden.com/#/organizations/11313781-4b83-41a3-9d35-afe200c8e9f1/vault) and remove from "Default collection" - [ ] Role removal - - [ ] File and complete a "Remove a team member from the Support Steward Team Role, calendar, and rotation" [issue](https://github.com/2i2c-org/team-compass/issues) + - [ ] File and complete a "Remove a team member from the Support Triager Team Role, calendar, and rotation" [issue](https://github.com/2i2c-org/team-compass/issues) **Documentation** diff --git a/.github/ISSUE_TEMPLATE/onboard-to-role.md b/.github/ISSUE_TEMPLATE/onboard-to-role.md index b658a025..51ffbc97 100644 --- a/.github/ISSUE_TEMPLATE/onboard-to-role.md +++ b/.github/ISSUE_TEMPLATE/onboard-to-role.md @@ -1,23 +1,23 @@ --- -name: "🙌 Add a team member to the Support Steward Team Role, calendar and rota" +name: "🙌 Add a team member to the Support Triager Team Role, calendar and rota" about: Steps to follow to add a team member into our Team Roles calendar and rota labels: "type: onboard" -title: "Onboarding into Support Steward: " +title: "Onboarding into Support Triager: " --- ### Checklist -- Add them to the a`@support-stewards` [Slack usergroup](https://2i2c.slack.com/admin/user_groups) +- Add them to the a`@support-triagers` [Slack usergroup](https://2i2c.slack.com/admin/user_groups) The above action will automatically mean they will start to be added into rotation on the [Team Roles calendar](https://calendar.google.com/calendar/embed?src=c_nq8hl7qsm484g1p7mfkm29jpo8%40group.calendar.google.com&ctz=Etc%2FUTC) and be pinged by the Slackbot for reminders. However, we keep the calendar populated ~1 year in advance (to assist with PTO scheduling), so it may be a long time before their first shift comes around! To expedite this a little you can use code in the [`team-roles-geekbot-sweep` repo](https://github.com/2i2c-org/team-roles-geekbot-sweep) to update the calendar. -- [ ] Delete all upcoming events for the Support Steward using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#delete_events_bulkpy) - - Command should look something like: `poetry run delete-bulk-events support-steward` +- [ ] Delete all upcoming events for the Support Triager using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#delete_events_bulkpy) + - Command should look something like: `poetry run delete-bulk-events support-triager` - Use the `--date` flag to tweak when to begin deleting events from -- [ ] Regenerate upcoming events for the Support Steward, with the new member in the roster, using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#create_events_bulkpy) - - Command should look something like: `poetry run create-bulk-events support-steward` +- [ ] Regenerate upcoming events for the Support Triager, with the new member in the roster, using [code described here](https://github.com/2i2c-org/team-roles-geekbot-sweep/blob/HEAD/README.md#create_events_bulkpy) + - Command should look something like: `poetry run create-bulk-events support-triager` - Use the `--date` flag to tweak when to begin creating events from, and the `--team-member` flag to indicate where in the team to begin cycling through from :tada: **Congratulations! This person is now on the rota for their new role!** :tada: diff --git a/_data/support_stewards/gen_support_stewards.py b/_data/support_stewards/gen_support_stewards.py index 80f0c313..4a561e7e 100644 --- a/_data/support_stewards/gen_support_stewards.py +++ b/_data/support_stewards/gen_support_stewards.py @@ -102,7 +102,7 @@ def main(): path_data_root = Path(__file__).resolve().parent.parent tmp_dir = path_data_root.joinpath("tmp") tmp_dir.mkdir(parents=True, exist_ok=True) - support_stewards_file = tmp_dir.joinpath("support-stewards.txt") + support_stewards_file = tmp_dir.joinpath("support-triagers.txt") # Get support stewards usernames and avatars try: @@ -114,7 +114,7 @@ def main(): print("Generating support stewards gallery encountered an error:") print(err) sys.exit() - usernames_and_avatars = slack.get_users_in_usergroup("support-stewards") + usernames_and_avatars = slack.get_users_in_usergroup("support-triagers") diff --git a/administration/contractors.md b/administration/contractors.md new file mode 100644 index 00000000..971a8140 --- /dev/null +++ b/administration/contractors.md @@ -0,0 +1,31 @@ +# Set up a contractor with CS&S + +If you need to contract work to an external person or organization, follow the steps below. +Note that this is different from the process of hiring a contractor that is meant to be part of 2i2c's team on an ongoing basis. +For that use case, see [](#hiring). + +1. Fill out the tables in the contractor agreement template + + CS&S has [a contractor agreement template at this Google Doc](https://docs.google.com/document/d/15Vq-pMFEI9xa279ftgNzoxKEPsWyji-WKwHBo1ZA6MM/edit?usp=sharing). + + Copy it and fill out the top tables in coordination with the contractor and others at 2i2c. + + ```{admonition} Choosing a grant code + See [](#reimburse:grant-code). + ``` +2. Have the contractor prepare a **Statement of Work**. + Most contractors have their own templates for an SOW, but if one doesn't, here are a few pieces of information they should contain: + + - A general description of the service being provided and the need it is meeting. + - The outcomes that we aim to achieve with this work. + - The specific actions that will be taken as part of the work. + - The pricing structure of the contract. +3. Confirm the contract template with the contractor. + Make sure the language looks reasonable and that the information is correct. + If they have any changes they'd like to see to the contract, note it in the following step. +4. Send an e-mail to `fsp@codeforsociety.org` requesting a new contractor agreement. + Attach the contractor template you've filled out, as well as the Statement of Work. + Add any requests or questions the contractor has about the contract language. + `cc` the contractor so that they can follow up with CS&S if need be. + +After this, CS&S should provide next steps and take it from there if they need any extra information or clarification. diff --git a/administration/css.md b/administration/css.md index 37df0381..ec879865 100644 --- a/administration/css.md +++ b/administration/css.md @@ -12,12 +12,16 @@ Below are links to each: - [The CS&S Handbook](https://www.notion.so/CS-S-Handbook-18cd12a6e44c4393857642da6a6b0fdf) is similar to our Team Compass. - [CS&S Employee Handbook](https://docs.google.com/document/d/1LDN8-iSak391uQC5AzvtzD9dIOmfHg8kihwlvzn8Cy8/edit#heading=h.gjdgxs) is more like an employee policy guide. +```{tip} +📧 Please avoid emailing individual CS&S email addresses where possible. This ensures CS&S staff have maximum visibility of incoming email addresses and your query may be resolved more quickly as a result. +``` + ```{role} CS&S Operations ``` ## CS&S Operations To discuss invoices, contracting, etc. -This includes most "administrative actions" that we need help with. +This includes most "administrative actions" that we need help with, such as work with *external parties* regarding onboarding, signatures, invoicing, etc. E-mail address: **`operations@codeforscience.org`** @@ -30,6 +34,18 @@ For more strategic and programs-level conversations. E-mail address: **`fsp@codeforscience.org`**. +## CS&S HR + +For confidential Human Resources needs. + +E-mail address: **`hr@codeforscience.org`**. + +## CS&S Bills + +For sending invoices. This inbox is automated and not monitored. + +E-mail address: **`bills@codeforscience.org`**. + ## Google Group We have a dedicated Google Group and e-mail that we use to provide CS&S team members access to our files. @@ -37,14 +53,18 @@ We have a dedicated Google Group and e-mail that we use to provide CS&S team mem - **`css-admin@2i2c.org`** This is because they need visibility into many of our operational information for bookkeeping and accountability purposes. -It contains several adminsitrative and organizational leaders of CS&S. +It contains several administrative and organizational leaders of CS&S. They are all listed as managers, so can add people on their own. In Google Drive, you may add the `css-admin@2i2c.org` group to the sharing list for a folder or file and they will have access. ## Asana board -CS&S has an Asana board that they occasionally use to tack work items. +CS&S has an Asana board that they occasionally use to track work items. You can find it at this link: [CS&S Asana Board](https://app.asana.com/0/1200569652722016/list). + +```{note} +The list above is fairly comprehensive – there is no need to use any other aliases (such as `accounting@codeforscience`, etc.) since they are intended for outgoing use. +``` diff --git a/administration/index.md b/administration/index.md index f8a70eec..4a73ea42 100644 --- a/administration/index.md +++ b/administration/index.md @@ -8,6 +8,7 @@ overview structure css reimburse +contractors invoices google-workspace github diff --git a/leads/governance.md b/cross-functional/governance.md similarity index 86% rename from leads/governance.md rename to cross-functional/governance.md index 56d9d0ce..c9ce23c5 100644 --- a/leads/governance.md +++ b/cross-functional/governance.md @@ -1,6 +1,6 @@ # Making decisions -Functional areas and their team leads follow our [Principles of decision making](../operations/governance.md). +Functional areas and their leads follow our [Principles of decision making](../operations/governance.md). This section describes more specific ways in which decisions usually happen. ## Decision-making scope @@ -10,14 +10,14 @@ This means that most decisions are made by individuals without requiring a consu ### Within-area decisions -For decisions that primarily affect their area and no others, team leads are empowered to make decisions within their own team without requiring consent from team members of other areas. +For decisions that primarily affect their area and no others, area leads are empowered to make decisions within their own group without requiring consent from team members of other areas. However, they should make decisions transparently and inclusively, especially if they think another area will be interested in the decision. They are also empowered to _delegate_ scoped decision-making authority to others at 2i2c. ### Cross-organization decisions -There are a few kinds of decisions that require discussion and agreement from our team leads: +There are a few kinds of decisions that require discussion and agreement from our area leads: - Decisions with significant financial impact across 2i2c - Decisions that will significantly impact our capacity or commit ourselves to more work diff --git a/leads/index.md b/cross-functional/index.md similarity index 69% rename from leads/index.md rename to cross-functional/index.md index f4e1d1ec..141fd868 100644 --- a/leads/index.md +++ b/cross-functional/index.md @@ -1,4 +1,4 @@ -# Cross-team leadership +# Cross-functional processes ```{toctree} overview.md diff --git a/leads/overview.md b/cross-functional/overview.md similarity index 79% rename from leads/overview.md rename to cross-functional/overview.md index ae655f95..169d8be1 100644 --- a/leads/overview.md +++ b/cross-functional/overview.md @@ -1,13 +1,8 @@ # Scope and responsibilities -The Team Leads group is a bit different than most other 2i2c teams. -It has a cross-organizational scope and focuses on high-level priorities, strategy, and ensures we are distributing attention and resources across the organization correctly. +Our cross-functional processes focus on high-level priorities, strategy, and ensures we are distributing attention and resources across the organization correctly. -Team leads are representatives of their respective areas in 2i2c. -They advocate for the goals and needs of those areas. -They also bridge and coordinate strategy, prioritization, and resources across 2i2c. - -Here are their major responsibilities: +Here are this area's major responsibilities: ## Embody our values and team practices diff --git a/cross-functional/roles/chief-of-staff.md b/cross-functional/roles/chief-of-staff.md new file mode 100644 index 00000000..8e22efcc --- /dev/null +++ b/cross-functional/roles/chief-of-staff.md @@ -0,0 +1,6 @@ +```{role} Chief of Staff +``` +# Chief of Staff + +This role is new to 2i2c, and needs to be refined in the coming months. +For information about our acting Chief of Staff, see [](../../engineering/roles/delivery-manager.md). \ No newline at end of file diff --git a/cross-functional/roles/executive-assistant.md b/cross-functional/roles/executive-assistant.md new file mode 100644 index 00000000..debadce9 --- /dev/null +++ b/cross-functional/roles/executive-assistant.md @@ -0,0 +1,8 @@ +```{role} Executive Assistant +``` +# Executive Assistant + +We partner with [VaVaVirtual](https://vavavirtual.com/) for Executive Assistant support. +This role supports a variety of needs across our leadership team. + +Our executive assistant is Camille Gonzalez. diff --git a/cross-functional/structure.md b/cross-functional/structure.md new file mode 100644 index 00000000..78d34e95 --- /dev/null +++ b/cross-functional/structure.md @@ -0,0 +1,22 @@ +# Structure and roles + +The area leads group is composed of representatives from each area (usually, the Area Lead), who advocate for the goals and needs of those areas. +However, the policies and ideas in this area apply to all of 2i2c. + +## Area leads + +Below is the current list of area leads: + +- **Executive**: {role}`Executive Director` and {role}`Chief of Staff` +- **Partnerships**: {role}`Partnerships Lead` +- **Engineering**: {role}`Engineering Manager` / {role}`Technology Lead` +- **Product**: {role}`Product Lead` + +(cross-functional:roles)= +## Team roles + +```{toctree} +:glob: +:maxdepth: 2 +roles/* +``` diff --git a/leads/workflow.md b/cross-functional/workflow.md similarity index 91% rename from leads/workflow.md rename to cross-functional/workflow.md index 6b8efe23..cb7d683c 100644 --- a/leads/workflow.md +++ b/cross-functional/workflow.md @@ -1,6 +1,10 @@ (leads:workflow)= # Workflow +```{warning} Out of date +Our cross-team workflow is being significantly re-worked, and this information is out of date. +``` + This section describes how our leadership team carries out its planning and day-to-day work. (leads:meeting:organizational-strategy)= diff --git a/engineering/roles/delivery-manager.md b/engineering/roles/delivery-manager.md new file mode 100644 index 00000000..05412480 --- /dev/null +++ b/engineering/roles/delivery-manager.md @@ -0,0 +1,47 @@ +```{role} Delivery Manager and Chief of Staff +``` +# Delivery Manager / Chief of Staff + +```{note} +This role is new, and we must define its responsibilities, metrics for success, etc more clearly. +As a starting point to describe this role, below we provide the text we used in the job posting. +``` + +We’re looking for a **Delivery Manager** who will serve as a key facilitator in ensuring the successful and efficient delivery of [our product](https://2i2c.org/service/) . Acting as a servant leader, you’ll guide our engineering team, promote collaboration, and eliminate obstacles to deliver high-quality results that are aligned with our mission and goals. + +In addition to your role as a Delivery Manager, we’re keen to have this person to take on responsibilities of a **Chief of Staff** role, organizing cross-functional work, enabling transparency in decision-making, and fostering a cohesive work environment. + +We’re ideally looking for someone who has experience of leading or facilitating globally distributed and remote-first teams, asynchronous working and coaching teams in agile best practices. + +## What you’ll do + +As a Delivery Manager you’ll be primarily responsible for the detailed planning and day-to-day management of engineering tasks, and will also act as a servant-leader to resolve and remove any blockers that individual team members may be experiencing. + +Reporting into the Engineering Manager, you’ll work closely with them on running the day-to-day delivery related tasks on their behalf. To do this you’ll be someone with extensive experience in running agile delivery processes including planning, running retrospectives, and driving continuous improvement. + +You’ll collaborate with others, in particular the Product Manager, to design a process for balancing Sprint Goal work, support tasks, reactive tasks, and upstream work that is driven by open source community needs. + +In addition to this primary role, you’ll take on responsibilities as the **Chief of Staff**, working closely with the Executive Director. In this role you’ll be responsible for **organizing cross-functional work, enabling transparency in decision-making, and fostering a cohesive work environment**. + +## About you + +You’re a Delivery Manager who understands the principles and purpose and not just the ceremonies of agile. You’ll bring experience in optimizing the delivery process, fostering collaboration and ensuring that our product priorities are delivered in the most optimal fashion, all while upholding and coaching others in the principles of agility and continuous improvement. + +### Essential experience + +- Proficient in agile frameworks (Scrum, Kanban, Lean) with a deep understanding to effectively apply agile principles. +- In-depth understanding and extensive experience of working with software engineers to enhance their day-to-day experience and optimize product delivery. +- Strong communication skills to facilitate effective team collaboration and lead the team through various project phases. +- Ability to engage and communicate with stakeholders, manage expectations, and promote alignment with goals and objectives. +- Proficiency in coordinating the efforts of remote teams, ensuring efficient collaboration and productivity. +- Strong analytical and problem-solving abilities to address impediments, make informed decisions, and keep work on track. + + +### Useful qualities + +- Facilitating globally distributed and remote-first teams. +- Asynchronous working and associated best practices. +- Creating and overseeing systems of work that organize distributed teams. +- Facilitating teams who in addition to their day-to-day work actively contribute to open-source. +- Working directly with Platform, DevOps or Site Reliability engineers. +- Understanding the challenges of contributing to and leading community-driven open source technology projects. \ No newline at end of file diff --git a/index.md b/index.md index 5c4d7c6c..639b376c 100644 --- a/index.md +++ b/index.md @@ -48,7 +48,6 @@ operations/index people/index open-source/index finance/index -product/index administration/index ``` @@ -61,9 +60,10 @@ Functional areas each have their own leads, goals, and structures. :caption: Functional Areas :maxdepth: 2 -leads/index +cross-functional/index engineering/index partnerships/index +product/index ``` (index:hubs-service)= diff --git a/leads/structure.md b/leads/structure.md deleted file mode 100644 index 7a492a3e..00000000 --- a/leads/structure.md +++ /dev/null @@ -1,18 +0,0 @@ -# Structure and roles - -The team leads group is composed of leaders from various areas of 2i2c. - -## Team leads - -Below is the current list of team leads: - -- **Organization-wide**: {role}`Executive Director` -- **Partnerships**: {role}`Partnerships Lead` -- **Engineering**: {role}`Engineering Manager` / {role}`Technology Lead` - -## Executive assistant - -We partner with [VaVaVirtual](https://vavavirtual.com/) for Executive Assistant support. -This role supports a variety of needs across our leadership team. - -Our executive assistant is Camille Gonzalez. diff --git a/partnerships/structure.md b/partnerships/structure.md index 79ff0f91..6ecf0e36 100644 --- a/partnerships/structure.md +++ b/partnerships/structure.md @@ -18,6 +18,4 @@ See [list of team members](../reference/team.md). We use a [shared e-mail inbox](org:communication:shared-email) called `partnerships@2i2c.org` to collect any inbound communication from those that wish to partner with 2i2c. -It is attached to the `2i2c Partnerships` Google Group. - -Access is also shared with {term}`CS&S` so that they have context for any handoffs to invoicing and administration. +It is attached to the `2i2c Partnerships` Google Group. \ No newline at end of file diff --git a/partnerships/workflow.md b/partnerships/workflow.md index 257fbc04..1f8b62d4 100644 --- a/partnerships/workflow.md +++ b/partnerships/workflow.md @@ -66,7 +66,7 @@ Infrastructure services operated by 2i2c are managed through the [infrastructure CS&S uses AirTable to process and store tabular data. They store a record of **all invoices and executed agreements** with 2i2c's partners. -See [our Invoices and Contracts section](../../finance/contracts.md) for information about this table. +See [our Invoices and Contracts section](../finance/contracts.md) for information about this table. ### DocuSign @@ -122,11 +122,15 @@ A lead confirmed an upcoming meeting with 2i2c. Calendly sends an automatic mess A member of 2i2c Partnerships Team sends email to partnerships@2i2c.org requesting `Send Draft Contract` to PartnerX contact email(s). 2i2c's Partnerships Assistant carrys out the following actions script: -1. Copy 2i2c Team Drive >> Partnerships >> Templates >> [Template] service agreement... into PartnerX folder -2. Replace `PartnerX` names by name of partner organization in draft service agreement -3. Remame [Template file] to `PartnerX - 2i2c - CS&S Services Agreement` -4. Set sharing of service agreement (with editor rights) with lead contacts -5. Add dated entry "YYYY-MM-DD Sent (Draft) Service Agreement as shared Google doc" to PartnerX >> Running Notes... file +1. In the [Agreements folder](https://drive.google.com/drive/u/1/folders/1d2N0F0zn3-7wG1FrA_6FHgHtNAyMcJr8), navigate to the folder for the partner you're contracting for (or create a new one if needed) - this step is important for Step 5. +2. Return to the Agreements folder and navigate to the [Templates folder](https://drive.google.com/drive/u/1/folders/1oRFLPChp8J9GpgWpnalF74752oNh9tt8), and open the [[TEMPLATE] Outbound Services Agreement shortcut](https://docs.google.com/document/d/1kPgSddJ_Sob0XcTbkDy5UShIAVKPmm04P9ZLsYiOV20/edit#heading=h.qo34o8p9in1e). +3. In the template document, from the menu bar, select `File > Make a copy` +4. Name the copy appropriately (i.e. `PartnerX + 2i2c/CS&S - Services Agreement YYYY-MM-DD`) +5. Click the box below the word **Folder** and in the pop-up menu, the partner folder you navigated to in Step 1 should appear at the top of the list. Mouse-over it and hit the **Select** button +6. Do not check either of the boxes (re: sharing or copying comments) +7. Click **Make a Copy** - your new agreement will open, and will be filed in the appropriate partner folder. +8. Set sharing of service agreement (with editor rights) with lead contacts +9. Add dated entry "YYYY-MM-DD Sent (Draft) Service Agreement as shared Google doc" to `PartnerX >> Running Notes...` file (create a new one if needed). ### SOP: Service Agreement Negotiation diff --git a/people/hiring.md b/people/hiring.md index 4f32396b..f8d7865c 100644 --- a/people/hiring.md +++ b/people/hiring.md @@ -1,3 +1,4 @@ +(hiring)= # Hiring process and information This page contains information about the hiring process at 2i2c. diff --git a/product/index.md b/product/index.md index 39382c23..4b8ced3c 100644 --- a/product/index.md +++ b/product/index.md @@ -5,6 +5,7 @@ They work alongside engineering teams to define ways in which we aim to improve ```{toctree} overview.md +structure.md pricing/strategy pricing/cost-model ``` diff --git a/product/roles/product-lead.md b/product/roles/product-lead.md new file mode 100644 index 00000000..1f9b7175 --- /dev/null +++ b/product/roles/product-lead.md @@ -0,0 +1,52 @@ +```{role} Product Lead +``` +# Product Lead + +```{note} +This role is new, and we must define its responsibilities, metrics for success, etc more clearly. +As a starting point to describe this role, below we provide the text we used in the job posting. +``` + +The Product Lead is a senior-level role that will be instrumental in shaping 2i2c’s product vision, strategy, and execution of our "product function" within the team. You'll own the product vision, align it with user needs, and translate it into a clear product roadmap which defines cross-functional priorities and guides our partnerships and engineering teams, enabling efficient product delivery and continuous improvement. + +You’ll have a good level of technical understanding and be genuinely interested in the 2i2c offering, ideally having worked previously with platform teams and/or worked at a very detailed level alongside engineers and/or were a software Engineer yourself. In addition, recent experience in, or a good understanding of, [Product Operations](https://blog.logrocket.com/product-management/product-operations/) would be essential to your success in this role. + +## What you'll do + +The Product Lead would work with others, in particular the Delivery Manager and the Engineering Manager, to design a process to measure and track the flow of work through the team. You’ll shape the future of our product by gathering and distilling ideas from the collective group, fostering a shared vision. Working collaboratively, you’ll drive the development of our product and effectively position the product as a key function within our organization. + +On a day to day basis you’ll: + +- Define and own the product vision and strategy assuming ‘the voice of the user’, and doing so collaboratively and inclusively with our team and key stakeholders. +- Create a clear product roadmap that guides the engineering and partnerships teams and ensures alignment with the organizational vision. +- Collaborate closely with our engineers and users in partner organizations (researchers, educators etc.) to translate the product roadmap into actionable plans and tasks, managing a structured product backlog and sign-off of completed deliverables. +- Prioritize the product backlog based on impact, feasibility, and partner needs, ensuring alignment with the product roadmap. +- Define and manage a system to integrate and prioritize reactive tasks and contributions from the JupyterHub open-source community, which will in some instances shape the product direction in real-time. +- Working collaboratively with users to understand their news, gathering feedback and insights that shape the product vision and roadmap. +- Elicit insights and incorporate the deep experience from the Engineering team into the product vision and roadmap. +- Measure and enhance efficiency, quality, and flow within the product development lifecycle, incorporating ProductOps principles. +- Optimize processes to ensure a smooth and streamlined flow of work, promoting a structured and efficient product delivery approach. + + +## About you + +Your expertise in product management will complement the profound knowledge of our existing Engineering and Partnerships teams, as well as our partner and key stakeholder communities. + +### Essential experience + +- Previously worked with platform products and teams and/or worked at a very detailed level alongside engineers. +- Proficient in defining and articulating a clear product vision and strategy, aligning it with partner needs and organizational goals. You must be able to do this collaboratively and inclusively. +- Excellent communication and stakeholder management skills, ensuring a thorough understanding of requirements and fostering effective collaboration with internal and external stakeholders. +- Strong ability to translate product vision into a structured roadmap, prioritizing features and tasks based on impact, feasibility, and partner needs. +- In-depth understanding and experience with the product development lifecycle, from ideation to delivery. +- Familiarity with Product Ops principles, focusing on enhancing efficiency, quality, and flow within the product development lifecycle. +- Skilled in optimizing processes to ensure a smooth and streamlined flow of work. +- Strong grasp of technical concepts and proficient communication skills to effectively engage with engineering teams, comprehending the technical intricacies of product development. +- Proven expertise in the application of user-centric research and design principles and methodologies. + +### Nice to have skills + +- Experience working with distributed and remote-first teams, understanding the challenges and dynamics associated with remote collaboration. +- Experience with asynchronous working and associated best practices, allowing for productivity and collaboration across different time zones. +- Familiarity with open-source contributions, gained from environments where open-source collaboration and contributions are common. +- Experience working directly with Platform, DevOps, or Site Reliability engineers, understanding the intricacies of platform-based product design and development. \ No newline at end of file diff --git a/product/structure.md b/product/structure.md new file mode 100644 index 00000000..3f4f72f1 --- /dev/null +++ b/product/structure.md @@ -0,0 +1,12 @@ +# Structure and roles + +## Current roles + +```{toctree} +:glob: +roles/* +``` + +## Membership + +See [list of team members](../reference/team.md). diff --git a/projects/managed-hubs/incidents.md b/projects/managed-hubs/incidents.md index c6f4cefa..c4cf921f 100644 --- a/projects/managed-hubs/incidents.md +++ b/projects/managed-hubs/incidents.md @@ -25,7 +25,7 @@ The goal of the Incident Response Team is to collectively resolve incidents. An Incident Response Team is generally made up of: - An {term}`Incident Commander` -- The {term}`Support Stewards` +- The {term}`Support Triagers` - One or more {term}`Subject Matter Experts` (SMEs) ```{glossary} @@ -71,7 +71,7 @@ PagerDuty has a 'Severity' field for incidents. We do not use this field current ### External communication - The {term}`Incident Commander` acts as the primary point of communication with external stakeholders like the {term}`Community Representative`s. -- They may **delegate** this responsibility to another team member if they wish (e.g., to the {term}`Support Steward` team.) +- They may **delegate** this responsibility to another team member if they wish (e.g., to the {term}`Support Triager` team.) - We may interact with external stakeholders via comments in Incident Response issues if it helps resolve the incident more quickly. (incidents:communications)= @@ -104,7 +104,7 @@ Here is the process that we follow for incidents: - **Type `/pd trigger` and hit `enter` in `#pagerduty-notifications`** to trigger the incident After you hit `enter`, you should get a dialog box with options. - For "Impacted Service", **select `Managed JupyterHubs`**. - - **Assign it to the Incident Commander**. By default this is one of the {term}`Support Stewards` or the person triggering the event, but may be delegated to others[^note-on-delegation]! + - **Assign it to the Incident Commander**. By default this is one of the {term}`Support Triagers` or the person triggering the event, but may be delegated to others[^note-on-delegation]! - **Provide a descriptive but short title**, but don't sweat it too much! - **Add a link to the FreshDesk ticket** in the description (if there is one). - **Create a new Slack channel** by checking the box for `Create a dedicated Public Slack channel for this incident`. diff --git a/projects/managed-hubs/support.md b/projects/managed-hubs/support.md index 23f6f5fc..3e8e66f5 100644 --- a/projects/managed-hubs/support.md +++ b/projects/managed-hubs/support.md @@ -19,7 +19,7 @@ Here's a brief overview of our support process[^github-support-issues]: [^github-support-issues]: We had a lot of discussion around various support and operations systems to take as inspiration. [This GitHub Issue](https://github.com/2i2c-org/infrastructure/issues/1068) has a lot of useful discussion, including a few write-ups of specific support systems to use as inspiration ([example one](https://github.com/2i2c-org/infrastructure/issues/1068#issuecomment-1063138772) [example two](https://github.com/2i2c-org/infrastructure/issues/1068#issuecomment-1063516429)) - A {term}`Community Representative` sends a request to `support@2i2c.org`. -- This is triaged by our {term}`Support Steward` team. +- This is triaged by our {term}`Support Triager` team. - They assess whether they can resolve it quickly, and potentially do so. - If they cannot resolve it, then we raise this support issue with our engineering team. - If the issue is an {term}`Incident` @@ -80,17 +80,17 @@ Supporting a 2i2c hub is a collaborative process between 2i2c and the community The **Support Team** is one of the main teams in our **Managed JupyterHub Service Team**. -This consists of three main roles: {term}`Support Stewards`, {term}`Community Representatives`, and {term}`Hub Administrators`. +This consists of three main roles: {term}`Support Triagers`, {term}`Community Representatives`, and {term}`Hub Administrators`. ```{glossary} -Support Steward -Support Stewards - A **two-person team** of {term}`Support Stewards` work together to triage and communicate with all external support requests. +Support Triager +Support Triagers + A **two-person team** of {term}`Support Triagers` work together to triage and communicate with all external support requests. Tenure on the support team is **for four weeks**. - Every **two weeks** (generally at the sprint meeting), a Support Steward cycles off the support team, and a new team member joins the team. + Every **two weeks** (generally at the sprint meeting), a Support Triager cycles off the support team, and a new team member joins the team. The support team rotates through [the “Open Infrastructure Engineering Team”](https://compass.2i2c.org/reference/team/), in alphabetical order. - The primary responsibilities of the Support Stewards are: + The primary responsibilities of the Support Triagers are: - Ensure that we meet {ref}`our Support Service Level Objectives `. - Carry out [our support process](support:process). @@ -111,9 +111,9 @@ Hub Administrators ### Who are our Support Team? -The Support Steward role rotates through the below Support Team members. +The Support Triager role rotates through the below Support Team members. -```{include} ../../_data/tmp/support-stewards.txt +```{include} ../../_data/tmp/support-triagers.txt ``` ## Communication channels @@ -159,9 +159,9 @@ Here is the process that we follow when triaging and resolving support requests. The goal of the triage phase is to understand the Support Request, decide if it is related to an incident, and choose the appropriate resolution pathway. -This process is carried out in an ongoing basis by the {term}`Support Stewards`. +This process is carried out in an ongoing basis by the {term}`Support Triagers`. -1. **Monitor our support channels**. We use FreshDesk for all support requests, and the Support Stewards should regularly keep an eye on this account for new requests. +1. **Monitor our support channels**. We use FreshDesk for all support requests, and the Support Triagers should regularly keep an eye on this account for new requests. When a new support requests comes in, move to the next step. 2. **Read and understand**. Within one working day[^working-day], read the support request and try to understand what action would resolve it. 3. **Decide if there is an incident**. Determine if a request meets {term}`the definition of an incident `. @@ -174,12 +174,12 @@ This process is carried out in an ongoing basis by the {term}`Support Stewards`. (support:non-incident-response)= ### Non-incident response process -The goal of the non-incident response process is to bring standardization to our support response. This simple workflow tries to battle the bias towards a reactive response whereas it is also bringing some common patterns so all of our non-incident support responses are cohesive and shared among our support stewards. +The goal of the non-incident response process is to bring standardization to our support response. This simple workflow tries to battle the bias towards a reactive response whereas it is also bringing some common patterns so all of our non-incident support responses are cohesive and shared among our support triagers. The current iteration of the workflow states each step and who should be responsible/accountable for the specific step, plus some other clarifications. When a new ticket lands in Freshdesk under the support group and it is not an incident, we aim to respond within 24 working hours with a suggested next action. The next steps should be followed when resolving a ticket: -1. `Who: Support steward` +1. `Who: Support Triager` First, we determine if the person *initiating* the support ticket is *authorized* to do actually do so. While we may interact with many folks from a community during resolution of a ticket, we constrain who can *initiate* a ticket to {term}`Community Representative`s only. This prevents our @@ -198,11 +198,11 @@ When a new ticket lands in Freshdesk under the support group and it is not an in for who can initiate support requests for which communities. You should find the username & password for 2i2c airtable account in the organizational bitwarden. -2. `Who: Support steward` +2. `Who: Support Triager` **First 24h initial ticket evaluation**. In the first 24h a support ticket was opened, you should do an initial evaluation of the ticket and ask the {term}`Community Representative` about any additional information you may need. -3. `Who: Support steward` +3. `Who: Support Triager` **Spend 30 minutes trying to resolve**. If you believe you can resolve the issue within 30 minutes, try resolving it yourself. 1. If you resolve the issue, then jump to the "Confirm resolution" step 10. @@ -210,7 +210,7 @@ When a new ticket lands in Freshdesk under the support group and it is not an in Follow the guide at [](support:timeboxed-evaluation) to try and reach to a decision. -4. `Who: Support Steward` +4. `Who: Support Triager` **Open an issue in the 2i2c/infrastructure repository**. If this is an issue that cannot be resolved within 30 minutes, then open a GitHub issue for the team to discuss. @@ -218,8 +218,8 @@ When a new ticket lands in Freshdesk under the support group and it is not an in This issue will then be automatically added to the **Eng & Prod** board by the existing automation alongside the the **type**: `support` and the **impact** level specified in the form project fields. - If the issue has a `critical` impact (we defer that first evaluation to the support steward), an additional ping to the support Slack channel is needed to boost the signal. - + If the issue has a `critical` impact (we defer that first evaluation to the support triager), an additional ping to the support Slack channel is needed to boost the signal. + :::{admonition} What does `critical` mean? We recognize there might be some support-related issues that do not count as [incidents](incidents:what), but @@ -236,17 +236,17 @@ When a new ticket lands in Freshdesk under the support group and it is not an in * Authentication and authorization updates ::: - The support steward **should** self-assign the `critical` issue and work on it immediately (this is now outside of the 30-minute timebox described in step 3). + The support Triager **should** self-assign the `critical` issue and work on it immediately (this is now outside of the 30-minute timebox described in step 3). - If the support stewards (both of them) do not have the capacity to resolve the `critical` issue (ie. working on another `critical` issue, being out of their working time, etc.), they should ping the **Engineering Manager** (or the delegated person) so they can secure resources to resolve that issue on the fly (see step 8 below). + If the support Triagers (both of them) do not have the capacity to resolve the `critical` issue (ie. working on another `critical` issue, being out of their working time, etc.), they should ping the **Engineering Manager** (or the delegated person) so they can secure resources to resolve that issue on the fly (see step 8 below). - The support steward **should not** work on issues with impact lower than `critical` (unless they are assigned as part of the "planned" reactive work in the context of a running sprint (see step 8 below). + The support Triager **should not** work on issues with impact lower than `critical` (unless they are assigned as part of the "planned" reactive work in the context of a running sprint (see step 8 below). 5. `Who: Partnerships representative and the Engineering Manager (or respective delegates)` **Revisit the impact metadata**. Once a week (at minimum) the [support view in the **Eng & Prod** board](https://github.com/orgs/2i2c-org/projects/22/views/47) should be revisited to validate the impact level on support-related issues. Currently, we allocate a 30-minute working session every Wednesday (open to everyone to participate) to perform such impact revision and further prioritization ("planned" reactive) every other week (see step 8 for more details). - -6. `Who: Support steward` + +6. `Who: Support Triager` **Add a reference/link to the created engineering issue inside the Freshdesk ticket**. You can use an internal note or make it public when you communicate back to the Community Representative in step 7. Also, move the status of the ticket to the "Pending" state. @@ -267,17 +267,17 @@ When a new ticket lands in Freshdesk under the support group and it is not an in If there is any `critical` issue, we could assign people on the fly (during the sprint) to resolve them, but we should minimize that behavior (it should be exceptional cases). -9. `Who: Support steward` +9. `Who: Support Triager` **Resolve the request**. When some engineer is assigned to a support-related GH issue in the context of a sprint, we move ahead with the investigation/resolution for one (1) sprint. If we failed to find a fix during that time, we communicate back that state in the Freshdesk ticket and resolve it. Exceptional tickets might need more than one sprint. These tickets need to be explicitly approved as exceptions. -10. `Who: Support steward` +10. `Who: Support Triager` **Confirm resolution**. Once we have resolved a support request, send a message to the Community Representative to confirm that we believe it is resolved. In FreshDesk, mark the incident as {guilabel}`Resolved`. -11. `Who: Support steward` +11. `Who: Support Triager` **Close the request**. If the Community Representative confirms that their request has been fulfilled, consider this request closed. In FreshDesk, mark the incident as {guilabel}`Closed`. @@ -379,4 +379,4 @@ Here are the steps we take to set expectations for our team and for other organi ### Rotating team members during expected time off -Because team members continue to serve as support stewards during this time, we should take care to avoid the same person serving in this role across multiple periods of expected time off. +Because team members continue to serve as support triagers during this time, we should take care to avoid the same person serving in this role across multiple periods of expected time off.