Skip to main content

Tiki-Taka Playbook ⚽️✨

A high-skill, async-first, low-overhead delivery style inspired by tiki-taka football.

1) What “Tiki-Taka” Means​

Tiki-Taka Development is how we ship high-quality product increments through:

  • Short passes (small tasks + small PRs)
  • Constant movement (daily progress, minimal waiting)
  • On-need collaboration (activate talent briefly, then release)
  • Relay handoffs (clean continuity, no training overhead)
  • Assumption-light iteration (validate early, adapt fast)

Goal: Ship functional + polished outcomes with maximum efficiency and minimum waste.

2) Core Principles (The Rules of Play)​

  1. Short passes > long throws
  2. Async by default (work must move without meetings)
  3. Activate talent only when needed
  4. Relay handoffs, not hard handoffs
  5. Small PRs, fast reviews, frequent shipping
  6. Validate assumptions early
  7. Quality is part of speed
  8. Keep ownership clear (one driver at a time)

3) Talent Pool Model ⭐️​

We operate as a pool of mid-to-senior multitalented players:

  • Each person owns their main lane (design/dev/PM/QA/ops)
  • Each person can cover adjacent lanes when needed
  • Collaboration is tactical + timeboxed
  • After contribution, talent is released back to their star projects

Tiki-Taka only works with high-skill players:

  • Strong fundamentals (“first touch”)
  • Good intuition (“dribble”)
  • Async working discipline

4) Collaboration Style (On-Need Activation)​

When a project needs support, we “pass” the work briefly:

Examples

  • Need UX clarity? Pull design for 30–90 mins → get flows → release.
  • Need architecture decision? Pull senior dev for 15 mins → decide → release.
  • Need scope alignment? Pull PM for 20 mins → lock goal → release.

No long staffing. No permanent dependency chains.

5) Relay Handoff Standard 🏃‍♂️🏃‍♀️ (No Training Required)​

Handoffs must be lightweight and instantly actionable.

Relay Handoff Template​

Current State

  • What exists now:
  • Links (PR / issue / Figma / docs):

Next Pass

  • What to do next (1–3 bullets):
  • Expected output:

Definition of Done

  • Acceptance criteria:

Risks / Gotchas

  • Known pitfalls:
  • What not to break:

Owner + Timebox

  • Driver:
  • Timebox (e.g. 2–6 hrs / 1 day / 2 days):

6) Sprint / Iteration Rhythm (Minimal Ceremony)​

We use Agile principles, but keep it light.

  • 1–2 week sprint
  • Daily async update
  • Demo at end
  • Retro: 1 improvement only

Daily Async Update (Copy/Paste)​

Yesterday

  • …

Today

  • …

Blocked

  • …

Next Pass Needed

  • (Who/what I need, timeboxed)

7) Work Slicing (Keep It Playable)​

Work must be cut into demo-able increments.

✅ Good slices:

  • “Create login page + validate inputs + wire API”
  • “Add delivery status timeline UI + dummy data”
  • “Add webhook handler + store events + basic retry”

❌ Bad slices:

  • “Build authentication system”
  • “Finish backend”
  • “Do UI”

Rule: if it can’t be demo’d, it’s too big.

8) PR Standards (Fast + Clean)​

PR size target: small enough to review in 5–15 mins.

PR Checklist​

  • Clear title + description
  • Linked issue / goal
  • Screenshots for UI changes
  • No unnecessary refactors bundled in
  • Tests updated (where critical)
  • Logs/telemetry considered (where needed)

PR Description Template​

What

  • …

Why

  • …

How to test

  • …

Notes / risks

  • …

9) Decision Rules (Keep Momentum)​

  • Prefer small decisions fast over perfect decisions late
  • Write decisions down (avoid “lost in chat”)
  • If stuck >30 mins → ask for a quick pass (short unblock)

10) Tiki-Taka Scoreboard 🏆​

We measure success by:

  • Lead time to ship
  • Review turnaround speed
  • Quality + stability
  • Clarity of ownership
  • Minimal meeting load
  • User feedback loop speed

We win when the Product ships fast and feels premium.