Collaboration That Works: Shared Goals, Working Agreements and Healthy Communication

A story to begin with

Most collaboration problems are not about personalities. They are about incentives, information and structure. Fix those, and behaviour follows.

Start with shared goals

flowchart LR
  subgraph Before
    D1[Dev goal: ship features] --- X1((conflict)) --- O1[Ops goal: avoid change]
  end
  subgraph After
    S[Shared goal:<br/>customer outcome plus<br/>delivery speed and reliability]
    D2[Dev] --> S
    O2[Ops] --> S
    Q[Security] --> S
    P[Product] --> S
  end
  style S fill:#34d399,color:#062
  style X1 fill:#f87171,color:#fff

Good shared goals are:

• Outcome-based (customer experience, delivery performance), not activity-based.
• Visible on a dashboard everyone looks at.
• Joint: the same number is on everyone's scoreboard.
• Balanced: speed with stability, features with reliability.

Know who does what: lightweight ownership

Confusion about ownership causes dropped balls. For each service or process, write down:

A simple table like this (a light version of a responsibility matrix) removes most "I thought you were doing that" moments. Keep it in the service's repository or catalogue.

Working agreements

A working agreement is a short list of habits a team commits to together. It makes implicit expectations explicit, so newcomers and other teams know how to work with you.

Example agreements between development and operations:

1. Production changes go through the pipeline; nobody edits live systems by hand, except in a logged emergency.
2. Every service has a named owner and a documented on-call path.
3. Pull requests are reviewed within one working day.
4. Anyone can stop a release if a check is red, with no blame.
5. Incidents are reviewed within five working days, blamelessly, and actions are tracked.
6. We communicate in the shared channel, not in direct messages, for anything affecting others.
7. Meetings have an agenda and a decision owner, or they are cancelled.

Write them in one page, agree them in a 45-minute session, and revisit every quarter.

Decision records

Decisions that live in people's memories get re-argued every few months. A short decision record (sometimes called an architecture decision record) captures:

Title: Use GitOps for production deployments
Status: Accepted (2026-03-04)
Context: Manual kubectl changes caused drift and two incidents.
Options considered: keep manual changes; push-based CI; pull-based GitOps.
Decision: Adopt pull-based GitOps for production.
Consequences: Slower hotfix path (mitigated by an emergency procedure); need secrets tooling.

One page, stored beside the code, written in minutes. It saves hours of repeated debate and helps new joiners understand why.

Communication habits that reduce friction

Making meetings earn their time

• A clear purpose: decide, inform or brainstorm, never "sync".
• A written agenda shared beforehand, and notes with actions afterwards.
• Cap at the shortest useful length; use asynchronous updates for status.
• Rotate facilitation, so the same voices do not dominate.

Handling conflict early

Conflict is normal and healthy when it is about ideas. It becomes harmful when it is avoided or turns personal.

flowchart TD
  A[Disagreement noticed] --> B[Check the facts:<br/>what do we each actually know?]
  B --> C[Find the shared goal<br/>both sides care about]
  C --> D[List options and trade-offs<br/>in writing]
  D --> E{Agreement?}
  E -- yes --> F[Record the decision]
  E -- no --> G[Escalate to the agreed decision owner<br/>with both views summarised fairly]
  style C fill:#6366f1,color:#fff

Practical tips: address issues privately and promptly; describe the effect ("the deploy blocked three teams") rather than the person's character; ask for the other person's view first; agree who decides when you cannot agree.

Collaborating across roles

A one-month plan to improve collaboration between two teams

flowchart LR
  A[Week 1:<br/>listening session,<br/>list the top 5 frictions] --> B[Week 2:<br/>agree one shared goal<br/>and one dashboard]
  B --> C[Week 3:<br/>write a working agreement<br/>and ownership table]
  C --> D[Week 4:<br/>joint retrospective,<br/>pick the next experiment]
  style B fill:#6366f1,color:#fff

1. Week 1: listen. Run a 60-minute session with both teams and ask each: "What is the most frustrating thing about working with the other team?" Write answers on cards, group them, and thank people for honesty. Do not defend.
2. Week 2: align. Choose one shared outcome measure and put it on one visible dashboard.
3. Week 3: write down. Draft the working agreement and an ownership table. Agree them together.
4. Week 4: review and iterate. Hold a joint retrospective, pick one improvement for the next month, and book the next review.
5. Keep going: a quarterly joint retrospective prevents drift.

Pitfalls

• Agreements written by managers and not by the people who live by them.
• Shared goals that are really one team's goal with a new name.
• Treating a single heated incident as proof the other team is difficult.
• No follow-up: agreements that are never revisited fade.

Interview questions

Q1. How do you get development and operations to collaborate better? Give them shared outcome goals and dashboards, joint on-call, shared ownership of services, working agreements, and regular joint retrospectives, so their incentives align.

Q2. What is a working agreement? A short, jointly written list of team habits and expectations (how changes are made, review times, communication, incident follow-up) that makes implicit rules explicit.

Q3. Why write decision records? They preserve the context, options and reasoning behind a decision, preventing repeated debates and helping new people understand why things are as they are.

Q4. How do you handle a disagreement between two teams? Establish facts, restate the shared goal, list options and trade-offs in writing, seek agreement, and escalate to the agreed decision owner with both views summarised fairly if needed.

Q5. What makes a meeting worth holding? A clear purpose (decide, inform or ideate), an agenda sent in advance, the right people, a decision owner and written actions afterwards.

Next: unlock Blameless Culture and Learning from Failure for incident learning practices.