We held a companywide meeting a few weeks ago in Chicago, and it forced me to confront an issue I had overlooked. Anyone who has followed this column over the years knows that most of the Basecamp team works remotely--we have employees all over the country. We've also grown--the company is now almost 50 people strong. Remote or not, a team that large presents challenges, and this meeting was the first time I'd had to deal with the effect of our size on product development.

Let's back up. For the past year or so, a small team inside Basecamp has been quietly plugging away on a big new idea, something that will broaden in a powerful way how people use our software. We're a bit more than halfway done, and the plan is to get a product into people's hands later this year.

The project started like everything else here. We begin with a small team riffing on something. If an idea looks promising, we layer in more people. Sometimes the idea gets more interesting, and other times it dies. And sometimes we hit on something so big we get goose bumps. We'll start parallel tracks to explore multiple versions. And if we're still into it, we go all in. That's the moment we had arrived at shortly before the all-hands meeting.

In the past, when we had fewer people, going all in was pretty straightforward. About four years ago, for instance, when we decided to build an all-new version of Basecamp, the company had about 25 employees. By the time we went all in, the majority of the team was already involved, and much of the vision and the specifics were common knowledge.

The current project had fewer than 10 people actively working on it before our meeting, meaning that 80 percent of the company wasn't in the loop. I had started hearing rumblings that people were confused. The parts of the work they had seen didn't seem to function all that differently from other things we had done, so why were we sinking so much energy into making the same thing, just in a different way? It was a fantastic question.

What I saw, and they couldn't see, was the bigger picture. We have a great vision, but it had been locked away in the heads of a few people who knew that what we'd built so far was just a foundation, and that now we would be able to move on to the real innovations. The team's blindness to that was my fault, of course. It's easy to forget, as a leader, that when employees don't get the wide view, not only does the point of their work escape them, but it can also lead to real frustration. It's hard to feel pride and ownership when you don't understand where things are going.

I started the meeting by acknowledging that we hadn't done a good job communicating and promised we'd do better. A few of us then spent several hours laying everything out and taking questions. We also set a launch date, so no one would be left wondering where the finish line is.

The irony, of course, is that Basecamp is a project-management tool whose aim is to foster better communication. What we realized with the new idea is that the stakeholders of a major initiative aren't limited to those most directly involved, so we've invited everyone in the company to the Basecamp project where we are managing the work and discussing progress and roadblocks. Further, we'll be sending out biweekly "heartbeats" to everyone--progress memos of a few hundred words that include a video tour of the latest work. This way, even if you aren't paying close, daily attention, you'll at least get regular briefings.

Maybe it sounds like dead-simple stuff, but this experience was a wake-up call for me. As much as I value the way we work, people shouldn't be doing it in the dark.