Use red teams to challenge orthodox thinking on your software dev. ...
summary
Claims that red teams cut the industry’s alarmingly high project failure rate by surfacing hidden assumptions and testing strategy against alternatives and real cases. Concrete tools include a diagnosis → creative → challenge workflow, liberating structures, and CIA‑style strategic analytical techniques plus workshops and diagnostics. Examples: Canary Wharf’s flawed market assumption that led to receivership and early internal Expleo pilots on RFPs. Success hinges on boss buy‑in, a diverse team (testers fit well), clear briefs, and iteration; early pilots show promise but are not yet widespread.
AI-written summary · about
chapters (18)
- 0:00Red teams in software dev
- 1:27Orthodox thinking fails
- 3:56Court jester analogy
- 6:05Decision-support red team
- 7:32Can’t mark our own homework
- 9:58Mavericks role and risks
- 11:02Canary Wharf flawed assumptions
- 12:47Red teams in IT projects
- 14:09Testers as red team members
- 16:19Cognitive biases in decisions
- 17:44Structured thinking tools
- 19:30Red team alternatives
- 20:12Q&A: Training vs separate teams
- 21:18Q&A: Single-person red team?
- 21:40Q&A: IT project examples
- 22:42Q&A: Setting assumptions
- 23:03Q&A: Governance patterns
- 24:28Q&A: Protecting Mavericks
related talks
33mBuilding Red Team Capability
44mChallenges, Facts, and Myths About Building Red Team Competencies in Organizations
39mColorful AppSec - Red, Blue, or Purple?
40mFantastic Red-Team Attacks and How to Find Them
49mTraining for Incident Response: The Red, the Blue, and the Ugly
32mHow to Train your Red Team (for Cloud Native)
35mBreaking Boundaries with Adversarial Testing
35mRed Teaming AWS: Practice What You Preach/