← Back to Operations: In practice Case study

Every layer read the same weekly picture of the work.

Time tracking, four org-health measures and a weekly summary that explained the design team's work to team leads, the director and the C-suite.

The problem

Reporting was a Jira dashboard exported to a spreadsheet. It counted requests by status and could not explain the work behind a timeline or a decision.

The constraint

Designers first read time tracking as surveillance. The measures were only useful if the team trusted how the data would be used.

The outcome

Every team had a baseline within six months, and delays could be traced to where they started.

6 monthsto baseline every team
4org-health measures

Counts of open requests could not explain the work behind them

Reporting started as a Jira dashboard, exported to a spreadsheet that the director of product design took to the VP of product. The VP and the product directors used it to work through conflicts and concerns. It counted requests: how many were pending, how many were in progress, and how many were marked as waiting on design.

Those counts could not explain a timeline, a decision or the work behind either. When a deployment slipped while a request sat in waiting on design, the report could not show where the delay started, and design had no data to give its side of the story.

The report, before and after
Recreated, values illustrative
status-export.xlsx
1RequestPendingIn progressWaiting on design
Before: a status export
Weekly operating summary
2Projects by teamTeamProjectStatus
3Org-health measuresMaker vs adminRedo rateDesign debtFocus loss
4Risks, and where delays started
After: the weekly summary
  1. 1
    Counts by statusPending, in progress, and waiting on design. No causes, decisions or timelines.
  2. 2
    Projects by teamWhat each team is working on, read by team leads each week.
  3. 3
    Org-health measuresThe four measures from time tracking, against each team's baseline.
  4. 4
    Risks, and where delays startedThe context the director took into C-suite updates.
1. Counts by status: Pending, in progress, and waiting on design. No causes, decisions or timelines.. 2. Projects by team: What each team is working on, read by team leads each week.. 3. Org-health measures: The four measures from time tracking, against each team's baseline.. 4. Risks, and where delays started: The context the director took into C-suite updates..

Four measures showed where design time went

Time tracking ran through Tempo, a Jira plugin, and fed four org-health measures. Within six months every team had a baseline. The measures showed where design time went, where work came back, and where the partnership with product and development could improve. They also gave the department the evidence to ask for new tools, resources and headcount.

The org-health measures
01

Maker-vs-admin ratio

Time spent designing against time spent on meetings, status and process.

02

Redo rate

Work done again after review or a change in scope.

03

Design debt

Known compromises waiting to be fixed.

04

Focus loss

Time lost to switching between projects and interruptions.

Designers could see every number recorded about their own time

At first, designers read time tracking as surveillance. Every team member was taken through the workflows and what the tracking was for. In operational meetings I showed how the data was used, and made sure leaders did not use it as a main measure of performance.

The leadership team made two commitments. Every metric drawn from time tracking stayed open to the people it described, to review and question. If their data came into an issue that involved them, they would hear about it early, know the full situation, and take part in the review.

One report, read at each layer

Each month I led an all-staff meeting that shared the previous month's operational metrics. Everyone had access to the reports, and anyone could book a 1:1 in my weekly office hours to ask about them. The measures later fed employee development and evaluations, and showed where a gap in delivery started, so the team that owned it could close it.

From time entries to every layer
Sources
  • TempoTime entries in Jira
  • JiraWork status
Measures
  • Maker-vs-admin ratio
  • Redo rate
  • Design debt
  • Focus loss
Reports
  • Weekly summaryProjects, risks and causes
  • Monthly all-staffLast month's metrics
  • Office hoursQuestions in a 1:1
Readers
  • DesignersTheir own time
  • Team leadsProjects and risks
  • DirectorC-suite updates
  • C-suiteDelivery with its causes
Sources: Tempo, Jira Then Measures: Maker-vs-admin ratio, Redo rate, Design debt, Focus loss Then Reports: Weekly summary, Monthly all-staff, Office hours Then Readers: Designers, Team leads, Director, C-suite.
In practice

USF behind eight real operational initiatives.