The Value of Being Wrong First

One of the most reliable ways I've found to make progress on a hard decision is to put something wrong in front of people.

I know, it sounds backwards. If a group needs to decide how a system should be designed, how a team should be organized, or even what the organization should work on next, the natural instinct is to start with the problem, get the right people together, and try to invent the right answer as a group. Everyone brings their experience and perspective, you talk through the possibilities, and eventually the answer should emerge.

Sometimes it does. More often than I'd like, everyone spends a lot of time circling the problem. The conversation can be thoughtful and intelligent while still producing surprisingly little progress. Everyone is constructing their own version of the problem and the possible solutions in their head, and then trying to communicate fragments of those models to everyone else. Much faster: put up a first version of the outcome.

Draw the architecture. Write the proposed team structure. Sketch the API. Put together the roadmap. Write down the strategy. Make the decision, at least provisionally, and show everyone what it would look like if that were the answer. The important part is that the first version doesn't need to be right. In fact, you should probably assume that it isn't (you probably don't want to go as far as to try to be wrong but... if you have any "we definitely can't do X" then throwing in "do X" as part of your first version will absolutely validate whether you can do X...)

There is an old pattern from Stack Overflow and other engineering forums that captures this: Ask a broad question about how to solve a problem and you might get a handful of responses, if you're lucky. However... post the implementation you've come up with and suddenly people are extremely motivated to explain everything that's wrong with it. They'll point out the edge case you missed, the library you should have used, the assumption that won't hold, the simpler approach you somehow overlooked, and the problem you're going to create for yourself six months from now.

There is something fundamental about how people think hiding in that behavior. Generating a solution from an empty space is expensive. Evaluating something that already exists is much easier. We are remarkably good at looking at something concrete and saying, "That part doesn't work," or "You've forgotten this," or "I agree with the premise, but I would solve it completely differently." That difference matters even more when you're working with a group.

If you start with a blank page and ask five people what the answer should be, you're effectively asking all five of them to independently work their way through the entire problem before they can contribute. They need to decide which parts matter, establish their assumptions, think through the obvious options, discard the bad ones, and eventually get themselves to the interesting part of the problem.

A straw man can shortcut a lot of that work, by giving everyone the same initial coordinate system: Here is one interpretation of the problem. Here are some assumptions. Here is what those assumptions lead to. Here is what the outcome might look like.

Now tell me what's wrong with it.

The conversation changes almost immediately. Someone knows that one of the assumptions isn't true. Someone else sees a constraint that hasn't been represented. Another person agrees with most of it but sees a much simpler way to get there. Someone asks the question that causes everyone to realize they're solving the wrong problem entirely. That's the part of the conversation you wanted to get to in the first place.

The real value of putting up a first version isn't that you've saved everyone the work of coming up with an answer. It's that you've moved the group more quickly through the relatively obvious thinking and toward the higher-order question: what are we not thinking of?

I've seen this work at very different levels of an engineering organization. It works when you're deciding how to implement a technical system, where an architecture diagram gives engineers something concrete to attack. It works when you're thinking about organizational design, where drawing the proposed teams and responsibilities immediately exposes unclear ownership and awkward boundaries. It works at the strategic level, where writing down "here is what I think we should do and why" tends to produce a much richer conversation than asking a room what everyone thinks the strategy should be.

The artifact doesn't even need to be particularly sophisticated. Sometimes a diagram is enough. Sometimes it's a few paragraphs. Sometimes it's a spreadsheet or a rough prototype. The point is to make the thinking tangible enough that everyone can interact with the same thing. There is, however, a cultural requirement for this to work.

You have to be willing to be wrong first.

If you put up the straw man and then spend the meeting defending it, you've changed the exercise completely. People quickly learn that they're being asked to approve your answer rather than improve it. Feedback becomes more cautious, positions harden, and suddenly the thing that was supposed to accelerate learning becomes an argument about whose idea wins. Don't fold at the first challenge (higher quality discussion comes from a debate than a punch-list, after all), but be willing to throw away anything you need to when your assumptions prove wrong.

The person who puts forward the first version has to be genuinely comfortable watching it get dismantled. The final answer might retain 80 percent of the original idea. It might retain 10 percent. The discussion might uncover something that sends the group in a completely different direction, but the key is realizing that all of those are successful outcomes.

The measure of success for the first version isn't how much of it survives. It's how much faster it gets the group to a better answer.

I think this is especially important in engineering cultures, because we're trained to care deeply about correctness. Putting our name on something we know is incomplete can feel uncomfortable. There's a temptation to keep working privately until the thinking is defensible, the edge cases have been considered, and the proposal is polished enough to withstand criticism. But sometimes that instinct works against us. The additional hours spent making the first proposal more correct may be much less valuable than putting the rough version in front of four people who each know something you don't.

There are obviously decisions where substantial analysis needs to happen before proposing a direction. The cost of being wrong varies enormously, and rigor should scale accordingly. But even in those situations, there is value in externalizing the current thinking early. A straw man isn't necessarily a commitment to action. It's a tool for discovering where the thinking is incomplete. Being wrong first isn't about lowering the bar for decision making. It's about getting more useful information into the decision sooner.

Start somewhere. Make the assumptions visible. Give people something concrete to disagree with then let them tear it apart.