An inspiring post about Network and networks

While I was at SXSW, Bill Hart-Davidson tweeted me the link to this fantastic blog post by Michael Wojcik: {n1,n2,n3,…}. If you have any interest in networks - or in Network, my second book, which figures prominently in the post - you should go read it. As I tweeted back to Bill, I agree with about 90% of the post, but I respect all of it.

What's really extraordinary is that this post is not a formal book review or essay - it's a reading response in a graduate class. Bravo.

I love that Wojcik gets my general project, that he finds the strong parts, and that he doesn't pull punches when he finds the simplifications and glosses in my book. That's the mark of someone who is actually engaged with the text. It's flattering: it makes me think that I wrote something worth reading closely. (I also like that he lays into Deleuze and Guattari, but that's another story.)

What's the 10% that I don't agree with? For now, let me just leave you with one clue.

Wojcik's post comes at a good time, since I am thinking about writing an essay on networks anyway. More on that as it evolves. But until then, really, do click through and read his post. And then go write stuff like this.

"Hold on Loosely": The summary and some thoughts

Last week I held two conversations with two very different audiences about loose organizations. On Monday, I presented at Austin's RISE conference to perhaps a dozen local entrepreneurs. On Friday, I held a conversation with dozens and dozens - I have no idea how many, I'm terrible at crowd estimates - at South by Southwest Interactive. What struck me was how very different the conversations were.

RISE

At the RISE session, I gave a brief slideshow to introduce the notion of loose organizations - an umbrella term meant to describe ways in which people are working in less hierarchical, more agile ways that orient to common projects rather than job descriptions or departments. Then I asked several questions about the attendees' experiences with loose organizations. The results tracked fairly closely with the sorts of case studies I've been doing (e.g., independent contractors and coworking spaces in the Austin area). People named loose organizations such as

• independent contractor relationships
• coordinated relationships among nonprofits
• small, locally based virtual organizations (8-10 employees)

These people noted several challenges:

• Maintaining enough transparency to develop trust with team members, while maintaining enough opaqueness to keep clients unaware of the details they shouldn't know about.
• Coordinating projects (using Basecamp, Mavenlink, or other collaborative planning and communication tools).
• Figuring out what to keep in-house (either in skill or in capacity) and what to subcontract or outsource.
• Finding ways to support data infrastructure for loose organizations. Members emphasized cloud-based solutions.
• Finding ways to backchannel latest knowledge about projects and general knowledge for a given field.
• Being able to give up control to other specialists with whom you work.
• Being able to maintain strategy when coordinating transient project-oriented teams.

Hearing these points was gratifying, since they reinforced the sorts of things I had seen and read.

Then I got to Friday.

SXSW

The crowd at SXSW was much more diverse. Participants included:

• A coordinator for a major open source projects
• A representative of a company that produced software by coordinating software development contests
• A manager at a large construction company
• Owners of virtual organizations with employees based across the world
• Coworking space owners
• Members of companies using independent contractors

This crowd was largely not Austin-based - but more importantly, their organizations were generally not local in any sense, and they were generally much larger than the ones I have studied in Austin. Consequently, some of the challenges they mentioned were very different.

Members of geographically distributed organizations focused on challenges such as these:

• How do we attract and interest the right people to work with our organization?
• How do we vet these people and establish trust with them? How do we establish and track a reputation for them?
• How do we make sure we can command them (give them specific enough assignments) without controlling them (micromanaging them)? (This issue is particularly important in some states, such as California, where state regulations say that the amount of management can cause an independent contractor to be reclassified as an employee.)
• How do we keep multiperson teams coordinated, both synchronously and asynchronously?
• How do we make sure that people working in different time zones have times that they can communicate synchronously?

As you can see, compared to the concerns at RISE, these questions are much more heavily focused on long-term coordination and collaboration among people who are not geographically colocated. Part of the reason is that the RISE session participants were generally independent contractors and small businesses - but the SXSW session participants were generally owners and managers of larger, more distributed organizations.

So the SXSW crowd suggested several ways to handle these issues:

• Attracting and interesting the right people: Participants focused on having, sharing, and projecting a clear reason for working in their organization. They expressed this reason as cause, ideology, vision, or mission. They generally agreed that when you devolve decision-making across an organization, especially a geographically distributed one, you have to attract people to work with you. Team members had to look forward to more than a paycheck: perhaps a challenge, a chance to do good, a chance to change the world or participate in something bigger than themselves.
• Vetting and establishing trust: So how do you determine which team members will work out best? Participants had different mechanisms. On one end, one company attracts team members by posting challenges and holding competitions, competitions that represented stages in the software development process. In this case, as with most market transactions, trust is minimal but transaction costs are low; through multiple competitions, team members can prove themselves and improve their standing. On the other end, some companies focused on communicating their mission clearly during the hiring process; people who couldn't get on board with that mission would remove themselves from the process. Larger organizations leaned toward metrics and reputation systems, even rating systems, while smaller ones still went with the gut - but even then, the "gut" was informed by many, many different channels of interaction.
• Commanding without controlling: Here, people generally agreed that they had to simply be clear about specifications and deadlines. One organization had a three strikes policy: you could deliver projects late twice, but the third time, you would be cut out. Many organizations didn't even dictate a common tool set to their teams beyond specific, easily obtained communication software and a narrow set of tools used in their industry.
• Keeping teams coordinated: Again, responses ran the gamut here. One surprise for me was that people did not seem enthusiastic about project management software: one person complained that either you sank the time into it, in which case it became cluttered, or you didn't, in which case it became inaccurate. Instead, people focused on tools that could be used synchronously or with a short lag time. For instance, one reported that his virtual team simply kept Skype on all day so that they could see each other working and have conversations whenever they needed to. Others reported that all team members used IRC or IM.
• Coordinating synchronously. Many insisted that nothing could replace team meetings and synchronous conversations, although these didn't have to take place in the same room. But these opportunities can be difficult to achieve when people work in different time zones or on their own schedules. To open these opportunities, many reported posting availability schedules for team members and making sure that all were available during some part of the day.

My takeaways?

• Challenges look different on different levels of scale.
• Challenges look different on different sides of the table.
• People are finding their own uses for communication technologies.
• Teams are continuing to figure out trust, and they're beginning to apply reputation systems to team interactions.

And perhaps most importantly: Sometime soon I'm going to have to study a large, geographically distributed virtual organization.

Thanks to all who participated, and don't hesitate to leave your own thoughts in the comments.