Ways of Working — Tech Team

1. Purpose of this document

Document how the team works: our task flow, roles, rituals, how business and technology connect, and how we make decisions. We want everyone to have a high level of autonomy, access to tools/platforms and transparency in their work.

2. The team

3. Principles

1. Continuous pipeline. A queue of tasks. The top is prioritized in advance.
2. Async first. Meet only when it adds more than a written message would.
3. Focus and low WIP. Finishing beats starting. Fewer tasks in parallel = faster delivery and less context switching.
4. Transparency. Pipeline state is visible to everyone, business included.
5. Written decisions. What is decided becomes text — in Linear, here, or as ADRs in this repository.

---

4. The task pipeline (main flow)

4.1 Pipeline states ✅

4.2 Definition of Ready ✅

• Clear goal: what it is and why it matters.
• Acceptance criteria defined.
• Known dependencies with no open blockers.
• Reasonable size when possible. If too large, we either split the delivery or cap the number of iterations until its state is stable/safe and acceptable to ship.

4.3 Definition of Done ✅

• Acceptance criteria met.
• Tested internally (minimum agreed by the team).
• Code review approved.
• Desk check completed for customer-facing tasks.
• In production and working.
• Documentation/record updated when applicable.

4.4 WIP limit 💬

• Proposal: max. 2 "In progress" tasks per dev at a time.
• A task blocked and idle leaves "In progress" and is flagged.

4.5 Task lifecycle (SDLC) ✅

From entering "Ready to start" through to "Done", going through code review and desk check iterations. Changes requested in review — or problems in the desk check — send the task back to "In progress". The desk check only applies to customer-facing tasks (see §4.3). The merge only happens after the desk check is approved (or after review, when there is no desk check).

---

5. Rituals (tech team)

5.1 Stand up (Daily) ✅

• What: each person says what they did, what they will do and blockers.
• When: daily, 10:30 BRT.
• Who: everyone.
• Why: quick alignment; a flagged blocker gets resolved the same day.

5.2 Backlog pre-refinement ✅

• What: leadership prepares and pre-prioritizes demands before refinement with the team.
• When: weekly.
• Who: leadership (CTO/Head + CPO/COO when there is product demand).

5.3 Backlog refinement ✅

• What: review pre-refined demands, clarify, roughly estimate and mark "Ready to start".
• When: weekly, ~30 min.
• Who: everyone (devs + CTO/Head; CPO/COO when there is product demand).

5.4 Roadmap alignment ✅

• What: business and tech review priorities, trade-offs and progress; agree on the order of the top of the pipeline.
• When: quarterly.
• Who: everyone (CTO, Head, CPO/COO, co-founder).

5.5 Retrospective ✅

• What: the team reviews what went well, what to improve and defines concrete actions.
• When: monthly.
• Who: everyone.

---

6. Quality, decisions and incidents

6.1 Technical decisions ✅

• Relevant decisions (architecture, tool choice, standard) become a short decision record: context, options, decision, who decided, date.
• 💬 To decide: where they live (folder/Notion) and when they require consensus vs. an individual decision.

6.2 Quality standards ✅

• Minimum before merge: code review approved + agreed tests passing.
• 🔓 Define minimum test/coverage standards.

6.3 Production incidents ✅

• Who triggers: whoever detects it opens the alert in the incidents channel.
• Response: the Head coordinates; engages the dev responsible for the area.
• Communication: status to business (CPO/COO) as soon as there is a diagnosis.
• 🔓 Define: on-call rotation/owner outside business hours.

---

7. Tools 🔓

---

8. Ritual owners

Each ritual has an owner responsible for keeping it alive and useful. (To be filled in the meeting.)