Skip to content

Latest commit

 

History

History
69 lines (40 loc) · 4.21 KB

File metadata and controls

69 lines (40 loc) · 4.21 KB

Sample writer assignment process

This example demonstrates one approach to assigning documentation writers to projects. Your team can adapt this cadence, terminology, and requirements to match your organization's planning cycles and resource management practices.

Planning cycle assignment

The docs team assigns writers to documentation requests at the start of each planning period based on which parent initiatives meet predefined minimum requirements.

At the beginning of each planning cycle (quarterly, bi-annually, or sprint-based), the docs team meets to assign writers to documentation requests that meet the minimum requirements. Assignment happens during the first week of the period.

For this process to work, all parent initiatives and corresponding documentation requests should be created during planning before the period begins.

Before the planning period starts

This section outlines the steps required to ensure your parent initiative is ready for writer assignment during the initial planning phase.

If your parent initiative is planned for the upcoming period:

  • Create your parent initiative and corresponding documentation request during planning (before the period begins).
  • Ensure your parent initiative meets the minimum requirements for writer assignment.

If the requirements are met, the docs team assigns a writer during the first week of the period.

If requirements are not met, the docs team will not assign a writer.

Customization notes

  • Planning cycle terminology: Adapt "planning period" to match your organization's terminology (quarter, sprint, release cycle, etc.)
  • Minimum requirements: Define what constitutes a "ready" documentation request based on your team's needs (completed design docs, approved PRD, stakeholder sign-off, etc.)
  • Assignment timing: Adjust the "first week" timeline based on your planning cycle length

If your parent initiative becomes ready mid-period

Parent initiatives that miss the initial assignment window can still receive documentation support if they meet requirements and capacity is available.

If your parent initiative was not ready for assignment at the beginning of the period but becomes ready mid-period:

  • Bring it up in the next cross-functional sync.
  • If the minimum documentation request requirements are met, the docs team will assign a writer.

Mid-period changes should only happen if priorities shift in a way that makes it necessary to update the parent initiatives for a period. Flexibility is expected, but these situations are handled on a case-by-case basis.

Customization notes

  • Escalation channel: Replace "cross-functional sync" with your team's appropriate meeting or communication channel
  • Mid-cycle policy: Adjust the flexibility guidelines based on your organization's change management practices

Constraints

The docs team operates with finite resources and uses a collaborative prioritization process to allocate writer capacity across competing requests.

The docs team has limited capacity and might not be able to support all requests.

Capacity conflicts are resolved collaboratively in the cross-functional sync on a case-by-case basis. It is the docs team's responsibility to communicate when they are at capacity. Decisions about which documentation requests get resources are made collaboratively.

Customization notes

  • Prioritization framework: Consider adding specific criteria for prioritization (business impact, user impact, regulatory requirements, etc.)
  • Escalation path: Define what happens when collaborative resolution doesn't work
  • Capacity visibility: Determine how capacity constraints are communicated (dashboard, regular updates, planning artifacts, etc.)

Variations to consider

Different organizational contexts may require different approaches:

  • Continuous assignment: Some teams may prefer ongoing assignment rather than fixed planning cycles
  • Dedicated writers: Projects with dedicated writer resources may not need this process
  • Self-service documentation: Technical teams writing their own documentation may use this process for review capacity rather than writing capacity
  • External documentation: Teams managing third-party documentation may need additional approval gates