Requested by: @ricksu978 via YakShaver.ai 🦬
cc: @jakebayliss, @PennyWalker, @ricksu978, @calumjs, @tiagov8, @adamcogan
Hi Team!
🟥 Watch the video (1 min 58 sec)
Pain
Add new content to Rules (Content) explaining how to protect client projects from single-developer risk ("bus factor"). This should include guidance on maintaining shared knowledge through practices like pair programming and minimum secondary-developer involvement, even when clients request cost reductions. The content should also include a drafted client-facing email that explains the rationale in clear, non-technical terms.
Acceptance Criteria
- A new SSW Rule is added addressing single-developer risk (bus factor).
- The content explains why projects should not rely on a single developer and references scenarios such as holidays or unexpected unavailability.
- Guidance includes a concrete example (e.g., 1 day of secondary developer involvement for every 5 days of primary developer work).
- The benefits of practices like pair programming and shared ownership are clearly described.
- A reusable client-facing email template is included that explains this approach and its value.
- The draft email is reviewed and approved by Jake and Rick (and optionally Callum).
- Content tone is suitable for both internal guidance and external client communication.
Requested by: @ricksu978 via YakShaver.ai 🦬
cc: @jakebayliss, @PennyWalker, @ricksu978, @calumjs, @tiagov8, @adamcogan
Hi Team!
🟥 Watch the video (1 min 58 sec)
Pain
Add new content to Rules (Content) explaining how to protect client projects from single-developer risk ("bus factor"). This should include guidance on maintaining shared knowledge through practices like pair programming and minimum secondary-developer involvement, even when clients request cost reductions. The content should also include a drafted client-facing email that explains the rationale in clear, non-technical terms.
Acceptance Criteria