Way of Working

Source: Notion | Last edited: 2025-12-16 | ID: 2c62d2dc-3ef...

---

Overview

This document outlines our development process, designed to deliver high-quality, scalable solutions with consistency and agility. By combining disciplined development practices with a weekly work cadence, we stay aligned, adapt to challenges, and continuously improve, building a strong foundation for long-term success.

Guiding Principles

• Quality over Speed: We prioritize delivering reliable, well-tested solutions that are scalable and maintainable
• Teamwork: We collaborate openly, share knowledge, and align on goals to drive collective outcomes.
• Iterative Progress: We break down work into small, deliverable increments to maintain momentum and flexibility
• Continuous Growth: We regularly reflect on our methods, refine our processes, and embrace better ways of working
• Clarity: We keep our process, progress, and decisions visible to everyone involved to foster transparency

Workflow: Plan-Build-Ship

1. Plan (Scoping & Planning)

This phase is all about defining what we’ll build and how.

• PRD Creation: The product team drafts Product Requirements Documents (PRDs) to define the scope and requirements. All PRDs are stored in a central repository, and the team is kept informed of their status
• Epic Definition: The engineering team translates the final PRD into one or more epics in our task tracking tool. An epic represents a major piece of work tied to the PRD’s goals
• Task Breakdown: Once the epics are defined, we break them down into smaller, actionable tasks. Each task is given an ETA and added to the work backlog according to capacity and priority
• RFCs: For complex features or architectural changes, the engineering team may initiate a Request for Comments (RFC). This ensures a shared understanding and technical alignment before implementation

2. Build (Implementation & Delivery)

This is where we execute the plan.

• Development: Engineers write code, create unit and integration tests, and submit their work for code review.
• Trunk-Based Development: We work from a single main branch, integrating small, frequent changes. This minimizes merge conflicts and supports our CI/CD pipelines for fast, reliable releases.
• Code Review: Every code change goes through a structured review process. This catches issues early, enforces best practices, and promotes knowledge sharing across the team.

3. Ship (Testing & Deployment)

This phase focuses on ensuring a quality release

• Testing: We use both unit and integration testing to catch bugs early and ensure our system works as a cohesive whole.
• Feature Flags: We use feature flags to safely roll out or roll back new features without affecting the user experience.
• Continuous Delivery: Changes are integrated and deployed frequently to enable a seamless Continuous Integration/Continuous Delivery (CI/CD) pipeline

Project Rhythm

We follow a customized one-week (or two-week) Sprint to plan, deliver, and reflect on our work

Sprint Cadence

• Duration: 1 week (5 working days).
• Goal: Deliver a set of tested, usable increments while refining our process.

Key Meetings

1. Weekly SyncUp

• When: Start of each Sprint (Monday).
• Participants: Product and Engineering teams
• Duration: 1 hour
• Purpose: To review the previous sprint and plan the next sprint’s deliverables, as well as update the roadmap if needed

1. Daily Meeting

• When: 9 AM weekdays
• Participants: Engineering team
• Duration: 15-30 minutes
• Purpose: To sync up on progress, discuss work status, and identify any blockers

1. Sprint Retrospective (Optional)

• When: After the weekly review.
• Duration: 30-45 minutes.
• **Participants: **Engineering and Product teams
• Purpose: To reflect on what went well, what could be improved, and create action items for the next cycle.
• Example:
  • What went well? (e.g., smooth CI/CD, great code reviews)
  • What could be better? (e.g., testing delays, merge issues)
  • Action items: Pick 1-2 things to tweak (e.g., adjust review process, refine RFC timing).

Collaboration Guidelines

🔄 Sync Communication

Daily Meeting (Internal)

• Purpose: Ensure alignment, identify blockers, handle cross-team issues.
• Topics:
  • Overall team progress
  • Blockers needing TL/EM or cross-team support
  • Risks or dependencies

Weekly Sync (External)

• Purpose: Maintain transparency and alignment with client expectations.
• Agenda:
  • Demo or progress walkthrough
  • Highlight achieved work and next steps
  • Discuss blockers needing client input
  • Technical or product discussions

📬 Async Communication

Daily Report (Internal)

Each engineer posts a daily report.

• Format:
  • Work Completed: Summary of done items
  • Upcoming Work: What will be tackled next
  • Blockers: Issues needing support
• Purpose: Provide async visibility and help TL/EM remove obstacles

Daily Report Summary (External)

• Based on the Daily Report from each engineer, combine with the recap of the internal Daily Meeting, the team rotates members to post a summary to the client
• Includes:
  • Overall team progress
  • Key updates
  • Risks or blockers
• Purpose: Keep the client aligned

Dev–Test Mindset

To match the high‑velocity nature of startup projects and maintain engineering excellence, all engineers must adopt a Dev–Test mindset, regardless of whether a QA role is present.

Core Principles

• Quality is a shared responsibility, not owned solely by QA.
• Engineers must design, implement, and test features with end‑user impact in mind.
• No feature is considered “done” until it satisfies functional, technical, and quality requirements.
• Testing is integrated into development flow—not an afterthought.

Product Mindset

To thrive in startup environments, engineers must not only build features but also think like product owners—understanding the “why,” not just the “what.”

Core Principles

• Outcome over output: Focus on solving the user/customer problem, not just completing tasks.
• Ownership: Engineers take responsibility for the entire lifecycle — understanding requirements, challenging assumptions, validating impact, and ensuring quality.
• Empathy for users: Consider usability, performance, accessibility, and real-world behavior when designing and implementing features.
• Proactivity: Identify unclear requirements, missing cases, potential improvements, or risks early.
• Data-informed decisions: Use metrics, logs, and user feedback to guide technical and product decisions.

Additional Practices

• On-Call Process: We maintain a clear on-call process to ensure a quick and effective response to production issues. On-call Process