Post the Wrong Answer: Why Your First Draft Should Be Imperfect

According to internet lore the quickest way to get an answer on a technical forum is to use a sockpuppet account to post the wrong answer to your own question. People rush to correct the mistake, when they would otherwise have ignored the original question.

I've been thinking about documented standards again, particularly why getting that first draft written is so difficult. We're paralysed by the need to write it perfectly. But like that sockpuppet posting the wrong answer, sometimes the quickest way to get a good standard is to put out an imperfect one.

The problem: standards that exist only in people's heads

Every organisation has standards. They just live in people's heads rather than on paper. This hidden knowledge tends to manifest in two ways, both of which create the same problem: nobody wants to be the first to write things down.

Magic Jeff

I work with a fella, let's pretend his name is Jeff, and I have nicknamed him Magic Jeff. This is because I am forever hearing about some critical process that can't proceed because Magic Jeff is busy so he can't do it. Whenever I ask if one of the many other engineers could do the thing I get told that only Magic Jeff can do it.

It's not that the other engineers are incapable. They're smart people. The problem is they either don't know how to do the process at all, or they don't know how to do it the way Magic Jeff does it. And Magic Jeff's way has become the de facto standard through years of repetition. Do it differently and you risk breaking something, or at least getting a raised eyebrow from Magic Jeff when he reviews your work. So everyone just waits for Magic Jeff.

In reality I suspect that Magic Jeff just wants to preserve his job by not writing things down and so maintaining his position as the only person who can do the critical process. That's a risky strategy because every management consultant I have ever spoken to will tell you to weed out those people first and reward those who document repeatable standardised processes.

Tribal knowledge

I'm not sure if we're allowed to call it tribal knowledge anymore, but the idea is the same. Everyone in the team just knows how things are done. They pass it down from older, wiser team members to the new recruits. This works fine until someone leaves the team, or the team gets too big for everyone to know everything. That's when knowledge drifts or you get islands of expertise in characters like Magic Jeff.

The problem here is the same: nobody wants to be the first to write it down. Everyone assumes someone else will do it, or that they'll get it wrong if they try.

The solution: post the wrong answer

Here's the thing: Magic Jeff's undocumented process and your team's tribal knowledge are your current standards. They're just not written down. And like that sockpuppet's deliberately wrong forum post, they're imperfect implementations that work well enough to persist.

The trick is recognising that when you write down "this is how Magic Jeff does it" or "this is what tribal knowledge says," you're not creating perfection - you're posting your wrong answer. And just like on that forum, people will rush to correct it. "That's not secure enough." "We should use this naming pattern instead." "This conflicts with the firewall team's approach."

But they'll only do that if there's something written down that they can react to.

A fresh team member might be the best person to get this started. They have to do the research anyway to get up to speed, and any mistakes in their understanding will be swiftly corrected by the wise old elves of the team. Even Magic Jeff will struggle to stay quiet when someone documents his process incorrectly.

Why the first draft is the hardest

I really love the IETF RFC standards process. It's what I modelled the infrastructure standards adoption process on at a retailer some time ago. Essentially it encourages that first draft to be written quickly, even if it's not perfect. The idea is that once the first draft is out there, people can start to comment and improve it.

The first draft is always the hardest because it's the one that requires the most effort. In a traditional approval flow a draft gets written, it goes to various stakeholders for review, they all nit pick it to death and it never gets finished. Conversely in the IETF process you can get a working group to agree to a rough draft which is posted as a working document. From there it can be refined and improved until it reaches a point where there are no more objections and it can be considered a standard.

Encouraging that first draft and getting it out there for a road test and critical review is the hardest part and any process that includes pre-publication review is going to struggle to get things done.

Just post the wrong answer

So next time you're stuck trying to write the perfect standard, remember the sockpuppet. Document what Magic Jeff actually does. Write down the tribal knowledge as it exists today, inconsistencies and all. Post your wrong answer.

The engineers who would never find time to help you write a standard from scratch will suddenly have plenty of opinions about why your draft is flawed. Let them. That's how imperfect-but-visible becomes refined-and-adopted. The alternative is perfect-but-imaginary, which helps nobody.