Google's testing on the toilet initiative, widely known as TOTT, started as a clever hack to solve an intractable engineering problem: how do you teach software testing practices to thousands of busy developers without pulling them away from their desks? Created by software engineer Jonathan Russell in 2006, the program placed single-page flyers on bathroom stall doors across Google offices. These sheets featured short testing tips, debugging puzzles, and code quality advice.
The strategy worked because it met engineers in a place free from distractions, email notifications, and urgent bug fixes. Instead of sitting through lengthy training seminars or skimming dense wiki documentation, developers absorbed bite-sized engineering wisdom during a quiet daily routine. Over two decades, TOTT evolved from a grassroots experiment into a legendary staple of Google's engineering culture, influencing how tech companies worldwide approach internal developer education and quality advocacy.
The Origin Story: Solving Developer Apathy
Back in the mid-2000s, Google faced a scaling crisis. As the engineering headcount expanded rapidly, maintaining consistent code quality and robust automated testing became difficult. Many developers viewed writing unit tests as tedious overhead rather than a core engineering responsibility. Traditional documentation existed, but engineers rarely read internal wikis unless forced by an immediate blocker.
Jonathan Russell wanted a way to reach people who wouldn't normally attend testing workshops or read style guides. He drafted a simple, one-page document explaining a specific testing concept, printed copies, and tacked them to the inside of bathroom stall doors at Google's Mountain View headquarters.
The medium worked because of captive attention. Without screens, phones, or code editors demanding focus, readers engaged deeply with the single technical puzzle or tip presented on the page. Engineers returned to their desks talking about the puzzles, debating test doubles, and questioning their own assertion styles. What began as a rogue single-office experiment quickly caught the attention of corporate leadership, who funded and formalized the distribution.
How the TOTT Program Scaled Globally
As Google opened engineering offices across the globe, scaling TOTT required moving past rogue printing jobs. The initiative matured into a structured, community-driven program managed by testing advocates known internally as Testing Congruence or Testing Champions groups.
A formal editorial workflow emerged to sustain the output:
- Topic Nomination: Any engineer could submit an idea or draft a tip based on real debugging struggles or new tooling releases.
- Peer Review: Experienced test engineers reviewed drafts for technical accuracy, clarity, and tone, ensuring the advice matched production best practices.
- Formatting Constraints: Every edition had to fit strictly on a single sheet of paper, forcing authors to keep explanations punchy and code snippets minimal.
- Translation and Localization: To support global offices, volunteers translated popular editions into multiple languages, ensuring engineers in Zurich, Tokyo, and New York received the same insights.
This decentralized authorship model prevented bottlenecks. Content stayed fresh because the writers were active developers wrestling with real codebase challenges every day.
Anatomy of a Classic TOTT Edition
The success of a TOTT flyer rested on its rigid structural discipline. Each edition followed a reliable framework designed to deliver maximum value in under three minutes:
- The Hook: A provocative question, a common anti-pattern, or a baffling bug report that instantly caught the reader's attention.
- The Core Concept: A concise explanation of a testing principle, such as mock object behavior, flaky test identification, or test isolation strategies.
- Before and After Code: A side-by-side comparison showing fragile, untestable code transformed into clean, highly testable architecture.
- The Call to Action: A practical step the reader could apply immediately when returning to their workstation.
For example, an early edition might address why global state breaks unit tests, showing a stark contrast between tightly coupled singleton usage and dependency injection. By keeping code snippets under ten lines, readers grasped the architectural lesson instantly without needing a compiler.
Cultural Impact and Lasting Legacy
The cultural footprint of TOTT extended far beyond clean test suites. It fostered an environment where talking about code quality, failures, and testing trade-offs was normalized and celebrated. It broke down silos between product developers and dedicated test engineers, establishing a shared vocabulary around test-driven development.
The initiative also proved that internal marketing matters. Technical excellence alone doesn't change organizational behavior; information must be packaged so it's frictionless to consume. By treating developers as an audience that values clever writing and practical utility, Google turned an administrative chore into a cultural badge of honor.
Other technology enterprises noticed. Organizations like Atlassian and various open-source communities later adopted physical or digital variations of TOTT, publishing internal micro-tips on Slack, intranet homepages, or physical bulletin boards.
Common Pitfalls When Replicating TOTT
Teams inspired by Google's success often attempt to launch their own version of testing on the toilet, only to watch engagement stall. Avoiding these common mistakes ensures better results:
- Making Content Too Long: If a tip requires scrolling or reading past a single page, people tune out. Brevity is non-negotiable.
- Using Academic Tone: TOTT succeeds because it sounds like a senior engineer chatting over coffee, not a textbook lecturing students. Keep the language conversational.
- Failing to Update Content: Stale tips destroy credibility. Rotate content weekly or bi-weekly to maintain reader curiosity.
- Forcing Mandatory Reading: The magic of TOTT is its voluntary, low-pressure nature. Turning it into a mandatory compliance check destroys the organic curiosity it relies on.
Frequently Asked Questions
Why was it specifically placed in restrooms?
Restrooms offer a unique physical environment where individuals have a brief pause without digital distractions, making them ideal spaces for micro-learning.
Did Google only cover unit testing?
No. While unit testing dominated early editions, later issues expanded into integration testing, performance profiling, flaky test triage, continuous integration pipelines, and code review best practices.
Can remote companies use the TOTT model?
Yes. Many distributed teams adapt the concept by posting weekly "Testing on the Intranet" snippets in dedicated Slack channels or internal newsletters, preserving the bite-sized format for remote workers.
Who wrote the content for each edition?
Any engineer at Google could volunteer to write an edition. A small editorial board reviewed submissions to ensure technical accuracy and readability before publication.
