--- title: "The ‘I told you so’ board: taking the stigma out of being wrong" url: "https://toddpaulbrownjr.com/writing/the-i-told-you-so-board/" author: "Todd Paul Brown Jr." description: "Teams hide mistakes when being wrong is costly. A board that celebrates testing ideas made failure normal—and it's why I publish mine now." kind: "article" updated: "2026-09-26T02:50:43+00:00" --- # The ‘I told you so’ board: taking the stigma out of being wrong I was thinking about how to build a team culture where people test their ideas instead of just arguing over them, and I realized the problem wasn't the disagreements — it was what happened afterward. Being wrong cost too much. So you got careful, you hedged, you waited to see which way the wind was blowing before you committed to a position. The fix I came up with was simple: an "I told you so" board. When two people disagree, they design a test around it. Run the test. Post the result. Winner and loser both go up on the board, and it stays there. The rule that makes it work: I would start it the first time someone proved me wrong. I'd post that outcome publicly, with my name next to the loss, and then invite everyone else to join. ## Why it has to start with me losing If I roll out a board and the first entry is someone else being wrong, the board becomes a wall of shame with extra steps. Everyone sees it for what it is: a way to keep score on who screwed up. The board dies right there, or worse, it lives and people just stop disagreeing out loud. But if the first entry is me being wrong — and I'm the one who posted it — the frame changes. The board isn't about shame. It's about the test. It says: we had a disagreement, we ran a test, here's what we learned, and being on the losing side of that test is normal enough that the person running the team did it first. That's the point. Every result gets logged, wins and losses, so being wrong carries no stigma. ## What it actually does The board solves two problems at once. First, it takes disagreements out of the realm of authority and puts them into the realm of evidence. You don't win an argument because you've been here longer or because you're louder or because you're the one signing the paychecks. You win it by designing a test the other person agrees is fair, running it, and showing the result. Second, it makes being wrong a regular, visible, unremarkable event. When someone sees their name on the board next to a loss, they also see my name next to a loss, and a dozen other names next to wins and losses. The board doesn't say "this person failed." It says "this person had a hypothesis and tested it, and here's what happened." ## How it fits with the rest of the system The "I told you so" board is one piece of a larger way I think about building teams. Another piece: I recognize technicians specifically for their creativity when they generate a lot of hypotheses during data analysis. Most people don't associate creativity with that kind of work, and I want to change that. A board that celebrates testing hypotheses — win or lose — reinforces the same idea. Both of those tie into something else: I delegate technical troubleshooting not because I can't do it, but because it protects my time and spreads the knowledge. If I'm the only person who knows how to solve a problem, the system breaks when I'm not there. The board and the hypothesis recognition are both ways to build a culture where people test things themselves, learn from the results, and teach each other what they found. I've built that pattern into everything I've run. At one job, I set up a wiki maintained by department leaders so the knowledge didn't live only in my head. At another, I built a reporting system that got adopted company-wide because other people could actually use it. With Adroit, I've written the processes down so eventually other people could take over the day-to-day work. The "I told you so" board is the same idea applied to disagreements: take the thing that usually lives in someone's head or in a closed conversation, make it visible, and make it something everyone can participate in. ## Why I publish my failure reports I don't have an "I told you so" board running on a wall somewhere right now, but I do publish my failure reports. When something I built breaks, or when I try an approach that doesn't work, I write it up and put it on this site. That's the same principle: make being wrong normal by being wrong in public yourself. The reason it works is the same reason the board would work. When I write up a failure, I'm not writing "here's a mistake you should avoid" or "here's a lesson I learned." I'm writing "here's what I tried, here's what broke, here's what I think happened, and here's what I did about it." The failure is just another data point. It's useful the same way a win is useful: it tells you something about what works and what doesn't. If I only published the successes — the builds that shipped, the systems that went live, the test counts that proved the thing worked — I'd be training people to hide their failures. And that's the opposite of what I want. I want people to test things, to try approaches that might not work, and to share what they learned either way. Publishing failures does something else, too: it filters for the people I actually want to work with. If you read a failure report and your reaction is "this person doesn't know what they're doing," we're not a fit. If your reaction is "okay, so that approach has a problem at this layer, good to know," then we probably are. ## What I think it means for how I build now I don't lead a traditional team anymore — I build with AI agents, and I build systems that other people can run without me. But the principle is the same. The "I told you so" board was about taking the stigma out of being wrong so people would test their ideas instead of defending them. Publishing failure reports does the same thing in a different context. When I write up a build, I include the test count and the gate checks and the things that broke. When I describe how I work with Claude Code, I talk about the 157 prompts in the two weeks when three-quarters of the C++ was written, and I also talk about the fixes I had to make when the generated code didn't do what I thought it would. The receipts aren't just the wins. They're the whole record: what worked, what didn't, what I learned, and what I'd do differently next time. That's what the board was for. Not to keep score, but to make testing normal. To make failure just another result worth logging. To take the idea that you might be wrong and turn it from a threat into a tool.