In my work as a web designer, I’ve seen projects fall apart despite the best intentions of brilliant people. A project’s outcome depends on effective collaboration as much as the skills of the people involved.  Assembling a team of the most talented designers, programmers, writers, and managers is a good start, but it does not guarantee success.

I recently attended an InfoCamp Seattle 2011 session on collaboration ((Lead by Andrew Mottaz. Thanks, Andrew! Update on 10/24/11: Andrew wrote up his own thoughts on the session on Protoshare’s blog. Check them out. )) that really clarified my thinking. One of the common themes was that no project management tool or workflow process assures a smooth project. This strengthened my belief that establishing shared values among a group plays a significant role in successful collaboration. I want to share some thoughts that, like good collaboration, I think add up to more than the sum of their parts.

What Collaboration Is Not

I’ll start with what collaboration is not: one person telling another what to do. That is how an operator works with a machine. Humans are not machines.

Unfortunately, this passes for collaboration at times. I have occasionally worked with clients who view me as a website machine (or Photoshop machine or WordPress machine). They seem to think that building a website works like this: Client Input → *Magic* → Website.

Avoiding this mental model of collaboration is a top priority when starting a new project. Otherwise, a project can devolve into micromanagement by the clients. “Can you make that green 10% more yellow?”

Collaboration Requires Trust

People cannot collaborate unless every person working on the project trusts each others’ judgements. Trust is the assumption that everyone is trying to make meaningful contributions based on their knowledge and skills. That doesn’t mean they all have to agree on every decision or idea, but it does mean that each member must give the other the benefit of the doubt.

For example, trust can completely transform the meaning of the above request to alter a shade of green. On its surface, that sounds like a personal preference. However, giving the benefit of the doubt means assuming that there’s a reason for that opinion. Maybe a competitor uses that green. Without trust, you may gloss over a comment that’s full of meaning and ideas.

Acknowledging Expertise Builds Respect

But how to build respect? I’ve concluded that acknowledging the expertise of every project collaborator is an ideal way to build respect. By expertise, I mean two things:

1. Specialized knowledge relevant to the project not held by other team members.
2. Knowledge that has developed over time and through experience. ((This sort of reformulates the 10,000 hour rule of mastery popularized by Malcolm Gladwell’s Outliers.))

True expertise is not easily dismissed and is built on other admirable traits such as perseverance and commitment, traits that will surely be useful on a large project.

In my case, many clients may not realize that, besides my technical knowledge, I am aware of accessibility best practices and general search engine optimization (SEO) principles. My clients are often experts on their industry’s terminology and their audience demographics.

To return to the earlier example, knowing the expertise of a collaborator gives team members the ability to ask relevant, pointed questions. “In your experience with other websites, does that green have a particular meaning in design?” “In your industry, what does that green mean?”

By explicitly identifying expertise, nitpicking becomes engaging discussion leading to valuable new ideas.

Valuing Alternative View Points

It’s often said that creative solutions come from unexpected sources, ones less ingrained in standards and ways of doing. But how to make this happen?

My theory is that identifying expertise builds trust—that “benefit of the doubt”—that allows all team members to eventually make contributions outside of their areas of expertise. It seems counterintuitive, but here’s my thinking: By acknowledging expertise to build trust, each collaborator learns to view the other team members as resources. As resources, team members are encouraged to share the reasoning behind decisions and opinions.  Not just the “what” but the “why.”

To return to the example, team members can respectfully pose questions such as “Why did you select that shade of green.” If there’s a good reason, collaborators can evaluate that reasoning and ask further questions. If that reason lacks support, then others can make suggestions, hopefully backed by a line of thinking that draws upon their expertise.

What started as nitpicking, is now a multidisciplinary discussion of web site standards, color theory, and the psychology of color.

That’s creative. That’s exciting. That’s collaboration.

Putting This to Use

Part of the reason I like this theory is that it provides a very loose “framework” that can be applied to different projects types, group sizes, and team relationships. There are probably other processes, tools, and interaction styles that can lead to good collaboration, but this is a theory that I am going to actively try to implement in future projects.

What do you think?

Does this align with your collaboration experiences (good or bad)?

Photo Credit: guttertec. Some rights reserved.