# 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>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://typo.gitbook.io/typo-help-docs/faqs/access-management/how-can-a-manager-start-using-the-typo-dashboard.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.