I want to help teams move faster together; not through more process, but through shared clarity, trust, and communication.

The goal: reduce friction without adding bureaucracy.
Clear communication is a speed advantage.

The 4-Step Collaboration System

Listen → Align → Adjust → Agree

Use this staircase as the weekly rhythm when joining or reshaping a team.

Why This Matters

Fast-moving teams don’t struggle because of a lack of talent – they struggle because of misalignment.

This playbook reduces friction between Design, Product, and Engineering by making:

• Expectations visible

• Decision-making shared

• Handoffs predictable

• Feedback continuous (not reactive)

It’s intentionally simple – no heavy ceremonies.

Week 1: Listening & Learning

Short 1:1 conversations reveal where collaboration breaks today – expectations, timing, formats, decision-making.

For Developers (ICs)

• What slows you down the most when you get designs?

• How do you prefer to receive designs: prototype, tickets, screenshots, walkthrough?

• What’s your current process when designs don’t match technical constraints?

• How do you prefer to give feedback on feasibility?

• If you could change one thing about design–dev collaboration, what would it be?

For Dev Manager / Lead

• What do you need from design so your team feels confident going into a sprint?

• When things break down, what usually went wrong earlier?

• How should disagreements be handled?

• What has worked well in the past?

For Product Managers

• Where does friction happen today?

• How can we reduce rework during execution?

• How should we document design–dev decisions?

For Everyone

• What tools are non-negotiable?

• How should we make decisions during urgent pivots?

Output after Week 1:
Top 3 collaboration pain points + protocol for urgent decision-making.

Week 2: Quick Wins

A. Weekly Design–Dev Sync (15–20 min)

Before sprint planning → walk upcoming designs → devs flag risks → avoid mid-sprint surprises.

B. Enhanced Handoff Checklist

Every design handoff includes:

• Prototype link

• Final flow (start → end + alternatives)

• Edge cases (empty, error, loading)

• Responsive behavior (if relevant)

• Specs/redlines (if precision matters)

• Assets + interaction notes

• Technical constraints noted

• Priority level: MVP vs. Polish vs. Delight

• Definition of done

Optional: short Loom walkthrough (<5 min)

C. Resource Reality Framework

• MVP: Must work; polish deferred

• Polish: Customer/demo-ready

• Delight: Added when time allows

Output after Week 2:
Clearer handoffs + shared expectations + fewer blockers.

Week 3: Feedback & Adjustments

Ask the team:

• What worked better this sprint?

• What’s still frustrating?

• If we fix one thing next sprint, what should it be?

• How did MVP/Polish/Delight work in practice?

Output after Week 3:
Refined systems shaped by the team, not imposed.

Week 4: Shared Working Agreement

A lightweight agreement everyone contributes to:

• Designs shared X days before sprint planning

• Devs review and raise blockers within 24 hours

• Post-sprint-start changes require alignment (PM + Dev Lead + Design)

• If unclear, ask directly  – don’t guess

• Weekly sync to prevent surprises

• Monthly technical design review

• Escalation path for decision deadlocks

Output after Week 4:
Clear rules → fewer misunderstandings → faster delivery.

Startup Realities

Crisis Mode Protocol

• Design triage: Drop polish first

• 24-hour decision window: PM + Dev Lead + Design can override

• Scope Parking Lot: Document cuts → revisit after launch

Iteration Expectations

• Version 1 → learning

• Version 2 → clarity

• Version 3 → refinement

Special Considerations

• Investor/demo features require clarity on “how good is good”

• Prepare for scaling as headcount grows

• Engineers can suggest UX improvements during build – partnership, not a function silo