Skip to content

Operations

Day-to-day procedures: how we handle leave, handovers, issue tracking, and internal documentation.

Blame-Free Postmortem

When something goes wrong, the goal is to understand the system — not to find someone to blame.

Reporting a mistake — even a big one — will never be held against you. What matters is that it surfaces early. If people fear punishment, problems get hidden, minimized, or reported late. That makes everything worse.

The question is never "who did this?" — it's "how did our system allow this to happen?"

A postmortem is written after every customer-impacting incident. It is a learning tool, not a punishment.

Language is impersonal. Write "the migration was skipped during deploy" — not "X skipped the migration." The person is never the root cause; the system is.

Every postmortem follows this template:

Section What to write
Summary One paragraph. What happened and what was the impact.
Impact How many tenants affected, for how long.
Timeline Chronological events — detection, response, resolution.
Root Cause The underlying system failure, not the surface symptom.
What went well Things that limited the damage or helped recovery.
What went badly Things that made it worse or delayed the response.
Actions Concrete next steps, each with an owner and a due date.

Root cause: use 5 Whys. Don't stop at the first technical answer. Ask "why" five times until you reach the systemic or process failure underneath.

Postmortems are public — posted in Linear or the wiki, visible to the whole team. They are not stored away. An action without an owner and a deadline does not count. Actions are tracked like normal work and followed up until closed.

Incident reports go on iDoc. Every customer-impacting incident gets a postmortem and a published incident report on iDoc under the relevant section. A postmortem in a Slack thread or in someone's head is not a postmortem.

Over time this builds a searchable record: what broke, why, and what changed as a result. When the same class of problem resurfaces — and it will — the record is there.

Security exception

If the incident involves a security breach, sensitive technical details may be restricted to a small group. The lessons learned are still shared with the full team.

The distinction that matters

Blame-free postmortems apply to mistakes and incidents — things that happened unintentionally. Deliberately concealing a known problem is a different thing entirely and remains a red line.

Incident Response / On-Call

Production incidents require a different reflex from normal work: speed, clear role separation, and controlled customer communication. In our multi-tenant and self-hosted setup, a single incident can affect many customers at once.

Priorities during an incident — in order:

  1. Mitigate — stop the bleeding. Customers don't wait while you debug.
  2. Communicate — notify the right people, including customers per the SLA.
  3. Root cause — investigate after the situation is stabilized.

Severity levels:

Level Definition Response
S1 Full outage or multiple tenants impacted Immediate, all hands
S2 Partial impact, degraded service Within 30 minutes
S3 Minor impact, workaround exists Within 2 hours

Roles during an incident:

Every incident has a single Incident Commander. The commander owns communication and coordination — they do not do technical work during the incident. Engineers handle the technical response. Roles do not mix.

  • Commander opens the incident channel, keeps it updated, and decides when to escalate.
  • Commander owns customer communication: what to say, when, and in what tone.
  • Engineers report status to the commander, not directly to customers.

On-call rotation:

On-call is distributed fairly across the team. After an on-call shift that involved a significant incident, rest or compensation time is documented and honored.

If you're overwhelmed

Escalate immediately. There is no expectation that you carry it alone.

Emergency Leave

If you have an emergency and can't make it to work:

  1. Notify your direct manager as soon as possible — a message is enough to start.
  2. Submit a formal leave request the same business day, or the next morning if the emergency happens after hours.
  3. If you're mid-task on something critical, drop a quick note in the relevant channel so the team isn't blocked.
  4. If possible, post in #leave-notification so the team knows you're out.

No need to over-explain. Just keep your manager in the loop.

Job Handover

When someone is leaving or transitioning roles, a proper handover is required. The timeline is set by your manager based on role complexity.

A complete handover includes:

  • All active tasks documented and reassigned
  • Relevant credentials and access transferred securely through proper channels
  • A walkthrough session with the incoming person (where applicable)
  • Key context written down — not kept in your head
  • RACI matrix updated to reflect ownership and accountability changes

The outgoing person owns the handover. The manager ensures it's complete before the last day.

There is no "I'll send docs later." The handover is done before you leave.

Issue Tracking

We use Linear. Every issue must be logged — not kept in Slack threads or someone's memory.

When opening an issue:

Field What to do
Title Be specific. "Bug" is not a title.
Priority Set it honestly. Not everything is urgent.
Description Context, steps to reproduce, expected vs. actual behavior.
Assignee Assign if you know who owns it. Otherwise, leave for triage.

Priority levels:

Level Meaning
Urgent Blocking someone right now
High Must be resolved this sprint
Medium Important but not on fire
Low Nice to have

If you find something broken and there's no issue for it — open one. Don't assume someone else will.

Engineering Discipline

Writing code is one part of the job. A task is done when:

  • Status is updated. Your Linear ticket reflects where you actually are. "Done" means done and verified — not "I pushed the branch."
  • Story points are set. Every ticket has an estimate before work starts.
  • TDD is written. If the work warrants a technical design document, it should be ready approximately one sprint before implementation begins. Writing a TDD months in advance is not expected — analysis done too early can become stale before the work even starts.
  • Ticket exists. If the work isn't in Linear, it doesn't exist for the team.

A merged PR with no ticket update is not done. Update the ticket.

AI-Generated Output

AI is a tool in our way of working, but the output it produces is yours. The responsibility for anything you generate with an AI tool rests entirely with you, the person who shipped it.

Nothing leaves your hands without a human review first. This applies to every kind of output, not just code:

  • Documents and specs
  • Messages (to customers, to the team, anywhere)
  • Code and configuration
  • Anything else produced with AI assistance

You can't blame the tool. If you share it, you own it - its accuracy, its tone, and its consequences. Read it, verify it, and make it yours before it goes out.

If a task takes less than 30 minutes, handle it in the next available slot — don't queue it behind long-running work.

Small tasks accumulate. A 10-minute fix that waits three days becomes a blocker and a frustration for someone else.

If you're in a focused block on something critical, log it in Linear and return to it immediately after.

Time Tracking

We use Clockify for personal time tracking.

This is for you — not oversight. The goal: after a month, you should be able to answer — "I spent X hours on feature work, Y on support, Z on meetings." If you can't, you have no visibility into your own work.

  • Log as you go, not in a weekly bulk session.
  • Review your own data monthly.

Mandatory Internal Documents

RACI Matrix

Every project must have a RACI matrix before work starts. No exceptions.

A RACI defines:

Letter Role Meaning
R Responsible Does the work
A Accountable Owns the outcome — the one who answers if it goes wrong
C Consulted Provides input before decisions
I Informed Kept in the loop after decisions

Rules: - There can only be one A per task. Shared accountability is no accountability. - If roles shift mid-project, update the RACI immediately. - If a project doesn't have a RACI, stop and create one.

The RACI is a living document, not a one-time checkbox.

Password Management

All Appcircle-related credentials — passwords, API keys, certificates, SSH keys, and any other secrets — must be stored in the company password manager.

Storing or sharing work credentials anywhere else (Slack, email, notes apps, local files, spreadsheets) is not allowed.

This applies to every team member, without exception. If a credential exists and is not in the password manager, move it there.

Setup instructions: Password Manager