Engineering Communication Guidelines¶

Purpose¶

Effective communication ensures engineering work is delivered efficiently without unnecessary interruptions or lost context.

This guideline defines how communication should occur so that:

Work is visible and trackable
Urgency is clear and appropriate
Focus time for complex tasks is protected

This supports the Engineering Operating Principles, particularly:

Urgency is defined, not assumed
Deep work requires protected focus time
Work should be visible and documented

Core Approach¶

1. Async by Default¶

Engineering communication should be asynchronous unless something is actively blocking work or impacting production.

This allows:

Better focus for complex tasks
More thoughtful responses
Reduced context switching

Immediate responses should not be expected for standard queries.

Messages sent outside standard working hours are considered asynchronous and do not require immediate acknowledgement. They will be reviewed on the next business day unless they meet the defined urgent escalation criteria.

2. Shared Context Over Private Messages¶

Whenever possible, communication should occur in shared channels or documented systems, not direct messages.

This ensures:

Knowledge is visible to the team
Questions only need to be answered once
Work is not dependent on a single individual

Direct messages should be reserved for:

Sensitive information
Short clarifications that do not impact broader work

3. Slack Is for Communication, Not Task Tracking¶

Slack messages should not be treated as formal work requests.

All actionable work must exist in the designated task tracking system (e.g. ClickUp/Jira/etc.).

If a request is made via Slack and requires work:

It should be converted into a tracked task before being prioritised.

This ensures:

Clear prioritisation
Visibility of workload
Accurate planning

4. Define Urgency Explicitly¶

If something is urgent, it should be clearly marked as urgent and include:

What is impacted
Who is impacted
What the business impact is
Required timeframe

Without this context, requests will be treated as standard priority.

5. Reduce Interrupt-Driven Work¶

Non-blocking questions, feature ideas, and general requests should:

Be posted asynchronously
Be tracked as tasks if action is required
Not interrupt active engineering work

Interruptions should be limited to:

Production incidents
Active delivery blockers
Time-sensitive, business-critical issues

Repeated follow-up messages for the same request should be avoided unless the issue is actively blocking or has been marked as urgent.

6. Response Time Expectations¶

General guidance:

Communication Type	Expected Response
General question	When available
Task-related clarification	Same business day
Blocking issue (non-prod)	As soon as practical
Production incident	Immediate

This sets realistic expectations without creating pressure for instant replies.

7. Availability & Working Hours¶

Engineering communication should assume standard working hours unless an issue meets the defined urgency criteria.

Messages sent outside working hours are treated as asynchronous and will be reviewed on the next business day.

No response should be expected outside working hours unless:

There is a production outage
There is a revenue-blocking incident
There is a security issue

This ensures critical issues are still addressed promptly while reducing unnecessary after-hours load.

8. Use of Mentions (@)¶

Mentions should be used intentionally to reduce notification noise and protect focus time.

Scenario	Use @mention?
Production incident	Yes
Active blocker during delivery	Yes
General question	No
Feature request	No
Status follow-up	No

If a message does not require immediate attention, avoid using direct mentions.

What This Means in Practice¶

Not every message requires an immediate response
Not every request is urgent
Work should be tracked in shared systems
Communication should prioritise clarity and visibility

These practices help engineering deliver faster with higher quality and fewer disruptions.