1. Copying or modifying what other teams have already done. I see a lot more of the copying of open hardware and open source software than of anything else, which is fine and good, but not the entirety of what chapter was talking about in my mind. In the chapter it’s more about the how than the what, meaning that you learn how another team did something so you learn how to avoid pitfalls, and gain hard won insights. You don’t have to repeat the other team’s failures. That’s one reason Mach 30 documents our entire engineering process, from the initial assumptions and goals we start with all the way through to the errata (problems with the design).

Unfortunately though, it’s been my experience that many open source groups are so eager to get started and forge their own path that they don’t always take the time to thoroughly research what’s already out there. It’s great to forge ahead and be on the cutting edge, but you don’t want to reinvent the wheel along the way. If you stand on someone else’s shoulders you’ll be able to reach much higher much more quickly. To me, this is what the FSF’s software freedom #3 is about – continually building off of each other’s efforts to accelerate development. http://www.gnu.org/philosophy/free-sw.html

2. Getting information from unexpected sources. In the chapter, teams in one industry would find and learn from teams in another industry. The outside team had already gone through the process the X-team was now in the midst of. I think that this highlights that you shouldn’t wall yourself off to learning from another, very different, open source project. If you’re working on a rocket motor test stand, you shouldn’t be opposed to learning lessons from a team that is working on an E-textile project. You’ll see this in action on forums, Google+ groups, etc where there is a good diversity in the participants.

3. Being on the lookout for technologies that were dropped but are still viable. The chapter mentions that the RAZR team picked up on technologies that were dropped for various reasons. These technologies were abandoned, but still had the potential to be reused or re-purposed to make the RAZR team’s product a reality. However, I think there’s a balance here between learning from other teams about what technology didn’t work, and being willing to revisit an abandoned technology. It would probably be best to check with another team on why a piece of technology didn’t work for their project before evaluating whether or not it will work for yours.

[I'm going to use Mach 30 as an example, and I have comments for each X-teams sub-principle. Additional comments will be added later after I finish editing my response.]

Q2-LEADERSHIP EFFECTS ON XTEAMS: It seems like a “normal” team can be transformed into an X-team given the right leadership. If the leader is clear about the need for external engagement, as an example, then the rest of the team can follow. However, in “flat” or distributed leadership teams, it seems like it may be much more difficult to mandate the activities of an X-team. These teams are already working “outside of the box” and it seems like all the “normal” team processes and dynamics go out the window. Implementing a new X-team process is a bigger challenge because all members of the team need to be informed about what that even means.