I'm a fan of sharing lessons learned along the way.  One light-weight technique I do with a distributed team is a simple mail of Do's and Dont's.  At the end of the week or as needed, I start the mail with a list of dos and dont's I learned and then ask the team to reply all with their lessons learned.

Example of a Lessons Learned Mail

Collaboration

• Do require daily live synchs to keep the team on the same page and avoid churn in mail.
• Do reduce the friction to be able to spin up Live Meetings as needed.

Guidance Engineering

• Do index product docs to help build categories and to know what's available.
• Do scenario frames to learn and prioritize the problem space.
• Do use Scenarios, Questions and Answers, Practices at a Glance, and Guidelines to build and capture knowledge as we go.
• Do use Scenarios as a scorecard for the problem space.
• Do use Questions and Answers as a chunked set of focused answers, indexed by questions.
• Do use Practices as a Glance, as a frame for organizing task-based nuggets (how to blah …)
• Do use Guidelines for recommended practices (do this, don't do this … etc.)
• Do create the "frame"/categories earlier vs. later.

Personal Effectiveness

• Do blog as I go versus over-engineer entries.
• Do sweep across bodies of information and compile indexes up front versus ad-hoc (for example, compile bloggers, tags, doc indexes, articles, sites … etc.)

Project Management

• Don't split the team across areas.  Let the team first cast a wide net to learn the domain, but then focus everybody on the same area for collaboration, review, pairing …etc.

Tools

• Do use CodePlex as a channel for building community content projects.

Guidelines Help Carry Lessons Forward
While this approach isn't perfect, I found it makes it easier to carry lessons forward, since each lesson is a simple guideline.  I prefer this technique to approaches where there's a lot of dialogue but no results.  I also like it because it's a simple enough forum for everybody to share their ideas and focus on objective learnings versus finger point and dwelling.  I also find it easy to go back through my projects and quickly thumb through the lessons learned.

Do's and Don'ts Make Great Wiki Pages Too
Note that this approach actually works really well in Wikis too.  That's where I actually started it.  On one project, my team created a lot of lessons learned in a Wiki, where each page was dedicated to something we found useful.  The problem was, it was hard to browse the lessons in a useful way.  It was part rant, part diatribe, with some ideas on improvements scattered here or there.  We then decided to name each page as a Do or Don't and suddenly we had a Wiki of valuable lessons we could act on.