What kills me is the teams who get into the bad habit of holding meetings every time they need to figure out how something is going to work. Did you ever try to write poetry in a committee meeting? It’s like a bunch of fat construction guys trying to write an opera while sitting on the couch watching Baywatch. The more fat construction guys you add to the couch, the less likely you are to get opera out of it.
I love meetings.
That’s a pretty heretical statement. I suspect most diehard bureaucrats just tolerate meetings, and Joel—whom I might emphasize has more than a passing relationship with Team Copilot—has spoken rather strongly against them in the past. Hell, I grew up hating meetings, and I’d be lying if I said that part of why I loved the idea of working at Fog Creek wasn’t that the company has traditionally had a strong anti-meeting culture.
That’s not to say Fog Creek doesn’t ever have meetings. We do. It’s just that, when we do have meetings, they’re usually rather targeted in scope—to the point that, for the first two years I was at Fog Creek, basically every meeting I attended was either a product demo, a discussion of Fog Creek’s finances, or an argument over what features were going to go into the next version of a Fog Creek product. The logic behind focused meetings is that they cannot drag on indefinitely. You’ve come for a specific purpose; when you have achieved it, the meeting is over. The ability to simply spin wheels and waste time has been cut to near zero.
Yet I got out of a meeting ten minutes ago that, although I didn’t call, I would have if Tyler did not. The agenda for the meeting was that we hadn’t gotten the team together today. The meeting was over when everyone had said everything they felt like talking about.
We have meetings like those daily. And it’s that kind of meeting that I’ve come to love.
“What the hey?” I hear you ask. “Those are exactly the kind of meetings that suck team productivity, lead nowhere, and derail your project. Are you having a dry martini that’s clouding your judgment?”
Well, yes, but that’s immaterial. I used to agree with you. What changed my opinion was Copilot OneClick.
Copilot, like the rest of Fog Creek, used to shun meetings held just for the sake of having a meeting. Historically, that had served us well. Tyler and I generally work on individual Copilot components by ourselves. For example, I managed the Copilot Reflector by myself for almost all of Copilot’s life until this past summer, and have managed the end-user clients by myself for more than a year. Tyler managed all of the website, internal tools, encryption layer, and direct connection daemon. There wasn’t a pressing need to communicate much—most of what we did we could do without consulting the other, and where we did have to talk, most of these issues could be managed trivially through a couple of email exchanges.
Things changed when we were doing Copilot OneClick. Leading up to Copilot OneClick, Tyler and I had decided that we needed to add auto-update functionality to Copilot. We had found that many of our customers would download a Copilot helper application, then leave it around indefinitely while continuing to use it. We initially hadn’t anticipated this usage of Copilot. Copilot was, after all, originally designed as an ad hoc remote assistance solution. You don’t keep around ad hoc libraries. Yet here we had customers keeping Copilot executables around and reusing them time and time again.
In the long run, that was a large chunk of what made us realize that Copilot OneClick would be a valuable product, but at the time, Tyler and I were faced with the more immediate concern that Copilot could not technologically handle this scenario. We had counted on the ability to upgrade clients at will. Having legacy clients in the field meant that we had to maintain backwards compatibility in a protocol and application stack that we had never built to do so.
So, we decided to introduce automatic updates. When you downloaded Copilot, you’d be downloading the current version, plus a stub that was smart enough to download a newer version if one were available. I calmly forecast, based on exactly the schedule technique that Joel advocates, and which had traditionally served us well, that I could have that done in a month or two.
That was in April 2008. Those of you who are loyal Copilot users probably know that you didn’t get that functionality until July. What happened?
Miscommunication. Or rather, not miscommunication, but an absence of communication. When you don’t talk to others, it’s easy to find yourself in a bubble where, despite your best intentions, you will misprioritize your agenda.
That’s exactly where I found myself six and a half weeks after promising to get automatic updates out the door in four. I had been determined at the outset to learn from the lessons of Copilot, and part of that meant that downloads should happen asynchronously. Not in their own thread, but rather using the existing asynchronous callbacks provided in the Windows WinInet library—the same library used by Internet Explorer. But it turns out that Microsoft’s documentation for asynchronous downloads with WinInet…well, it sucks, and I ended up spending many days trying to determine why programs that looked correct to me failed, reading over WINE source code, writing tiny demo programs, and even looking at CityDesk internals at one point to see what Joel and Michael had come up with in a similar situation several years earlier. In short, I had completely forgotten to focus on building a feature, and instead become sidetracked on solving a technical problem that was, at its core, irrelevant to what I was trying to accomplish.
But Copilot didn’t have meetings then really at all. Tyler just trusted I knew what I was up to, and as the schedule slipped, he and Jason just assumed—correctly—that I was working on it.
Finally, they reached a breaking point. Jason and Tyler wanted to know what on earth was going on with the auto-update solution. I told them what was going on, and one heated discussion later, we agreed that I should quit trying to come up with how to do the “correct” solution, and instead focus on shipping a solution that worked, regardless of how it was implement. Two days later, I had a “kluged” solution done that worked just fine, thankyouverymuch, using multiple threads, and it was out to customers within about a week.
Since then, Copilot has had daily scrum-like meetings, and we haven’t looked back. Even though the meetings have no set agenda, we’re disciplined enough that our meetings generally last only five minutes, and they help keep us focused on getting solutions finished that are relevant to our customers, instead of getting sidetracked on technical digressions. They also help keep us abreast of what others are up to, specifically so that none of us accidentally end up losing sight of the forest for the trees, and focusing on a technically elegant solution over a pragmatic one.
The result? Copilot OneClick for Windows was in your hands six weeks after we initially decided we should do the product. Mac auto-update was done in two weeks of development, and Mac OneClick will be out by the end of November. And, as much as I hate to admit it, we owe a lot of that to meetings.
If being a heretic means we ship good products on time, I’m all for it.
Comments