Skip to main content

Communication & Collaboration

The biggest bottleneck in most software projects is not technical. It is the gap between what one person knows and what the team needs to know. Good communication practice does not mean more meetings or longer messages. It means the right information reaches the right people at the right time, in a format they can act on without chasing you down.

Why this matters​

S&P's value of Teamwork is not an abstraction -- it is a daily practice of making information accessible. A developer who finishes a critical architectural decision but only tells the person sitting next to them has created a knowledge silo. A sprint ceremony that runs 45 minutes without a clear outcome has consumed the team's most expensive resource -- focused time -- and returned nothing.

Communication is also where Care becomes visible. When you write a clear Jira ticket, you are caring about the next person who picks it up. When you document a decision, you are caring about the future developer (possibly yourself) who will need to understand why. Every minute you invest in clear communication saves multiples of that time downstream.

The standard​

Async-first, sync when needed​

S&P operates with distributed and hybrid teams. The default communication mode is asynchronous -- written, persistent, and searchable. Synchronous communication (meetings, calls, screen shares) is the escalation path when async is not working, not the starting point.

Why async-first works:

  • It respects focus time. A Slack message can wait; a meeting cannot.
  • It creates a record. A Confluence page is findable six months later; a verbal agreement is not.
  • It crosses time zones. Written communication does not require everyone to be online at the same time.
  • It forces clarity. Writing a thought out fully exposes gaps that speaking off the cuff hides.

When to go synchronous:

  • The topic has gone back and forth async more than twice without resolution.
  • The discussion involves nuance that text cannot convey (architectural trade-offs with many variables, interpersonal conflict, sensitive feedback).
  • You need a decision from multiple people within the hour (incident response, release-blocking issue).
  • Onboarding a new team member -- the first week benefits heavily from live interaction.
  • Pair programming or debugging sessions where the feedback loop needs to be tight.

The rule is: start async, escalate to sync when the conversation stalls or the stakes demand it. After any synchronous discussion, capture the outcome in writing (Slack summary, Confluence page, Jira comment). A decision made in a call but not written down is a decision that will be relitigated.

Slack conventions​

Slack is the primary real-time communication tool. Without conventions, it becomes a firehose of noise that pulls people out of deep work.

Channel structure:

Channel patternPurposeExamples
#proj-[name]Project-specific discussion#proj-vetapp, #proj-clientportal
#proj-[name]-devTechnical discussion for the dev team#proj-vetapp-dev
#proj-[name]-alertsAutomated alerts (CI, monitoring, errors)#proj-vetapp-alerts
#eng-[topic]Engineering-wide discussions#eng-architecture, #eng-frontend
#team-[name]Team coordination#team-backend, #team-qa

Message etiquette:

  • Use threads. Every reply to a message belongs in a thread. Unthreaded replies in busy channels make it impossible to follow any single conversation.
  • Don't use @channel or @here unless it's urgent. If only two people need to see it, mention them by name. If the whole channel needs to see it but not immediately, post without a mention.
  • Front-load the ask. Start with what you need, then provide context. "Can someone review PR #342? It's a hotfix for the auth token expiry bug" is better than three paragraphs of context followed by a buried request.
  • Use message formatting. Code blocks for code, bullet points for lists. A wall of unformatted text gets skimmed or skipped.
  • Set your status when unavailable. If you are in deep work, in a meeting, or offline, your status should say so. This reduces "why aren't they responding?" anxiety.
  • Respond to direct questions within the business day. If you cannot answer yet, acknowledge the message: "Seen -- I'll look into this after my current task."

What does not belong in Slack:

  • Decisions that need to persist. Slack messages are ephemeral in practice (hard to search, easy to miss). Anything that qualifies as a decision should be captured in Confluence, a Jira ticket, or an ADR in the repo.
  • Long technical discussions. If a Slack thread exceeds 15 messages, it has outgrown Slack. Move it to a Confluence page or schedule a 15-minute call, then post the summary.
  • Code reviews. Those happen in Bitbucket, not Slack DMs.

Technical documentation culture​

Documentation is not a deliverable you produce at the end. It is a byproduct of good engineering practice throughout the project.

What to document and where:

