# How can a manager start using the Typo Dashboard?

### Daily Engineering Health Checklist (for managers)

Goal: Spot early signals, understand where pain concentrates, and intervene before problems compound

#### 1. Start with the baseline

Before reacting to anything, ask:

* What has been normal for this team in the last 4–8 weeks?
* Is today’s movement noise or a real shift?

#### 2. Always compare the middle to the tail

Never read averages alone.

* Average ≈ P75\
  Flow is consistent. Problems are systemic or mild.
* Average << P90\
  Pain lives in the tail. A small set of PRs or issues is dragging the system.
* P75 is creeping up week over week\
  The whole system is degrading, not just edge cases.

Rule of thumb:\
Most engineering problems start in the tail before they show up in averages.

#### 3. Cycle Time: ask where the tail begins

When cycle time looks bad:

* Check where P75 and P90 diverge.
* Then break the cycle time into stages.

Interpretation:

* Coding Time\
  Long tail → complex or unclear work causing rework or stalled implementation.
* Pickup Time\
  Long tail → work waiting for prioritization or clear ownership.
* Review Time\
  Long tail → reviewer bottlenecks, large PRs, or uneven review load.
* Merge Time\
  Long tail → release process friction, flaky checks, or coordination delays.

Don’t treat cycle time as one problem.

#### 4. PR Size + Review Time must be read together

Individually, they mislead.

* Large PRs + long review tail\
  Reviews are shallow, slow, or avoided.
* Small PRs + long review tail\
  Review capacity or process issue.
* Large PRs + normal review time\
  The team may be compensating. Watch CFR next.

This pairing usually explains 60–70% of delivery drag.

#### 5. Look for concentration, not spread

Every day, ask:

* Are delays spread evenly or concentrated in:
* specific repos
* specific teams
* specific reviewers
* specific weeks

See the “Risks” for each team to identify the concentration of issues

Concentration means a lever exists.\
Spread usually means structural issues.

#### 6. Incidents and delivery must be time-aligned

When incidents rise:

* Look backward, not just at the incident page.
* What changed 5–14 days earlier?
  * PR size?
  * Review depth?
  * Scope churn?
  * AI-generated code volume?

#### 7. Use contributor metrics to spot system stress, not performance

Daily question:

* Who is the system leaning on the hardest right now?

Signals to watch:

* Review load concentration
* Workload distribution
* Review time tail
* Sudden drop in coding days

Interpretation:

* High load ≠ underperformance
* It usually means a hidden dependency or a knowledge silo

#### 8. AI coding metrics only matter with downstream effects

Don’t stop at adoption or acceptance.

Always check:

* Are AI-assisted PRs larger?
* Do they take longer to review?
* Does CFR rise after high AI usage weeks?

#### 9. Allocation drift&#x20;

If delivery feels slow:

* Check bug vs feature vs task mix.
* Watch for week-over-week drift, not absolute numbers.

Interpretation:

* Rising bug share
* High task share&#x20;

#### 10. End every review with one decision

If you can’t answer this, you’re still dashboarding:

* What is the one thing I’ll change or watch more closely this week?

Good examples:

* Cap PR size for 2 teams
* Redistribute reviews
* Pause the new scope for a sprint
* Fix a single release bottleneck

Use Goals in Typo to set up alerts for best practices and metric benchmarks in the team.\ <br>

\ <br>

\
\
\
\
\
\
\
\ <br>

.

<br>