Leave with defensible priorities, protected time, and a simple way to review progress.
Workbook: weekly priority system
Observe one week, choose three priorities, protect focus blocks, and define evidence of progress.
Make the work that deserves attention visible.
A full calendar does not prove progress. Without explicit criteria, urgent work displaces important work. Missing agreements also scatter team attention.
Diagnose, decide, block, execute, and review. Each step leaves an observable artifact.
Deliver a short activity log, three justified priorities, a protected calendar, and a review with decisions for the next week.
How to use this workbook
Start in class, deepen through practice, and consolidate only with reviewable evidence.
- 01
Frame the caseState the case, desired result and evidence you want to observe.
- 02
Prepare the inputsGather what is needed, acknowledge boundaries and use the three preparation prompts.
- 03
Work in classComplete the essential practice and retain initial evidence.
- 04
Go deeperOpen each detail to review actions, criteria, examples and connections.
- 05
Consolidate and transferMeet the criterion, review the evidence and test the practice in another context.
The team week as a system
Align priorities, owners, reviewers, dependencies and rights before testing a shared rule.
- Use case
- A team with real deliveries and coordination.
- You are ready when
- A sponsor, exercise owner and permission to review agreed records exist.
Inputs
- Authorized shared calendar
- Deliveries and owners
- Dependencies and exceptions
- Data access rules
Define your case
Write only what is needed to frame the practice. These fields are neither saved nor sent.
Preparation prompts
Go deeper3 · Preparation prompts
Observable period
Bound the period and its records.
- Receives
- weekly activity log
- Produces
- Period and sources
Which seven days can you reconstruct from records? State custodian, permissions and authorized period.
Guiding result
State the result that will guide classification.
- Receives
- Activity value map
- Produces
- Result and evidence
Which concrete result should be closer to done? State who owns the result and who will accept the evidence.
Boundaries and permissions
Expose constraints before designing.
- Receives
- Three justified priorities
- Produces
- Declared constraints
Which data, commitment or boundary can you not change? State dependency, exception and authority to resolve them.
From busy to productive
Turn a real week into a visible priority system: three justified outcomes, protected blocks, and a final review.
Before you begin
Prerequisites
- A sponsor, exercise owner and permission to review agreed records exist.
Inputs
- Authorized shared calendar
- Deliveries and owners
- Dependencies and exceptions
- Data access rules
Limits
- Work with a bounded, authorized case.
- Do not include personal, confidential or restricted data.
- Stop when evidence, permission or an accountable reviewer is missing.
Observe one week, choose three priorities, protect focus blocks, and define evidence of progress.
Prepare the team week
Align records, rights and ownership.
Week inventory
Build a baseline before changing the system. Bound shared records and their custody.
Go deeperQuality criteria
How to apply it
- Collect calendar and task records.
- Record blocks, context switches and outputs.
- Name the record custodian and people with access.
Quality criteria
- Covers at least five days or the available period.
- Separates activity, duration and output.
- Record custodian and permissions are documented.
- Produces
- One real-week log for the team with ownership
- Example
- Synthetic team example: Monday 9:00–10:00 meeting; output: decision still pending.
- Avoid
- Do not reconstruct the week from memory when records exist. Do not expose data or calendars without access rights.
- Reflect
- Which part of the week is still invisible? Which dependency or exception will affect adoption?
- Connection
- Classify the work by value type.
Value map
Separate useful work, support, coordination and reaction. Align classification with affected areas.
Go deeperQuality criteria
How to apply it
- Label each block with one category.
- Mark uncertainty where context is missing.
- Assign a reviewer for disputed categories.
Quality criteria
- Every category has a reason.
- Ambiguous cases remain marked.
- Disputed categories have a reviewer and pending decision.
- Produces
- Activity value map for the team with ownership
- Example
- Synthetic team example: Prepare delivery = value; coordinate access = necessary support.
- Avoid
- Do not call all non-delivery work noise. Do not expose data or calendars without access rights.
- Reflect
- Which category takes more space than expected? Which dependency or exception will affect adoption?
- Connection
- Use the map to locate attention leaks.
Main frictions
Select the two frictions that most alter results. Turn observed frictions into concrete responsibilities.
Go deeperQuality criteria
How to apply it
- Group similar interruptions.
- Describe trigger, response and consequence.
- Name the owner of each friction and related dependency.
Quality criteria
- Each friction cites a fact.
- Avoid assigning motives to other people.
- Each friction has an owner and identified dependency.
- Produces
- Two evidence-backed frictions for the team with ownership
- Example
- Synthetic team example: Unruled messages: four context switches and one moved delivery.
- Avoid
- Temporal association does not prove causation. Do not expose data or calendars without access rights.
- Reflect
- Which friction can you change without external authority? Which dependency or exception will affect adoption?
- Connection
- Turn the diagnosis into three results.
Practise shared decisions
Agree criteria, dependencies and blocks.
Weekly results
Write three bounded, verifiable results. Write results the sponsor can accept.
Go deeperQuality criteria
How to apply it
- State the definition of done.
- Declare what is out of scope.
- Assign the result owner and agreed backup.
Quality criteria
- Every result is observable.
- Every boundary prevents scope drift.
- Each result has an accepted owner and backup.
- Produces
- Three candidate results for the team with ownership
- Example
- Synthetic team example: Deliver a reviewable draft with five cited sources.
- Avoid
- Do not use “work on” or “make progress” as the finish condition. Do not expose data or calendars without access rights.
- Reflect
- Which result serves the immediate purpose most? Which dependency or exception will affect adoption?
- Connection
- Compare the results with shared criteria.
Priority test
Rank results with explicit criteria. Validate the order with those managing dependencies.
Go deeperQuality criteria
How to apply it
- Compare impact, real urgency and effort.
- Add dependency, risk and missing data.
- Validate dependencies and risk with those able to resolve them.
Quality criteria
- The same criteria apply to all results.
- Ties expose the trade-off.
- Risks have a reviewer and escalation path.
- Produces
- Priority matrix for the team with ownership
- Example
- Synthetic team example: Result A: high impact, dependency cleared, medium risk.
- Avoid
- Do not treat a score as an automatic truth. Do not expose data or calendars without access rights.
- Reflect
- What fact could change the order? Which dependency or exception will affect adoption?
- Connection
- Reserve time for the selected priorities.
Protected calendar
Turn priorities into executable blocks. Coordinate blocks with other people’s commitments.
Go deeperQuality criteria
How to apply it
- Reserve blocks with purpose and output.
- Add preparation and definition of done.
- Align each block with its owner and dependent teams.
Quality criteria
- Every priority has assigned time.
- The calendar keeps realistic margin.
- Blocks respect shared commitments and dependencies.
- Produces
- Protected weekly calendar for the team with ownership
- Example
- Synthetic team example: Tuesday 9:00–10:30: draft; output: reviewable version.
- Avoid
- Do not fill every free slot or ignore fixed commitments. Do not expose data or calendars without access rights.
- Reflect
- Which block needs prior preparation? Which dependency or exception will affect adoption?
- Connection
- Define the interruption response.
Transfer a team rule
Review evidence and govern adoption.
Execution record
Compare the plan with what happened. Share status without exceeding agreed permissions.
Go deeperQuality criteria
How to apply it
- Mark blocks completed, moved or cancelled.
- Record the evidence produced.
- Give status to the reviewer without exposing others’ data.
Quality criteria
- Every status has evidence.
- A deviation retains its context.
- Status can be reviewed under current rights.
- Produces
- Plan-versus-execution record for the team with ownership
- Example
- Synthetic team example: Block completed; partial output; one source still needs review.
- Avoid
- Do not confuse attendance in a block with a completed result. Do not expose data or calendars without access rights.
- Reflect
- What decision became possible because of the record? Which dependency or exception will affect adoption?
- Connection
- Explain one deviation without automatic justification.
Deviation analysis
Explain one difference between plan and facts. Separate operating failures from external dependencies.
Go deeperQuality criteria
How to apply it
- Describe fact, condition and response.
- Separate personal control from external dependency.
- Separate the external dependency from the internal operating change.
Quality criteria
- The explanation uses facts.
- The action addresses the observed condition.
- The deviation separates internal owner and external dependency.
- Produces
- Deviation note for the team with ownership
- Example
- Synthetic team example: The block started late because input was not ready; prepare it the day before.
- Avoid
- Do not turn one case into a universal rule. Do not expose data or calendars without access rights.
- Reflect
- What alternative was under your control? Which dependency or exception will affect adoption?
- Connection
- Choose one rule to keep and one to adjust.
Rule for next week
Turn review into a testable adjustment. Prepare a rule that can be reviewed before scaling.
Go deeperQuality criteria
How to apply it
- Keep one useful practice.
- Change one friction and schedule review.
- Define sponsor, adoption gate and review date.
Quality criteria
- The rule is concrete and bounded.
- A review date and evidence are defined.
- The rule has a sponsor and adoption condition.
- Produces
- Reviewable weekly rule for the team with ownership
- Example
- Synthetic team example: Prepare inputs the day before; review on Friday.
- Avoid
- Do not change many rules at once if that hides what helped. Do not expose data or calendars without access rights.
- Reflect
- What evidence will keep or remove the rule? Which dependency or exception will affect adoption?
- Connection
- Add the rule to the visible system.
Repeat the system weekly and change one rule when evidence reveals recurring friction.
Turn a real week into a visible priority system: three justified outcomes, protected blocks, and a final review.
Pilot one rule with the team for another week
Repeat the cycle with one agreed change so its effect can be attributed.
- Name owner, reviewer and affected teams.
- Confirm rights, dependencies and exception path.
- Review adoption and evidence before expanding.
- Evidence
- Two comparable weeks, a team-level record and one documented adoption decision.
- Review
- At the end of the next week and before extending the rule to another team.
Closing rubric
Initial
The team records activity, but shared criteria, accountable roles or evidence are still missing.
Applicable
Priorities, protected blocks, accountable roles and shared review connect to evidence.
Transferable
Another team can adopt the rule because roles, exceptions and review are explicit.
Playbook
Continue with the next resource in the journey.
Workbook → Playbook