Content typeWhere it livesWho maintains it
Architecture decisions (project-scoped)docs/decisions/ in the repoThe engineer who made the decision
Architecture decisions (cross-team)Confluence DACI boardThe decision Driver
API contractsOpenAPI spec in the repoBackend team
System architecture diagramsConfluence (client-facing) or repo (internal)Tech lead or DRI
Runbooks and operational proceduresConfluenceDevOps / on-call engineers
Sprint retrospective outcomesConfluenceScrum master / delivery manager
Onboarding guidesConfluenceTeam lead, updated by recent joiners
Meeting notes with action itemsConfluence or Jira (linked)Meeting organiser

ADRs and RFCs:

Architecture Decision Records are covered in detail in Architecture & System Design. The communication principle here is: write the ADR before the decision is final, not after. An ADR published after implementation is a historical record. An ADR shared before implementation is an invitation for feedback. The latter is more valuable.

For larger changes that affect multiple teams or introduce significant new patterns, use an RFC (Request for Comments) approach: write a short design document, share it in the relevant #eng- Slack channel and on Confluence, and give reviewers 2-3 business days to respond before proceeding. This is the Nemawashi principle in practice -- build informal consensus through consultation before making the formal decision.

Design docs:

Not every change needs an ADR or RFC. But any change that takes more than a sprint and involves more than one person benefits from a short design document -- even just a page with:

  1. What we are building and why
  2. How it will work (with a diagram if multiple services are involved)
  3. What we are explicitly not doing
  4. Open questions

Share it with the team before writing code. The 30 minutes spent writing this saves hours of rework when someone discovers a missed requirement in week three.

Nemawashi: consensus before commitment​

The CTO has adopted the Nemawashi principle as a core part of how S&P makes decisions, and it is referenced in Engineering Principles. The communication implication is practical: before you bring a significant proposal to a formal meeting or decision record, socialise it informally first.

How Nemawashi works in practice at S&P:

  1. Draft your thinking. Write a short document or Slack message outlining the proposal, the reasoning, and the alternatives you considered.
  2. Share it 1-on-1. Before posting broadly, share it with the 2-3 people most affected. Ask for their honest reaction. Listen.
  3. Incorporate feedback. Adjust the proposal based on what you heard. If someone has a strong objection, address it before the group discussion.
  4. Bring it to the group. By the time the proposal reaches a team meeting or a formal ADR/DACI, the people most affected have already seen it, shaped it, and are aligned. The meeting becomes a ratification, not a debate.

Why this matters more than it seems: Surprising people with a major change in a meeting creates defensiveness. People who feel blindsided push back on principle, even if the proposal is sound. Nemawashi de-risks the decision process by making alignment incremental rather than all-at-once.

When to skip Nemawashi: Routine decisions, bug fixes, standard implementation choices. Nemawashi is for decisions that change how people work, what tools they use, or how the system is structured. If the blast radius is small, just make the decision and document it.

Meeting hygiene​

Meetings are expensive. A one-hour meeting with six people costs six engineering hours. Treat that cost seriously.

Before the meeting:

  • Every meeting has a written agenda shared at least 2 hours before (ideally when the invite is sent). "Sync up" is not an agenda. "Decide on the caching strategy for the product catalogue API" is an agenda.
  • Include pre-reading if applicable. Attendees who arrive uninformed waste everyone's time getting up to speed.
  • Invite only people who need to be there. If someone just needs to know the outcome, send them the notes afterward.

During the meeting:

  • Start on time. Waiting for latecomers punishes the people who showed up on time.
  • One person takes notes. Rotate this responsibility -- it should not always fall to the same person.
  • Track action items explicitly: who will do what by when. Vague commitments ("we should look into that") are not action items.
  • If the discussion goes off-topic, park it. "That's a good point -- let's take it offline" is a valid redirect.

After the meeting:

  • Post the notes and action items within 24 hours. Confluence for recurring meetings, Jira comments for sprint-related items.
  • Action items must have owners and deadlines. If they do not, the meeting produced discussion but not progress.

Recurring meetings to audit regularly:

