Collaboration
Communicate context, review ideas fairly, and make it safe to surface risks and ask for help.
Collaboration is not agreement. It is the ability to combine different information and perspectives into a decision the team can execute and revisit.
Communicate for the reader
Give people what they need to act:
- Status: outcome, current state, next step, owner, and expected time.
- Risk: what may happen, likelihood, impact, evidence, and the decision needed.
- Incident: user impact, scope, mitigations, next update time, and where work is coordinated.
- Proposal: problem, constraints, options, recommendation, trade-offs, and review deadline.
- Request for help: goal, what you tried, observed results, and the smallest question blocking progress.
Lead with the important fact. Add detail beneath it. Separate observations from interpretation.
Ask for help early
Early help is responsible risk management, not weakness. Before asking, gather enough context for another person to enter the problem without repeating all your work. After receiving help, close the loop with the result and document anything others may need again.
Leaders reinforce this behavior when they thank people for surfacing uncertainty and respond without humiliation. Google’s team-effectiveness work identifies psychological safety—feeling able to take interpersonal risks—as a key team dynamic.
Review work with respect
Review the change, not the author.
| Avoid | Prefer |
|---|---|
| “This makes no sense.” | “I cannot trace how this handles a timeout. Could we add that path to the description?” |
| “Just use Redis.” | “The requirement looks like shared expiration across instances. Redis is one option; what trade-off led to the current approach?” |
| “You broke production.” | “This change interacted with an undocumented dependency. Let’s restore service, then add a guard for that condition.” |
Label comments when useful: blocking, suggestion, question, or note. Explain the risk behind a blocking comment. Authors should make the change understandable; reviewers should respond within the team’s expected time.
Disagree and still move forward
- Restate the shared outcome.
- Identify the specific point of disagreement.
- Name the evidence that would change each person’s view.
- Choose a small experiment when the decision is reversible.
- Ask the accountable owner to decide when time is bounded.
- Record the decision and support it after it is made.
Escalate when there is material risk to users, security, legality, ethics, or the company—not to win a preference argument.
Give useful feedback
Useful feedback is timely, specific, and connected to impact:
For corrective feedback, discuss the observed behavior and its effect, listen for missing context, and agree on a concrete next behavior. Do not collect surprises for a performance review.
Make meetings earn their time
- Send context before the meeting.
- State whether the goal is a decision, review, planning, or information sharing.
- Invite the people needed for the outcome, not everyone nearby.
- Use written input so quieter or remote teammates can contribute.
- End with decisions, owners, and dates.
- Cancel a recurring meeting when it no longer produces value.
Share credit and context
Name the people who investigated, reviewed, operated, documented, and supported the work—not only the person who merged the final code. Share difficult work as well as visible work. This builds trust and makes contribution pathways clear to new team members.