Forbes picked up our Beautiful Teams interview with Tim O’Reilly and published it as an article called The Secrets of Great Teamwork.When Jenny and I talked to Tim, he had some intriguing things to say about what makes people work together. There’s plenty of good stuff in the interview, but one bit that really sticks in my mind is this excerpt:

Andrew: Do you think it’s possible to have a great team that doesn’t have a great leader? That has more of a collective leadership?

Tim: Yes, it is possible. But here’s the thing. Take Apache, because I think Apache is a great example of that. Tim Berners-Lee laid down the blueprint. He said, “I’ve created this idea for this hypertext server, this hypertext client.” And the genius of Apache was in embracing the constraints. I still remember back in the mid-’90s, this moment where Netscape had added this, Microsoft had added that, and everyone was saying, “Apache seems to be standing still. They aren’t adding all these features. They aren’t keeping up!” And the guys at Apache said, “Yup. What we do is a hypertext server, and we have this nice extension mechanism where people who want to do something else can add it on.”

And that goes back to that architecture of participation. They didn’t build this big, conglomerate, complex application. They kept to a pure vision. The vision did actually come from a visionary leader; it just wasn’t part of Apache. Apache came from a group of people who were abandoned by the NCSA server team when they all went to found Netscape. And there were a bunch of customers, so they said, “We have to maintain this, and keep it going.” What was wonderful about that kind of team was that they accepted the constraints that were laid down by the design of the system. They didn’t try to show off their ego or their creativity.

I think a lot of the work done by the IETF (the Internet Engineering Task Force) in the early years did the same thing. There were some wonderful principles laid down, and people really honored them. If you read some of John Postel’s stuff in the TCP RFC about the robustness principle, it sounds like something out of the Bible, for Christ’s sake! “Be conservative in what you do; be liberal in what you accept from others.” Literally, that’s what it says.

The point is that if you have the system architected right, you have a better chance of success for teams. You don’t want teams that are dependent on a single vision or leader, because if you loseWeight Exercise your leader, the whole team goes “pop.”

Something that came up over and over again throughout our many interviews and stories is the connection between teamwork and architecture.  I think Tim hit on exactly the right example with Apache, but there are a lot of other examples throughout the book. Peter Glück had some really interesting things about how the architecture restrictions of NASA projects affected the teams (and especially the practices they used). And Auke Jilderda talked about the “use-use-reuse” model for designing reusable code, and how it impacts teams. I have to be honest: before working on Beautiful Teams, I definitely didn’t make such a close connection between how great (or lousy) teamwork affects architecture.

You can read the entire interview — which, incidentally, is one of my favorites in the book! — on O’Reilly FYI.