Frameworks

Projects stall not because the right answer is unknown, but because nobody knows who decides. The RAPID framework eliminates this ambiguity. RAPID stands for: - Recommend: Who proposes the decision? - Agree: Who must agree (or escalate)? - Perform: Who executes the decision? - Input: Who provides data/expertise? - Decide: Who has final authority? For every critical decision, map these roles before the discussion starts.

Use RAPID for decisions that meet any of these criteria: - Cross-team impact (affects more than one team's work) - Budget implications (> $10K spend or resource reallocation) - Timeline changes (affects committed delivery dates) - Architecture choices (irreversible or expensive to change) - People decisions (team structure, vendor selection) For day-to-day decisions within a team, RAPID is overkill. Empower teams to decide locally.

Example: Choosing between building vs. buying a notification service - Recommend: Engineering Lead (evaluates technical tradeoffs) - Agree: Security team (must approve vendor data handling) - Perform: Backend team (implements the chosen approach) - Input: Product team (requirements), Finance (budget), Ops (maintenance) - Decide: Engineering VP (final authority on build/buy) Document the RAPID assignment in a shared doc before any meetings. This alone eliminates 50% of meeting time.

Level 1 — Chaotic: No predictable cadence. Commitments are guesses. Scope changes constantly. Level 2 — Reactive: Team delivers, but reactively. Fire-fighting is common. Estimates miss by 50%+. Level 3 — Structured: Consistent sprint cadence. Reasonable estimates. Some spillover (< 20%). Level 4 — Predictable: Team consistently hits sprint goals. Cycle time is tracked and improving. Stakeholders trust commitments. Level 5 — Optimizing: Continuous improvement is embedded. Team self-corrects. Delivery is a competitive advantage. Most teams operate at Level 2-3. The goal is to get to Level 4.

Rate your team on each dimension (1-5): 1. Sprint Goal Achievement Rate - How often does the team deliver the sprint goal? 2. Estimation Accuracy - How close are estimates to actuals over the last 5 sprints? 3. Defect Escape Rate - What % of stories result in production bugs within 2 weeks? 4. Cycle Time Trend - Is average cycle time stable or improving? 5. Team Autonomy - Can the team deliver without PM/management intervention? 6. Stakeholder Satisfaction - Do stakeholders trust the team's commitments? Average score = your Delivery Confidence Level.

Level 1 → 2: Establish consistent ceremonies. Define a basic Definition of Done. Start tracking velocity. Level 2 → 3: Introduce WIP limits. Invest in automated testing. Run retrospectives with follow-through. Level 3 → 4: Optimize sprint planning with capacity data. Track cycle time. Reduce batch sizes. Eliminate sprint spillover. Level 4 → 5: Implement continuous deployment. Empower team to make architectural decisions. Use lead time as primary metric. Each level transition typically takes 2-3 quarters of focused effort.

Rung 1 — Team Level - What: Blockers within team's control - Owner: Tech Lead or Scrum Master - Timeline: Resolve within 24 hours - Example: Code review bottleneck, unclear acceptance criteria Rung 2 — PM Level - What: Cross-team dependencies, resource conflicts - Owner: Project Manager - Timeline: Resolve within 48 hours - Example: API dependency on another team, shared resource contention Rung 3 — Director Level - What: Budget, timeline, or scope changes - Owner: Engineering Director / Program Manager - Timeline: Decision within 1 week - Example: Feature descoping, timeline extension request Rung 4 — Executive Level - What: Strategic pivots, major risk events - Owner: VP/C-suite - Timeline: Emergency meeting within 24 hours - Example: Security breach, major vendor failure, compliance issue

Every escalation should include: 1. SITUATION: One sentence describing the current state 2. IMPACT: Quantified impact on timeline, budget, or quality 3. OPTIONS: 2-3 options with tradeoffs 4. RECOMMENDATION: Your recommended option and why 5. ASK: What you need from the escalation target 6. DEADLINE: When you need a decision Example: 'The payments API integration is blocked by a vendor outage (2 days so far). This puts the March 15 launch at risk of a 1-week delay. Option A: Wait for vendor fix (free, but uncertain timeline). Option B: Build an interim solution (3 dev-days, reliable). I recommend Option B. I need your approval for the 3 dev-days by EOD Thursday.'

Avoid these common mistakes: - Escalating without data: 'This feels risky' vs. 'This has a 70% probability of delaying launch by 2 weeks based on...' - Skipping rungs: Going to the VP when the Director hasn't been informed creates organizational friction - Escalating emotions, not facts: Keep it professional and solution-oriented - Escalating too late: If you're escalating the day before the deadline, you've waited too long - Not following up: An escalation without a resolution date is just a complaint Golden rule: Escalate at the point where the cost of delay exceeds the cost of disruption.