Radical Transparency: Lessons From Open-Sourcing Nearly All Company Documenta...
summary
Company policy makes nearly all docs public—GitHub issues, Figma wireframes, ADRs, sprint demos and a public handbook—so customers can follow issues and onboarding is asynchronous, but that creates 40+ hours of recorded meetings and 90‑day Slack churn that drive overload and burnout. Video workflow is manual; a home‑built Chrome extension called openblur removes PII in demos. Confidential items live in a private repo and a vendor required one integration (Microsoft Entra ID) to stay closed. Scrum boards are public, which inflates visible backlog because maintainers prefer opening new issues over closing customer‑specific ones.
AI-written summary · about
chapters (15)
- 0:00Radical transparency intro
- 1:05Fleet’s open-source history
- 3:55Business benefits of transparency
- 6:07Internal trust and transparency
- 9:57Confidentiality versus openness
- 12:27Too much information risks
- 15:39Handbook-first approach
- 19:12Remote work handbook perks
- 21:45Public handbook lessons
- 23:32Open tech docs benefits
- 26:28Customer feedback trade-offs
- 28:58Public meeting recordings
- 32:27Public video challenges
- 35:16What stays confidential
- 36:42Conclusion and Q&A
related talks
39mOpen Docs, Open Collaboration: Building Better Documentation with Community PRs
58mBuilding Enterprise Software Today: A partnership in openness
27mFOSS behind the scenes - the center stage is not enough
24mBuilding a Foundation for Open Collaboration
56mEffective Documentation: The Key to Open Source Growth
51mBuilding Strong and Sustainable Open Source Projects
20mHumans of Open Source
44mBringing Open-Source Brilliance to Scrum Teams: A Guide to Enhanced Collaboration