First-Bad-Version™

Unproductive meetings have been the bane of my existence as both a software developer and later as an architect and technology leader.

I’m not talking about those meetings that should never have happened in the first place — there are many of those too. I’m talking about meetings where you have a worthwhile topic and peers who care, but somehow all that is produced from a 1 hour meeting is a bunch of talk and “hand-waving” but no concrete agreement or next steps other than to schedule a followup meeting.

Worse, everyone might leave believing they arrived at consensus, but over the days and weeks afterwards you realize that the group’s alignment and expectations couldn't be further apart as arguments erupt and the group is forced back into the meeting room.

For years I saw this phenomenon over and over again and it drove me crazy.

There is a cure!

Don’t go deep down the rabbit-hole of endless debates where everyone tries to out-argue or bully each other into submission. Instead of letting apathy win or let frustration and disagreements cause everyone to give up on the conversation, just stop and ask “Can someone create a First-Bad-Version?” Better yet, offer to create one yourself!

A First-Bad-Version™ is exactly what it sounds like. It’s a rough-draft that is sure to be wrong, incomplete, subjective, and far from something everyone would agree upon. It is a starting point to provoke civil debate, negotiation, and generally allow you to start the process of iterating on the topic so that you can reach an actual agreement.

What?!?

Stop and create something that the group can point at and discuss. Pick a person in the meeting and assign him/her (possibly yourself) to write-down a a completely selfish version of the topic at hand. Do this as fast as possible without worrying about formatting text, perfecting the appearance, or verifying its accuracy.

Sometimes you can do it together as a group on a whiteboard or screen-share while everyone is watching. If that isn’t possible, then just end the meeting and assign it as an Action Item for one participant and reconvene later so everyone can save some precious time.

Depending upon the purpose of the meeting, the First-Bad-Version could take the form of something like the following: (not a comprehensive list)

  • A bulleted list of requirements — in choppy phrases
  • A 1-page version of a 20 page report
  • A 2-slide presentation with nothing but a Title, Bullets, and placeholders
  • A back-of-the-napkin wireframe or mockup of a UI (rectangles & text)
  • A simple 4-box diagram of Software or Service interactions

The key point is to spend a minimal amount of time, 5 to 15-minutes at most, on an imperfect representation of the topic of discussion. This is not about note-taking, its about painting a picture (maybe literally) of what was discussed but without trying to “solve it”. This way everyone can see how close or far away they are from each other in reality.

Okay, we did it. Now what?

Once the First-Bad-Version is created, review it together as a team and start the process of making it “right”. Since everyone agreed up front that this version will be bad, there should be no ego or personal attacks for it being wrong — everyone knew that it would be wrong. Now you can focus on reviewing, modifying and improving it with an iterative approach until you have an artifact that represents proof of consensus. Once you have that, your reason for meeting is fulfilled!

Normally you leave a meeting only with theoretical consensus but you don't know for sure if you actually agree until later — often too late. If you are a software developer, this is like writing code but never compiling. If you are a lawyer, it’s like writing a legal argument but never litigating it in court.

Not only does the First-Bad-Version give you proof that you agree, you also get work done! This artifact is likely a valuable part of your overall results and how you will communicate the decision to others not in the meeting.

Conclusion

People don’t belong in meetings, they belong at their desks getting work done. So, the bottom-line is that your goal for every meeting should be to end the meeting as soon as possible — and without the need for a followup. The best way to solve unproductive meetings is to not have meetings at all and instead have Working Sessions.

Working Sessions are small groups not huge committees. They focus on results rather than attendance, proof rather than theoretical consensus, and productive debate rather than the usual behavior of verbal-sparring, passive-aggressive comments, or apathetic attendees trying to avoid conflict.

So, if you ever feel like you are wasting your time in a meeting and wish you were elsewhere, give First-Bad-Version a try and use it as a tool to move-on to a Working Session or independent work as soon as possible.

Note: After a while you can go one step further and email everyone your First-Bad-Version before you meet. Best case is you eliminate the need for the meeting, but even if you dont, you will start the meeting closer to the finish-line.