Every quarter, review recurring meetings and ask: "If this meeting did not exist, would we recreate it?" If the answer is no, cancel it. Meeting bloat is incremental -- each one seems harmless, but collectively they fragment the team's week.

Sprint ceremonies​

S&P follows sprint-based delivery. The standard ceremonies exist for good reasons, but they become wasteful when they are performed mechanically without intention.

Sprint planning:

  • The goal is a shared understanding of what the team will deliver this sprint and why. If the team leaves planning without knowing the sprint goal, the ceremony failed.
  • Tickets entering the sprint must meet the "definition of ready": clear acceptance criteria, estimated, and dependencies identified. If a ticket is not ready, it does not enter the sprint.
  • Time-box to 1 hour for a two-week sprint. If planning consistently exceeds this, the backlog is not groomed well enough.

Daily standup:

  • Three questions, answered concisely: what did I do, what will I do, what is blocking me. This is a synchronisation tool, not a status report to management.
  • Time-box to 15 minutes, strictly. Long discussions go to a "parking lot" and are resolved immediately after standup with only the relevant people.
  • If the team is working on independent tasks with no dependencies, consider replacing the daily standup with an async Slack standup in the project channel. The purpose of the ceremony is coordination -- if coordination needs are low, the ceremony can be lighter.

Sprint review / demo:

  • Show working software. Slides about what was done are not a demo. Open the application and demonstrate the feature.
  • Include the client or product owner. This is their opportunity to see progress and provide feedback before the next sprint.
  • If nothing was completed this sprint, be transparent about why. Do not pretend partial work is complete.

Sprint retrospective:

  • This is the most important ceremony for long-term team health. Protect it.
  • Use a structured format (Start/Stop/Continue, 4Ls, sailboat) to avoid aimless discussion.
  • Every retrospective must produce 1-3 concrete action items with owners. A retro without action items is a venting session.
  • Follow up on previous retro action items at the start of each retro. Accountability makes the ceremony credible.

Cross-team collaboration​

S&P projects sometimes involve multiple teams -- frontend and backend, or multiple squads on a larger engagement. Cross-team communication needs explicit structure; it will not happen organically.

Patterns that work:

  • Shared Slack channels. Every project that spans teams uses a shared #proj-[name] channel. Technical sub-discussions happen in #proj-[name]-dev.
  • Sync points. If two teams have dependencies within a sprint, schedule a 15-minute mid-sprint sync to surface blockers early. Do not wait until the sprint review to discover a dependency was missed.
  • API contracts as communication. Frontend and backend teams align on the API contract (OpenAPI spec) before building. This is the communication mechanism -- see Architecture & System Design for details. Disagreements about the contract are resolved in the contract, not in Slack after both sides have built their implementations.
  • Shared definition of done. When a feature crosses team boundaries, agree on what "done" means for the whole feature, not just each team's piece. A backend endpoint that is deployed but untested by frontend is not done.

Patterns that fail:

  • Relying on a single person as the communication bridge between teams. If that person is unavailable, the teams are disconnected.
  • Assuming the other team "knows" about a change because it was in a PR. If the change affects their work, tell them directly.
  • Scheduling cross-team meetings without a clear agenda. These become unfocused and people stop attending.

Remote and hybrid communication norms​

S&P teams work across offices and remotely. Communication norms must account for this.

  • Default to written communication. If a conversation happens in person or on a call, the outcome gets written down afterward. Remote team members should never be at an information disadvantage because they were not physically present.
  • Video on for meaningful discussions. For quick syncs, video is optional. For retrospectives, planning, and design discussions, video helps read the room and builds connection.
  • Record important meetings. Sprint reviews, architecture reviews, and knowledge-sharing sessions should be recorded for team members in different time zones.
  • Over-communicate on status. In an office, people can see that you are at your desk, in a meeting, or away. Remote workers need to make their availability explicit -- Slack status, calendar blocks, and proactive updates when plans change.

Knowledge sharing​

Knowledge that lives in one person's head is a single point of failure for the team. S&P invests in deliberate knowledge sharing, not just as a cultural nice-to-have but as an engineering practice that improves bus factor and code quality.

