This post captures a couple of quotes from an interview with Tim O’Reilly about leadership and effective collaboration that I found intriguing. My take-aways in summary: recognize that you have to set a context, which entices people to contribute to; know the strengths and weaknesses of your team members; and create a (decentralized) system that allows every member to realize their own vision, while still contributing to the whole.
On defining leadership:
Harold Geneen (…) said, “The skill of management is achieving your objectives through the efforts of others.” (…) While I completely subscribe to the concept, because the skill of management is indeed achieving your objectives through the effort of others, I have always worked with the framing of another quote, which is actually about writing (…) from Edwin Schlossberg, who (…) said, “The skill of writing is to create a context in which other people can think.”
On being a team leader:
It’s a kind of pattern recognition, which is going back to how I think about the process of editing. It’s a little bit like what Michelangelo used to say about making a statue; that it’s about finding the image that’s hidden in the stone. I think editing a book is like that. Leading a project is like that. (…) I think that leading your team is like that also. How do you get a group of people to achieve their potential? By seeing who they are, and what they can accomplish.
On the architecture of participation:
I think one of the reasons why certain projects fail is because they’re mixing and matching from the wrong systems. We have to have a system that has a fundamental characteristic that there are small pieces that people can work on independently. I think this is why, for example, people have said that they’ll do books as Wikis, and it hasn’t really taken off. Why not? Because a book is a fairly large, complex thing with a single narrative thread. Wikipedia is a set of pages, and the atomic unit of content is something that a single individual can make a plausible promise at, and other people can update and tweak. And the whole is the sum of many, many such small parts. I think, for example, that there are certain types of works that lend themselves to that kind of collaborative activity–being more free-form precisely because they’re designed in such a way that the pieces fit together.
Especially the last quote, the reasoning why wiki books have not taken off, makes me wonder if real collaboration with complex team processes can be designed to work beyond organizational contexts where someone can set the right incentives (e.g. through compensation) to have everyone pull in the same direction.
Thanks for sharing! My company, Syndicom, builds collaboration software for Spine/Ortho/Trauma surgeons. The big take away I got from this is what I call “realistic contributions”; doing things in small chunks, too.
hi walker, does your lesson relate only to building your software or also how the users of your platform work together? If yes, how does your platform help split things in realistic contributions?