Engineering Operating Model

Purpose

This playbook defines how Calibrax engineering projects should operate. The goal is to keep client delivery organized without adding heavy project-management overhead.

Core Principles

• Notion is the internal execution source of truth.
• GitHub is the implementation source of truth.
• Slack is for communication, not task ownership.
• Any role can create work items if the task meets the Definition of Ready.
• The Project Technical DRI (Directly Responsible Individual) is not a task-creation gate.
• High-risk releases require Project Technical DRI review before production deployment.
• The system should capture only the information needed to make good decisions.

Standard Project Roles

Responsibility	Default owner	Notes
Client context and feedback	Deployment Strategist	Captures feedback in Notion and keeps client-facing context clear.
Scope and acceptance	AI-PM, if assigned	If no AI-PM is assigned, this is shared by the Strategist and technical owner of the work.
Technical direction	Project Technical DRI	Role can be filled by the Lead Engineer or a senior engineer.
Implementation	Engineer	Owns implementation details, PRs, tests, and handoff notes.
Release approval for high-risk changes	Project Technical DRI	Required for production, data, auth, infra, or AI-behavior risk.
Client communication during release or incident	Deployment Strategist	Keeps client updates clear and separate from technical debugging.

Project Technical DRI

Use Project Technical DRI to mean Project Technical Directly Responsible Individual. Use this role name instead of Lead Engineer in playbooks.

This avoids tying the process to a single job title. A Project Technical DRI can be:

• The company Lead Engineer.
• A senior engineer assigned to the project.
• Another engineer explicitly delegated as technical owner for a narrow scope.

The role exists to make technical ownership clear. It should not become a bottleneck for every task.

Minimum Project Operating System

Every project should start from a standard Notion template with four core areas:

1. Project Dashboard
2. Work Board
3. Feedback Inbox
4. Release Log

Start here: duplicate the Notion project template - it comes preconfigured with all four areas.

This is intentionally small. Do not create separate databases for every concept unless the project has grown enough to need them.

Status Flow

Use this simple workflow:

Backlog -> Ready -> In Progress -> Review -> Done

Avoid extra statuses in the first version. If client validation is needed, track it as a field or note on the task or release, not another board stage.

Working Agreement

• Strategists can use Notion AI or templates to turn client feedback into task drafts.
• Engineers can create or refine their own technical tasks.
• AI-PMs can create and prioritize tasks when assigned.
• Work can start when the task meets the Definition of Ready.
• The Project Technical DRI reviews high-risk release decisions, not every task.

Definition of Ready

A task is ready when it has:

• Clear outcome.
• Priority: P0, P1, P2, or Later.
• Owner.
• Acceptance criteria, usually 1-3 bullets.
• Enough context or links for an engineer to start.
• Release risk: Low, Medium, or High.

Release Risk Levels

Risk	Meaning	Required review
Low	Internal-only, no production behavior change, no client-visible impact.	Engineer’s judgment.
Medium	Client-visible behavior change with limited blast radius.	Engineer’s judgment, notify Project Technical DRI if uncertain.
High	Production, data, auth, infra, billing, external integration, or AI output quality risk.	Project Technical DRI review before release.

What Not To Do

• Do not run projects only from Slack.
• Do not require a Project Technical DRI to approve every task before implementation.
• Do not create heavy Notion workflows that require constant manual updates.
• Do not let raw client feedback become engineering work without classification.
• Do not ship high-risk changes without a release owner and rollback path.