Mechanisms:

  • Pair programming. Not for every task, but deliberately for complex features, onboarding, and cross-pollination between senior and junior engineers. See Code Review for how pair programming relates to the review process.
  • Tech talks / brown bags. Monthly internal sessions where an engineer presents a topic they have learned or a problem they solved. Keep them short (20-30 minutes) and practical. Record them for people who cannot attend live.
  • Written knowledge sharing. A short Slack post in #eng-architecture or #eng-frontend about a useful pattern, a gotcha you discovered, or a tool that saved time. These are low-effort, high-impact. They compound over time.
  • Code walkthroughs. When a complex feature is merged, the author walks the team through the code in a 15-minute session. This is different from code review -- it is about transferring understanding of the design decisions, not catching bugs.
  • Cross-project rotation. When possible, rotate engineers across projects periodically. This spreads knowledge, prevents silos, and gives engineers breadth. Even a two-week rotation is valuable.

Jira hygiene​

Jira is the project management tool. Its value is directly proportional to the quality of the data in it.

Ticket quality:

  • Every ticket has a clear title that describes the outcome, not the activity. "Implement caching for product list API" is better than "Caching work."
  • Acceptance criteria are written before the sprint, not during development. If the acceptance criteria are unclear, the ticket is not ready for the sprint.
  • Link related tickets (blocks, is blocked by, relates to). This makes dependencies visible during planning.
  • Attach relevant context: Confluence links, design mockups, API specs. The person picking up the ticket should not need to ask "where is the design?"

Status updates:

  • Move tickets through the workflow (To Do, In Progress, In Review, Done) as work progresses. A board full of "In Progress" tickets tells the team nothing.
  • Add comments when the work deviates from the original plan. If a ticket takes twice as long as estimated, a brief comment explaining why helps future estimation.
  • Do not leave tickets in "In Review" for more than one business day. If a PR is waiting for review, actively seek a reviewer rather than waiting passively.

Sprint hygiene:

  • Tickets that were not completed in the sprint are explicitly carried over with a note explaining why, not silently moved.
  • Do not create Jira tickets retroactively to justify work that was not planned. If unplanned work happened, discuss it in the retrospective.

Confluence organisation​

Confluence is the knowledge base. Without active curation, it becomes a graveyard of outdated pages that nobody trusts.

Structure:

  • Every project has a Confluence space with a predictable structure: Overview, Architecture, Runbooks, Meeting Notes, Retrospectives, Decision Records (DACI).
  • Use the Confluence page hierarchy. Flat spaces with dozens of top-level pages are unnavigable. Group related content under parent pages.
  • Name pages descriptively. "Notes" and "Design" are not findable. "Product Catalogue API - Cache Strategy Design" is findable.

Maintenance:

  • Page owners are responsible for keeping content current. If a page has no owner, it is abandoned and should be archived or marked as potentially outdated.
  • Add a "Last reviewed" date to long-lived pages (runbooks, architecture docs). If the date is more than six months old, the content should be treated as suspect.
  • Synced pages from the engineering-playbook repo show a banner indicating they are auto-generated and should not be edited directly on Confluence.

Onboarding communication​

The first two weeks of a new engineer's experience shape their confidence and productivity for months. Onboarding communication should be deliberate, not improvised.

The onboarding checklist approach:

  • Maintain a Confluence page with the onboarding checklist for each project (or a generic one for the engineering org). Include: access to repositories, Jira, Confluence, Slack channels, CI/CD dashboards, staging environments, and relevant documentation.
  • Assign an onboarding buddy -- a specific person (not the tech lead) who is available for questions during the first two weeks. The buddy's role is to reduce the friction of asking "obvious" questions.
  • Schedule a project walkthrough in the first week: system architecture (C4 diagrams from Architecture & System Design), codebase structure, local setup (from Developer Experience & Setup), and current sprint context.

The new joiner's contribution to documentation:

New engineers are the best editors of onboarding documentation. What was confusing? What was missing? What was out of date? Ask new joiners to update the onboarding page as they go through it. Their fresh perspective catches gaps that the existing team has become blind to.

This practice ties directly into Learning & Growth -- onboarding is the first learning experience at S&P, and it sets the tone for continuous improvement.

