Learning objectives
- Identify a coordination problem using work evidence.
- Make responsibilities and handovers explicit.
- Review team routines without turning them into personal rankings.
Start with a shared task and clear responsibilities
Choose a task requiring more than one person, such as turning a customer request into a completed service. Identify who makes the decision, who performs each part and who needs to be consulted. Use O*NET's structured approach to tasks and skills as a reference for describing work, then adapt it to the actual role. A job title alone does not explain authority, workload or the knowledge needed for a successful handover.
Create conditions for questions and early warnings
Agree how team members ask for help, raise uncertainty and report an error without humiliation. This does not remove accountability; it makes problems visible while there is still time to respond. Google's Project Aristotle account discusses psychological safety alongside dependability, clarity, meaning and impact in its organisational setting. Translate these into concrete conversations about your team rather than assuming that copying terminology will reproduce Google's findings.
Practise together and revise the routine
Select one recurring breakdown and rehearse the handover or decision involved. Produce a brief example of complete work and compare actual samples with it. Hold a short review focused on what made the task easier or harder. Distinguish missing skill from missing time, permission or information. Change one routine, assign ownership and revisit it. Use work quality, delay and effort as complementary evidence; a single score can hide trade-offs or discourage reporting.
A coordination improvement cycle
An original aid for a team discussing its own work.
Map
Describe the shared task, dependencies and decision owner.
Practise
Try a clear handover or decision routine.
Review
Use samples and feedback to refine the routine.
Comparison
| Shared task | Agreement | Evidence |
|---|---|---|
| Customer intake | Define the required brief and its owner | Delivery can explain the request. |
| Technical review | Name the reviewer and escalation route | Uncertainty is raised before commitment. |
| Completion | Agree acceptance and documentation | The next user can continue the work. |
Hypothetical example: a delivery team
Imagine a five-person service team missing deadlines because requests arrive without essential details.
- The team maps the intake handover and discovers that everyone assumed someone else confirmed the deadline. It names one intake owner and defines a short brief.
- Members rehearse a difficult request, then review several real, authorised samples. They note clarification time as well as completeness to avoid creating unnecessary paperwork.
The review can show whether that routine is useful locally. It cannot prove that one workshop causes productivity gains or establish a universal team ranking.
Practical checklist
- Name the shared task and decision owner.
- Make it possible to ask for help and report uncertainty.
- Review one changed routine with relevant work samples.
Common pitfalls
Team building without work changes
A pleasant event does not clarify an ambiguous handover.
Safety confused with no standards
Respectful discussion and clear responsibility should reinforce one another.
Questions and answers
Is team development only a manager's job?
The manager should provide time, authority and fair conditions, but members hold important knowledge about actual dependencies. Develop routines together and make ownership explicit rather than expecting the manager to diagnose every difficulty alone.
How often should a team review its routines?
Use a cadence appropriate to the work and review sooner after a meaningful change or repeated breakdown. Keep the meeting focused on a specific task and an actionable adjustment. Frequency alone does not make a review useful.
Sources and further reading
- Google re:Work: team effectivenessGoogle re:Work
A primary account of Google's research; findings remain context-dependent.
- O*NET Content ModelO*NET Resource Center — U.S. Department of Labor programme
An official task-and-skill structure that can inform local role descriptions.
