Handle uneven contribution by making visible work and hidden work explicit, then discuss capacity, role expectations, capability, and support before judging effort. Reset ownership and priorities, agree on specific behavior, and review the result. Fairness does not mean identical task counts. It means understandable expectations and proportionate responsibility.
Why does this teamwork problem persist?
Uneven workload often appears first as resentment. One engineer sees a teammate close fewer tickets, while another spends days reviewing code, handling incidents, or helping others. A third may truly be missing commitments. If the manager treats all differences as motivation problems, useful context disappears and trust worsens.
Separate workload, contribution, and performance. Workload is what a person carries. Contribution is the value and support they provide. Performance is how behavior compares with role expectations. These overlap, but they are not interchangeable.
Pressure exposes ambiguity. During a calm week, people can compensate through goodwill and extra effort. During a release, incident, or urgent customer request, the same gaps create delay and blame. The useful response is to make the operating expectation clear before asking individuals to try harder.
What should the team make explicit?
| Practice | Useful agreement |
|---|---|
| Map all work | Include delivery, review, incidents, mentoring, coordination, support, and repeated interruptions. |
| Check expectations | Clarify what the role requires and whether ownership was actually understood. |
| Explore conditions | Ask about capacity, missing knowledge, unclear decisions, access, health boundaries, and dependency delays. |
| Rebalance deliberately | Stop or move work, add support, narrow scope, and protect the people who absorb common interruptions. |
| Follow through | Set a review date and address continued gaps directly if support and expectations are clear. |
These agreements should be easy to find and easy to challenge. They are not a permanent constitution. They are current choices about how the team will work. Review them when membership, product risk, architecture, or demand changes materially.
How can the team improve step by step?
- 1. Map all work. Include delivery, review, incidents, mentoring, coordination, support, and repeated interruptions. Ask the team to describe what this looks like in current work, who will act, and what signal will show that the change helped. Keep the commitment small enough to observe during a normal delivery week.
- 2. Check expectations. Clarify what the role requires and whether ownership was actually understood. Ask the team to describe what this looks like in current work, who will act, and what signal will show that the change helped. Keep the commitment small enough to observe during a normal delivery week.
- 3. Explore conditions. Ask about capacity, missing knowledge, unclear decisions, access, health boundaries, and dependency delays. Ask the team to describe what this looks like in current work, who will act, and what signal will show that the change helped. Keep the commitment small enough to observe during a normal delivery week.
- 4. Rebalance deliberately. Stop or move work, add support, narrow scope, and protect the people who absorb common interruptions. Ask the team to describe what this looks like in current work, who will act, and what signal will show that the change helped. Keep the commitment small enough to observe during a normal delivery week.
- 5. Follow through. Set a review date and address continued gaps directly if support and expectations are clear. Ask the team to describe what this looks like in current work, who will act, and what signal will show that the change helped. Keep the commitment small enough to observe during a normal delivery week.
Do not launch every change at once. Choose the smallest practice that addresses the present constraint and name a review date. A focused change produces clearer evidence than a broad teamwork program. It also reduces the risk that people experience improvement work as another unowned burden.
How does this look in engineering work?
One engineer reviews most pull requests
Count review demand, reserve capacity, and build more domain reviewers through pairing. Begin with the work rather than a judgment about personality or commitment. Ask the people closest to the system what they see, including constraints that are easy for others to miss. Make ownership and timing explicit so the conversation produces a usable change.
Review work becomes planned rather than invisible. Review the result with actual examples rather than general impressions. If the response added meetings or shifted work to someone else, include that cost. The team should keep what improves the shared result and revise what only creates the appearance of control.
A teammate repeatedly misses estimates
Examine task size, interruptions, understanding, and early risk signals before resetting the commitment. Begin with the work rather than a judgment about personality or commitment. Ask the people closest to the system what they see, including constraints that are easy for others to miss. Make ownership and timing explicit so the conversation produces a usable change.
The response addresses the cause rather than only the symptom. Review the result with actual examples rather than general impressions. If the response added meetings or shifted work to someone else, include that cost. The team should keep what improves the shared result and revise what only creates the appearance of control.
On call work disrupts one person's sprint
Record incident effort and reduce planned delivery for the rotation owner. Begin with the work rather than a judgment about personality or commitment. Ask the people closest to the system what they see, including constraints that are easy for others to miss. Make ownership and timing explicit so the conversation produces a usable change.
The plan stops treating operational service as spare time. Review the result with actual examples rather than general impressions. If the response added meetings or shifted work to someone else, include that cost. The team should keep what improves the shared result and revise what only creates the appearance of control.
A fast engineer takes every urgent task
Limit rescue work, distribute context, and evaluate the cost to learning and maintainability. Begin with the work rather than a judgment about personality or commitment. Ask the people closest to the system what they see, including constraints that are easy for others to miss. Make ownership and timing explicit so the conversation produces a usable change.
Speed does not create permanent dependence. Review the result with actual examples rather than general impressions. If the response added meetings or shifted work to someone else, include that cost. The team should keep what improves the shared result and revise what only creates the appearance of control.
A remote teammate receives less informal help
Create visible requests, pairing access, and clearer response ownership. Begin with the work rather than a judgment about personality or commitment. Ask the people closest to the system what they see, including constraints that are easy for others to miss. Make ownership and timing explicit so the conversation produces a usable change.
Support does not depend on physical proximity. Review the result with actual examples rather than general impressions. If the response added meetings or shifted work to someone else, include that cost. The team should keep what improves the shared result and revise what only creates the appearance of control.
A performance gap remains after support
State the expected behavior, evidence, impact, timeline, and available help in a private conversation. Begin with the work rather than a judgment about personality or commitment. Ask the people closest to the system what they see, including constraints that are easy for others to miss. Make ownership and timing explicit so the conversation produces a usable change.
Accountability becomes direct and fair. Review the result with actual examples rather than general impressions. If the response added meetings or shifted work to someone else, include that cost. The team should keep what improves the shared result and revise what only creates the appearance of control.
What belongs in a 1 on 1 conversation?
Use a 1 on 1 to understand experience that may not surface in a group. Ask where collaboration feels dependable, where the person spends effort that others cannot see, and which decision or dependency is hardest to navigate. Listen for concrete events. Do not turn one account into a verdict about another teammate.
Share relevant expectations clearly. If behavior must change, describe the behavior, impact, and next observable commitment. If the issue comes from priorities, access, staffing, or authority, own the management action. Private context should inform fair decisions without becoming team gossip.
Return to the subject. A thoughtful conversation followed by silence teaches that raising the issue had little effect. At the next 1 on 1, explain what changed, what could not change, and what you learned. Consistent follow through is one of the simplest ways to make teamwork discussions credible.
How should progress be measured?
Measure the flow of shared work rather than ranking individual busyness. Useful signals include waiting for review, blocked time, reopened decisions, escaped defects, unplanned operational load, and commitments that change without explanation. Pair those signals with examples from the people doing the work.
A metric needs context. Shorter review time can mean better preparation or rushed approval. More completed tickets can mean improved flow or smaller low value tasks. Ask what behavior changed, who received the benefit, who absorbed the cost, and whether the user or operating result improved.
Look for earlier information. Healthier teams raise risks while options remain, ask for help before rescue is needed, and challenge assumptions without turning every discussion into a conflict. The goal is not a dashboard that proves teamwork is good. It is enough evidence to choose the next useful adjustment.
What should the team try this week?
Choose one current piece of work and write the shared outcome, active owners, next decision, main dependency, and review date. Ask every member what is missing or misleading. Resolve one ambiguity immediately, then assign any larger issue to a named owner. Keep the note where the team already works.
At the end of the week, compare the agreement with what happened. Notice where work waited, where someone carried an unexpected load, and where a decision lacked context. Thank people who surfaced inconvenient evidence. Improvement depends on making reality discussable, not on protecting the original plan.
Keep the next adjustment specific. Change one review rotation, decision record, goal statement, workload assumption, or follow through habit. Explain why the change was chosen and when it will be checked. Practical teamwork grows through repeated, visible choices that make shared work more reliable.
What do teams often ask?
How should a manager address uneven workload on a team?
Make all work visible, check capacity and expectations, rebalance priorities, provide needed support, and review specific commitments.
Does fairness mean giving everyone the same amount of work?
No. Fairness considers role, complexity, capacity, development, interruptions, and hidden contribution while keeping expectations understandable.
What hidden work should teams track?
Track review, mentoring, incidents, support, coordination, documentation, hiring help, and recurring emotional or social labor relevant to work.
When does uneven contribution become a performance issue?
It becomes a performance issue when clear role expectations are not met after context, authority, resources, and reasonable support have been addressed.
Should workload concerns be discussed with the whole team?
Discuss system patterns and allocation openly, but handle private circumstances and individual performance with appropriate confidentiality.
Related: how to work better as a team, how to set shared team goals, how to repair trust on a team.
Want a steadier way to prepare and follow through? Explore iSilta features or try the product demo.