Critical thinking​

  • Async-first does not mean async-only. Some teams take the async principle too far and avoid all meetings, leading to slow decisions and isolation. The goal is not to minimise meetings to zero -- it is to make every meeting earn its place. A well-run 30-minute design discussion can save days of async back-and-forth.

  • Communication overhead scales non-linearly. A team of three can communicate informally. A team of six needs lightweight structures (standups, shared channels, documented decisions). A team of twelve needs explicit protocols. Do not apply a twelve-person team's communication overhead to a three-person team, and do not expect a twelve-person team to work with a three-person team's informality.

  • Tool fatigue is real. Slack, Jira, Confluence, Bitbucket, email -- that is already five communication surfaces. Before adding another tool, ask whether it replaces one of these or adds another place to check. Every new tool fragments attention.

  • Not every conversation needs to be documented. Quick questions in Slack, informal design brainstorms, rubber-duck debugging -- these are valuable precisely because they are lightweight. Only escalate to documentation when the outcome needs to persist beyond the conversation.

  • Sprint ceremonies can be adapted. The ceremonies described above are starting points. If daily standups are not adding value for a small, co-located team, try async standups. If retrospectives have become stale, change the format. The principle (synchronise the team, reflect on process) matters more than the specific ritual.

  • Jira is a tool, not a management philosophy. The goal is not a perfectly maintained Jira board. The goal is that the team knows what they are working on, what is blocked, and what is coming next. If a simpler tool achieves this, use the simpler tool. But if you are using Jira, use it well -- half-maintained project management tools are worse than no tool because they create a false sense of visibility.

Checklist​

For every project​

  • Slack channels follow the naming convention (#proj-[name], #proj-[name]-dev, #proj-[name]-alerts)
  • A Confluence space exists with a structured hierarchy (Overview, Architecture, Runbooks, Meeting Notes, Decisions)
  • An onboarding checklist exists on Confluence and is updated by each new joiner
  • Sprint ceremonies have fixed time-boxes and produce documented outcomes
  • Retrospective action items have owners and deadlines, and are followed up on
  • Cross-team dependencies are identified during sprint planning and have explicit sync points

For every engineer​

  • Slack threads are used for replies in shared channels
  • Direct questions receive a response or acknowledgment within the business day
  • Decisions from synchronous conversations are captured in writing (Confluence, Jira, or the repo)
  • Jira tickets are moved through the workflow as work progresses
  • Significant proposals are socialised informally (Nemawashi) before being brought to the group
  • Code walkthroughs or documentation are provided for complex merged features

For every meeting​

  • A written agenda was shared before the meeting
  • Notes and action items were posted within 24 hours
  • Action items have owners and deadlines
  • Only the people who needed to be there were invited

AI tips​

  • Draft technical design docs. Describe the problem, constraints, and your initial thinking. Ask AI to structure it into a design document with sections for context, proposed approach, alternatives considered, and open questions. AI is good at organising scattered thoughts into a readable format -- you supply the substance.
  • Summarise long Slack threads. When a Slack discussion has grown past 20 messages, paste the thread into AI and ask for a summary with key decisions and open questions. Post the summary back to the channel so people can catch up without reading the full thread.
  • Generate meeting agendas. Describe the meeting's purpose and the current state of the discussion. AI can draft an agenda with time allocations and decision points. Adjust based on what you know about the participants and the urgency.
  • Improve Jira ticket quality. Paste a vague ticket description and ask AI to rewrite it with clear acceptance criteria, edge cases, and links to relevant documentation. AI is particularly good at identifying implicit assumptions that should be made explicit.
  • Draft onboarding documentation. Describe the project's architecture, local setup steps, and key tools. AI can structure this into an onboarding guide. Have a recent joiner review it -- they will catch the gaps that AI (and you) missed.
  • Write RFC and ADR drafts. Describe the decision context, the options you are considering, and the trade-offs you see. AI can produce a well-structured first draft that you refine. This lowers the activation energy for writing decision records, which means more decisions get documented.
  • Translate technical decisions for non-technical stakeholders. Paste a technical decision record and ask AI to rewrite it for a product owner or client audience. AI is good at removing jargon while preserving the essential reasoning.

Resources​

S&P internal:

Playbook cross-references:

External references: