Skip to content
Ditwan Price edited this page Mar 9, 2026 · 1 revision

Managing Epics (Product Engineers)

This guide provides guidance for Product Engineers (PEs) responsible for managing epics. Epics help organize larger initiatives that span multiple issues, contributors, or milestones.

The goal of epic ownership is coordination and visibility, not implementation.


What is an Epic?

An Epic represents a larger body of work that contains multiple related issues. These issues may include:

  • Feature development
  • Refactors
  • Bug fixes
  • Design updates
  • Documentation updates

Epics help group related work together so the team can track progress on broader initiatives.

Example epic scope:

  • Refactoring a component family
  • Implementing a design refresh
  • Introducing new functionality across multiple components

Epic Ownership

Epics are typically assigned to a Product Engineer (PE) for coordination.

The epic owner is not necessarily responsible for implementing the work within the epic. Instead, the owner ensures the effort stays organized and continues moving forward. Epic ownership is primarily about keeping the initiative organized, visible, and moving forward.

Individual issues under the epic should still be assigned to developers as normal.

Responsibilities of the Epic Owner

Epic owners typically:

  • Monitor the issues contained in the epic
  • Ensure issues are progressing toward completion
  • Identify blockers or stalled work
  • Help create or organize new issues related to the epic
  • Coordinate discussions when design or technical decisions are needed
  • Keep the epic description updated as scope evolves

Think of epic ownership as project stewardship rather than task ownership.


Tracking Progress

Epic owners should periodically review the issues within the epic to ensure progress is being made. The goal is not strict oversight, but maintaining momentum and awareness.

Some helpful checks include:

  • Are issues assigned to someone?
  • Are issues moving through labels or workflow stages?
  • Are any issues blocked?
  • Are new issues emerging that should be added to the epic?

If work appears stalled, the epic owner may:

  • Ask for updates from the assigned developer
  • Raise the topic during team syncs
  • Help unblock discussions or decisions

Creating or Adding Issues to an Epic

As work progresses, additional issues may be identified that relate to the epic.

Epic owners should:

  • Add relevant issues to the epic
  • Ensure issues have clear descriptions
  • Confirm the issue scope fits the epic’s goals

Not every "related" issue needs to be included, but issues that fit the scope and is similar to the work being done in the epic should be tracked there.


Design and Development Labels

There is no strict rule (yet...that I know of) for applying workflow labels to epics (for example 2 - ready for dev).

Guidelines:

  • Use 2 - ready for dev label when the epic represents a coordinated design initiative
  • Skip readiness label if the epic contains mixed types of work (design exploration, refactors, bug fixes, etc.)

Individual issues under the epic should follow the normal workflow labels used by the team.


Milestones

Typically, an epic spans multiple milestones, and the assigned PE moves it forward at the end of each milestone until all the work is completed. This is mainly to keep epic top of mind when reviewing your assigned issues so they don’t fall by the wayside.


Examples of Epic Owner Activities

Epic management may involve things like:

  • Scheduling a discussion meeting to align on implementation direction
  • Monitoring related issues to ensure they move through the workflow
  • Adding newly discovered issues to the epic
  • Noticing related bugs or improvements that should be included
  • Tracking dependencies or blockers across multiple issues

Clone this wiki locally