So you’ve got codebases in Python, PHP, C and Java and an engineering culture that places a real premium on being able to throw everybody into a room and keep projects with lots of parts and lots of design decisions moving. But you’ve got engineers in Austin, Dallas and Phoenix, development partners in NY and SF, and at least one vendor in Dubai. How to have your rapid dev cycles and eat them too?

One of the best answers we’ve been able to conjure up for our own projects has been the notion of the standing project bridge. Conferencing wonks use the term bridge as a synonym for conference call. And we’ve coined the phrase project bridge to mean any type of highly internally publicized, dedicated conferencing number that everybody on the team has programmed into their Palm or iPhone and can dial into in a matter of seconds. The result is that anybody on the team can send out an IM or a text or (heaven forbid) an email with a request for the team to “hop on bridge 1″ or “hop on bridge 2″ or “hop on the API release bridge” and get an instant decision making forum in seconds.

It works. And it’s superfast.

So what do you need to conjure up project bridges for your own team? A couple of things.

First, you need a good conferencing provider. And you specifically need a conferencing provider who’s comfortable handling instant meet-me conferences that require no advance scheduling; advance scheduling is the enemy for this type of dynamic.

Second, you need everybody to commit the project bridge to memory (at least to a trusted memory offload cache in the favorite PDA). It’s no good digging through email or Google notes looking for “the 800 number we used last time.” When dialling into a project bridge gets as fast as dialling any other contact you’ll be amazed at how readily everybody will hop the bridge, work some stuff out, and get on with life.

Last, you need to get past the old ideas that conference calls are shareholder broadcast calls where one important dude talks and everybody else listens. The future of conferencing lies exactly not the old corporate broadcast event but in this type of 4 - 6 person instant bridge where everyone gets to talk, everyone gets to argue, and everyone gets a decision, fast.

UNIX screen is still be the single best developer collaboration tool ever. And dedicated project bridges come in a very close second.

Related posts:

1. Developer Collaboration, Part I The single best collaboration tool for developers? Unix screen. Try...