6. Make it stick (the first two weeks)

Tool rollouts usually fail not because a feature is missing but because there is no agreed way of working. Decide the first two weeks in advance.

Week 1: just get the work in

The goal this week is that none of your team’s work exists outside UTSUROI.

Rules to agree on

1. Requests happen somewhere that persists. Not verbally, not in DMs.
2. Every request gets a due date and a ball holder. “Someone, this week” is not a request.
3. When in doubt, create it. Duplicates can be archived. Not creating costs more.

What not to do this week

• Elaborate lane design
• Designing a label taxonomy
• Looking at analytics

There is no data yet, so analytics will tell you nothing. Design comes in week two, after you have seen where things actually jam.

Week 2: look at the stalls

Once there is data, take ten minutes once a week.

Open Insights → Risks, where stalled tasks collect.

Questions to ask

• Any task with no ball holder? → Nobody’s turn. It is stopped.
• Any task with no due date? → It cannot be detected as stalled.
• Any task sitting in one lane for a long time? → That lane is where waiting is produced.

The third one matters most. If items pile up in a specific lane (awaiting review, awaiting approval), that lane is your organization’s synchronization point. That is where the work of lowering your synchronous share happens.

Full procedure: The weekly stall review.

After that

Two things change the picture again:

• Connect MCP — generate tasks from meeting notes, let AI write the morning summary
• Deriving realistic due dates from velocity

When it is not working

Symptom	Usual cause
Tasks are not being created	Requests still flow through DMs and hallways. Slack not connected
Lots of tasks with no due date	No habit of deciding a date at request time. Go back to rule 1
Nobody looks at the board	Boards are sliced too finely; people cannot find their own work
Notifications are noisy	Too many enabled. Go back to overdue-only