How we work

Owned by Jonathan Belanger
Nov 18, 2023
3 min read

Our cadence

Please see https://awellhealth.atlassian.net/wiki/spaces/AH/pages/3503980690 to understand our cadence in more depth. Product development in a nutshell:

  • 4 quarters per year

  • 2 cycles per quarter (6-week and 7-week, alternating)

  • Each cycle is comprised of 5 weeks of project work and 1 week of cooldown work

  • The quarterly 7th week is reserved for a hackathon

The weekly cadence:

  • Monday standup

  • Thursday value stream reporting

  • Friday show & tell and dev retro

Inside the cycle

The 5-week cycle is either comprised of one LARGE project or two SMALL projects. Each project is owned by a single-threaded DRI who serves as project lead (more on the rotating project lead below). The project lead helps to guide the shaping process, is DRI for all communication, scope-hammering, value-slicing, and delivery of the project.

The 6th week is a cooldown week, where all high priority tickets are cleaned up, tech debt can be addressed, and additional small tasks that fall outside project scope can be completed.

The alternating 7th week is a cooldown and hackathon week. The goal is to keep triage clean while spending 3+ days in “hack” mode working on something fun and vitalizing to the team. It’s our quarterly week of engineering-focused initiatives.

Rotating project leads

We made the decision to have rotating project leads for cycle work. The rest of the team should make sure the project lead has no other major responsibilities during the implementation weeks of the cycle. There is also likely some small shaping work expected of the project lead prior to implementation, as determined by product management.

Expectations for the project lead

Phase: Framing and shaping

  • Support product management in framing or shaping activities, as requested by product management. During these phases, product management is DRI, while engineering is in a supporting role

Phase: Implementation

  • Communication

    • 1st day of cycle: Kickoff communication around milestones and scope

    • Weekly, Thursdays EOD: Milestone update to the group

  • Focus / delivery

  • Scope-hammering

    • Review feedback regularly and make sure scope hammering still allows the core value from a project to shine

    • Maintain a scientific approach: What is our hypothesis with this feature? How do we test the hypothesis? How do we know when we are successful?

      • is a partnership between engineering, design, and product

  • Cross-functional coordination

    • Help product to ensure that customer support and marketing are aware of new features and can communicate effectively around them

Phase: Post-delivery

  • Triage support

    • In the first week after a project is finished, work with the triage captain to help make sure any urgent, high, and medium priority bugs are triaged and resolved. The time right after a feature is complete is the time it is freshest in the minds of those who implemented the feature. This triage support will either come during a cooldown week ( LARGE projects and SMALL projects at the end of a cycle), or while another project is ongoing, so it’s important to keep perspective.

Triage captain

On a weekly basis, we rotate triage captain responsibilities. The role of the triage captain is to be the first line of triage for tickets.

Responsibilities

Ticketing

We use Linear as our issue tracking tool. See for more in-depth information.

Tracking our work

Labels

We use Echoes (https://app.echoeshq.com) to help track our work. Echoes has created labels that assist us in understanding the intent of our work (creating value vs unblocking a bug vs risk mitigation) as well as the impediments that prevent us from moving quickly (e.g. knowledge gaps, tech debt). Finally, initiatives are mapped 1:1 to the projects, and are just a way to capture those projects with mixed intent (e.g. a project that contributes both to throughput and to value creation).

Performance metrics

DORA metrics

We want to move with velocity while also maintaining stability, and DORA metrics aim to capture these two characteristics through the following metrics:

  • Lead time

  • # of deployments / day

  • MTTR

  • CFR

We’re capturing these metrics with both our platform repository, which helps to capture release information and the support of Echoes.

Other metrics

Please see building a top-tier engineering org (TBC) for more