This story has been updated and republished as Lessons Learned From My First Failed Meeting. That version is better. 🙂
It was a bad day at Geekaplex. A star developer’s computer had crashed hard, taking a week’s worth of new source code with it. The big boss was furious! How could it be that there was only one copy of the code? I spoke up, “We need source control, and a backup system.” The big boss looked at me and said: “OK, then get some people together and make it happen!”
I was fresh out of college and this was my first gig. I knew that I didn’t have the knowledge or clout to make this happen on my own, so I called a meeting. I sent out an invite to all of engineering: “Let’s get together and talk about source control and backup.”
Meeting day came and about half the engineering department showed up. I was a bit disappointed at the turnout; didn’t they know how important this was? After waiting a while to see if more people would come, I started. “I think everyone heard about what happened last week. I think we need a source control system, and a backup system too. Who wants to start the discussion?” Surly Jim snorted. Several people chimed in to agree that we needed source control and backup. A few were worried that using source control would slow them down or get in the way. Billy told a story about the time his previous company’s source control system crashed and only then did they discover that the backups were all corrupt. Ken said that to be elite, we needed to run Submarine-Version on Linus.
The meeting rambled on for quite a while, and I started to feel like it wasn’t getting anywhere. Laptops started opening. Spalding started coding. Kathy and Chris were obviously IMing, and a few people seemed to be reading email. Eventually, some people just got up and left. Those who stayed seemed to be getting more and more impatient, Surly Jim in particular. Finally, he burst out “Why are we all here? What’s the point of this meeting?” The room got very quiet, and then Socrates spoke up: “I think we have done all we can today. Let’s wrap things up for now.” Everyone, including me, was relieved. As people shuffled out, Socrates stayed behind.
Socrates wasn’t his real name, of course, but that’s what everyone called him. According to talk around the office, he had worked at PARC, Apple, and Atari back in the day. He had been a founding engineer at All Your Base, and as the company grew, he went from writing their first games to running the development group. He left shortly after the company was sold to EvilEmpireSoft.
“What do you think of your first big meeting?” he asked. “I feel like I just wasted everyone’s time.” I bemoaned. “It’s good that you see that. They’ll forgive you, once.” He paused, and then asked, “So, what will you do differently next time?” I said that I wouldn’t invite surly Jim, that’s for sure. “Actually, he may have helped you the most, as he raised a key question. What was the point, or more precisely, the goal of that meeting?” I thought about it for a minute, and then said that it was to talk about source control and backup. “Well then, you should be happy with the meeting. We talked about those things for some time.” Now it was my turn to snort. “Sure we did, but we didn’t get anywhere!”
Socrates then asked me where I had hoped to get. I replied that I had hoped that we would walk out knowing what source control and backup systems to adopt. “So, you wanted the goal of the meeting to be choosing source control and backup systems?” “Yes, I suppose that is what I was hoping for.” I replied. After a thoughtful pause, he said, “That’s actually a great goal for a meeting, much better than your original one.” That made sense. He went on, “Your first goal wasn’t a total stinker. It had one of the important qualities of a good meeting goal: at the end of the meeting you can easily determine if the goal was met. You simply ask the question: Did we meet the goal of talking about source control and backup systems. The question lends itself to a clear yes or no answer. Some goals are too vague or general to be even that useful. For example, what if your goal had been to improve software development practices here at Geekaplex? How meaningfully could you answer the question: did this meeting improve our software development practices? You really couldn’t tell if the practices improved until some time after the meeting.”
OK, so according to my original goal the meeting was technically a success. Still, it wasn’t a good meeting. According to my revised goal the meeting had failed. This wasn’t surprising, given that I hadn’t really known that it was my goal.
The meeting may have crashed and burned, but at least I was learning something from the experience. If I was to avoid wasting people’s time, I need to have a clear goal for any meeting that I call. The goal needs to be something that I can measure the success of the meeting against. At the end of the meeting, I want to be able to ask: “Did this meeting meet the stated goal?” For that matter, before calling a meeting I could ask myself “Will a meeting be able to meet this goal?” Had I asked myself this question at the outset, I probably wouldn’t have called this meeting, and wasted so many peoples’ time.