Don't Embarrass Yourself

A few years back, during giving season at GoFundMe, we needed to cross-post top charities from Classy. It was the first technical collaboration between the two companies, and there was pressure for it to look impressive. The proposal on the table was a bidirectional integration. Months of work.

I asked: "Why don't we just give you a CSV file?"

The pushback came from the project managers, and I get it. This was the first time GoFundMe and Classy were working together, and they wanted something big and flashy to show for it. A CSV felt like too little work to prove the teams had done something great. That's a fair worry. Nobody wants the first thing they deliver to a new partner to look like an afterthought.

The question I ask before I ship anything is: will this embarrass me? And if so, how?

Run that on the CSV. Worst case, it's a bit boring and someone asks later why we didn't build the real thing. I could answer that. It solved the problem, it shipped on time, and it left room to build more later. A boring solution that works doesn't embarrass anyone. A flashy one that isn't ready in time does.

We shipped it that week. The deadline was met, and the relationship stayed strong for the deeper integrations that came later.

Here's what I've come to understand about "don't embarrass yourself." It sounds like a check that slows you down. It's really a premortem. Before I release something, I ask what could go wrong, how it would go wrong, and what the worst outcome looks like. Then I decide if I can live with that outcome.

Most of the time, I can. And once I've named the worst case and decided it's acceptable, there's nothing left to deliberate. I just do it. The question that sounds like caution is the thing that lets me ship faster, because I've already looked at the failure and shrugged.

The other direction is where it gets interesting. Sometimes the premortem tells me the embarrassing version is the ambitious one. "We spent months on an integration for a cross-post" is a sentence I'd hate to say out loud. Overbuilding is its own kind of corner cutting. You skip the step where you ask what the thing is actually for, and you hide that behind effort.

This is not perfectionism. I make mistakes constantly. The test isn't "is this perfect." It's "did I think about how this fails, and can I explain the choice." That's a low bar on purpose. A low bar you clear every time beats a high bar you skip when you're in a hurry.

If you want to try it, do this before your next merge, design doc, or "we should obviously do X" in a meeting. Write down the single worst thing that happens if you're wrong. One sentence. Then ask two things: can I live with that, and could I explain this choice to someone I respect in six months without wincing?

If both are yes, stop deliberating and ship. If the worst case is one you can't live with, now you know exactly what to fix, and it's usually smaller than the whole thing you were about to build. Either way, you're moving faster than you were a minute ago.