# How do you work better as a team? **You work better as a team by making five things explicit: what success means, how work is shared, who decides, how people coordinate, and how trust is repaired after strain. Strong teamwork is not constant harmony. It is a reliable way to handle dependence, disagreement, and changing conditions without losing sight of the result.** ## Why does this teamwork problem persist? Many engineering teams contain capable people but still struggle because their work does not join together cleanly. Each person may complete assigned tasks while priorities compete, reviews wait, and important decisions remain implicit. The team needs a small operating system for shared work, not another appeal to communicate more. Treat teamwork as observable behavior. A useful agreement names what people will do when work changes, a review is blocked, or a decision has no obvious owner. This makes improvement practical because the team can inspect behavior and adjust it. 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 | | --- | --- | | Set one shared result | Describe the user or operating outcome, the evidence that will show progress, and the constraints the team must protect. | | Make work visible | Show active work, waiting work, review demand, and ownership so hidden queues do not become private burdens. | | Clarify decisions | Name who recommends, who contributes context, who decides, and how the result will be recorded. | | Balance contribution | Discuss capacity and less visible work before resentment turns a workload problem into a character judgment. | | Repair strain | Name the event, listen to impact, agree on changed behavior, and follow through long enough to rebuild confidence. | 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. **1. Set one shared result.** Describe the user or operating outcome, the evidence that will show progress, and the constraints the team must protect. 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. 1. **2. Make work visible.** Show active work, waiting work, review demand, and ownership so hidden queues do not become private burdens. 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. 1. **3. Clarify decisions.** Name who recommends, who contributes context, who decides, and how the result will be recorded. 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. 1. **4. Balance contribution.** Discuss capacity and less visible work before resentment turns a workload problem into a character judgment. 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. 1. **5. Repair strain.** Name the event, listen to impact, agree on changed behavior, and follow through long enough to rebuild confidence. 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. ## Which five teamwork practices belong together? This series follows five connected conversations. The practices work together because a clear goal can fail under hidden workload, and a sound decision can fail when trust is damaged. 1. [What makes a good team?](https://isilta.com/blog/what-makes-a-team-work-well/) explains what makes a good team through concrete engineering situations and actions. 1. [How do you set shared team goals?](https://isilta.com/blog/how-to-set-shared-team-goals/) explains team goals through concrete engineering situations and actions. 1. [How do you handle uneven contribution on a team?](https://isilta.com/blog/how-to-handle-uneven-contribution/) explains uneven workload on a team through concrete engineering situations and actions. 1. [How do you make team decisions?](https://isilta.com/blog/how-to-make-team-decisions/) explains team decision making through concrete engineering situations and actions. 1. [How do you repair trust on a team?](https://isilta.com/blog/how-to-repair-trust-on-a-team/) explains rebuilding trust on a team through concrete engineering situations and actions. Use the hub as a diagnostic. Start with the practice that is causing the most friction now, but check its neighbors. A workload dispute may reveal an unclear goal. A slow decision may reveal that people do not trust how dissent will be handled. Improving one connection often makes the next conversation easier. ## How does this look in engineering work? ### A service migration has many owners Choose one outcome owner, divide technical areas clearly, and hold a short dependency review twice a week. 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. Blocked work becomes visible before the release date is threatened. 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. ### Pull request review sits with one senior engineer Map review demand, add protected review time, and teach two more engineers the common review patterns. 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. Waiting time falls without lowering the review standard. 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. ### Product and platform priorities conflict Write the competing outcomes, name the decision owner, and set a date for the choice. 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. Engineers stop interpreting silence as permission to pursue different plans. 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 quiet engineer carries operational work List alerts, support, release help, and mentoring beside planned feature work. 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. Planning reflects total contribution instead of ticket count alone. 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 design argument becomes personal Restate the shared goal, separate evidence from preference, and record the chosen tradeoff. 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. People can disagree without turning the decision into a contest of status. 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 missed commitment damages confidence Discuss what happened, identify the preventable condition, and agree on one visible follow through behavior. 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. Trust rests on new evidence rather than a request to move on. 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? ### What is the first step to working better as a team? Start by agreeing on one shared outcome and the evidence that will show progress. Clear goals make workload, priority, and decision conversations more concrete. ### Does good teamwork require everyone to agree? No. Good teams make disagreement useful, assign decision authority, record the choice, and support execution after concerns have been heard. ### How often should a team review how it works? Use brief checks during delivery and a deeper review after a milestone, incident, or material change in workload or membership. ### What should managers do when teamwork is weak? Managers should clarify conditions, surface hidden work, protect candid discussion, and hold people to specific behaviors without taking every decision away from the team. ### Can a team improve without adding meetings? Yes. Many improvements come from clearer written goals, visible work, recorded decisions, focused review time, and better use of existing meetings. Related: [what makes a team work well](https://isilta.com/blog/what-makes-a-team-work-well/), [how to set shared team goals](https://isilta.com/blog/how-to-set-shared-team-goals/), [how to handle uneven contribution](https://isilta.com/blog/how-to-handle-uneven-contribution/). Want a steadier way to prepare and follow through? Explore [iSilta features](https://isilta.com/features/) or try the [product demo](https://isilta.com/demo/).