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.
