In her talk, which has been viewed almost two million times since it was posted last month, Susan makes a compelling case that the open, collaborative world we embrace today is not always set up to harness the best work from introverts.

Click here to view the embedded video.

As we’ve moved toward more open office plans, collaborative processes like design thinking, and into a digital world now dominated by the word “social,” Susan wonders who is looking out for the introverts? Should introverts feel guilty about wanting to do their thinking and working alone? And can introverts do great work in group settings?

I spent more than a decade working in the inherently collaborative world of open source software. I regularly lead brand positioning and strategy projects as open, collaborative, social exercises involving entire communities of people in the process. So Susan’s talk made me ask myself a tough question:

By emphasizing a collaborative, social process am I risking leaving introverts—and their best ideas—behind?

It’s no secret that I am a life-long introvert myself. I am much more comfortable writing or reading a blog post in my living room and discussing it via comments or Twitter than I am sitting and talking about it with someone over coffee or, worse, at a social gathering like a party or a conference.

So I get where Susan is coming from. Deeply.

In her TED Talk, she at one point pleads, “Stop the madness for constant group work.” When she said this, it hit me pretty hard. The first thing that came to my mind was the one gazillion design thinking ideation sessions I’ve either run or participated in over the last 7 or 8 years.

I’ve personally never had much trouble speaking up during ideation/brainstorming sessions. But I also suspect I am a relatively mild introvert compared to others I know. I started to wonder what the hard-core introverts were thinking during these sessions (and if you were one of them, feel free to tell me below in the comments).

Did they feel like they were being talked over by extroverts? Did they feel like they were out of their element, or needed more time to process their thoughts before blurting them out and having them recorded on the wall? Would they have preferred to contemplate on their own instead of thinking socially as part of a group?

Then another thought stuck me: I’ve met a lot of software engineers over the years, and while not all of them are introverts, many of them are. Frankly, I don’t think too many extreme extroverts could stand to sit in their office and stare at a computer screen all day. But for some introverted software developers, this is bliss.

Yet open source software is developed in a collaborative, social process… run in many cases by introverts.

Why does that work?

For me at least, the answer comes down to the difference between virtual and in-person collaboration. Open source software developers do much of their collaborating online. Often this is because they are geographically dispersed around the world. But I’ve also seen developers sitting two feet away from each other communicating via instant messages or email.

Online collaboration has two key advantages over in-person collaboration for introverts:

1) It allows them to avoid stressful in-person social interactions.

2) It allows them to take their time, contemplate, and think deeply before responding.

Over the past two years at New Kind, I’ve personally been doing less and less in-person design thinking ideation sessions, instead hosting more open, collaborative sessions online. Sometimes they are efforts like the hackathons I’ve run for the Management Innovation Exchange that involve hundreds of people collaborating from all around the world. Other times they are client projects where the collaborating happens via Basecamp or another online tool.

I’ve found I enjoy facilitating sessions online much more than in-person sessions, and I think it suits my personality better. Because the collaboration happens asynchronously, I can take my time crafting thoughtful responses and generating ideas. I can wait until I’m in the right frame of mind to participate, and most importantly, I can work with others, yet be alone at the same time.

I suspect some of these same advantages also translate to participants in online group sessions as well. And for this reason, perhaps many introverts are more comfortable in collaborative projects online than in person. Some of the best ideas I’ve seen emerge from online collaborative exercises come from people who usually remain completely silent in meetings.

In many cases, online collaborative projects provide the best of both worlds—you can collaborate and build off the ideas of others, but still take the time to process your thoughts before you add them (and as a special bonus, you don’t have the stress of in-person social interaction).

If you consider yourself an introvert, I’d love to hear about your experiences participating in collaborative projects online vs. in person. Do you agree with Susan Cain’s assessment that collaborative group projects are not designed to get the best out of introverts? Do you find yourself making better contributions and contributing more in online projects? Or are online collaborative groups just as bad for you as in-person sessions, and you’d rather just work completely on your own?

I’d love to hear what you think.

Today, I am pleased to announce the first New Kind Board of Advisors.

On this board we are honored to welcome a fantastic group of people who are recognized leaders in business, education, public policy, and technology. These individuals not only bring great wisdom and deep experience, but each has a genuine commitment to making our world a better place in which to live and work.

Here’s a brief introduction to the members of our Board of Advisors (click on a name or picture to access the complete bio).

Josh Becker, Palo Alto, CA

Josh is a venture capitalist, the Co-Founder and General Partner of New Cycle Capital, and a former employee at Netscape, McKinsey, and Agile Software.

Laura Carpenter Bingham, Raleigh, NC

Laura is the former President of Peace College and currently serves on a number of corporate, civic and philanthropic boards.

Paul Jones, Chapel Hill, NC

Paul is the director of ibiblio, a contributor-run, digital library of public domain and creative commons media in the Office of Information Technology Service at UNC-Chapel Hill where he is also Clinical Associate Professor.

Eric Reeves, Dallas, TX

Eric is an attorney and the Founder and Managing Director of High Bar Companies. He is also a former member of the North Carolina Senate.

Mark Webbink, Durham, NC

Mark is the former General Counsel of Red Hat and is a visiting professor of law and executive director of the Center for Patent Innovations at New York Law School.

You may ask, why does New Kind need a Board of Advisors? The short answer is that the board will provide advice, recommendations, and guidance to New Kind related to corporate goals and strategy.

But beyond that, we believe an outside board will make us a better company; better for our own personal growth and better for those organizations and companies that we are fortunate enough to call our clients.

We are humbled that these accomplished individuals are willing to invest their time and expertise in helping us build a great company.  And to our advisors I say, thank you for agreeing to serve.  We will do everything we can to exceed your expectations.

The article pits two experts who debate the issues involved. Harvard Law professor Jonathan Zittrain defends the classic ubiquity argument—“with open systems, a company can court far more usage and mind share.”

Frog Design’s Mark Vandenbrink, in his best “Jane, you ignorant slut” voice, retorts that Apple’s closed system gives the company a competitive advantage by creating “a more perfect experience” for its customers.

Who’s right? They both are. Apple proves closed systems work. Red Hat proves that open systems work. Both can drive competitive advantage. The idea that one strategy is right and therefore one strategy is wrong is flawed.

Instead of falling for that argument, let’s note that these systems are ‘creative/innovation’ systems—not software ‘development’ systems. This is a more self aware mode of comparison and from this perspective we can choose to make trade offs based on which design system will align better for our specific strategy.

Apple’s closed system worked because the company embraced a high-level commitment to design thinking and design-as-form. The systems and artifacts they designed were created to be beautiful and highly ‘human’ (as opposed to engineered technology). Frog Design is an expert in this form of design. But this ‘closed’ system is very expensive, highly dependent upon one powerful, ‘visionary’ design leader. Few businesses possess such committed leadership.

On the other hand, design has always been a competitive strategy chosen by desperate players. It’s easy to forget now, but as recently as six years ago Apple was anything but a lock to survive. Much less thrive. With Microsoft enjoying 96% of the market, Apple was a desperate company.

Thankfully for Apple shareholders and fans alike, Jobs was the man for the job. His early exposure to design, coupled with finding his design soul mate, created the opportunity to succeed. But it was a highly risky strategy. And one that could have easily failed.

Red Hat shareholders and fans know that open systems also drive a competitive advantage. Indeed, Red Hat is proof positive that a small company with nothing to lose can use open strategies to great success. With competitors like Microsoft, Oracle, Sun Microsystems and Novell (remember them), this small player has become a billion dollar company…selling ‘free’ software. That’s a pretty compelling story on the competitiveness of openness.

It’s only fair to note that Apple has utilized more open strategies with its open iPhone application creative process. Less known is the fact that Apple operating systems have, for years, been based on the same open development community-driven processes that Red Hat’s enterprise software uses—even Apple didn’t start from scratch.

In the end, both companies succeeded because of the disciplined and courageous leadership of two non-conformist business leaders who shared an inherent (though differing) belief in ‘design’—Steve Jobs and Matthew Szulik. Fortunately for me, I had the opportunity to work directly with one of these men. And every day I enjoy the products and services the other helped create.

Open or closed? Yes.

Ever since my friend Paul Salazar first introduced me to the book Built to Last back in 2002, I’ve been a willing member of the cult of Jim Collins. During my time at Red Hat, we took some of the ideas from Built to Last as inspiration for the process we used to uncover the Red Hat values. Then we later employed many of the principles from Collins’ next book Good to Great as we further developed the Red Hat positioning, brand, and culture.

Check out this picture of my copies of Built to Last and Good to Great, with little Red Hat Shadowman stickies marking the key sections I refer to the most. (I’m such a nerd.)

While many of the Big Concepts (TM) expressed in these books may initially seem a bit cheesy and Overly Branded (TM), I’ve come to love and occasionally use some of the terms like BHAGs (Big Hairy Audacious Goals), the Tyranny of the OR, Level 5 Leadership, and my longtime favorite The Hedgehog Concept. Why?

Because they are just so damn useful. They make the incredibly complex mechanics behind successful and not-so-successful organizations and leaders simple and easy for anyone to understand. They are accessible ideas and you don’t have to be a former management consultant with an MBA from Harvard in order to understand how to apply these principles to your own organization.

I’d go so far as to say that over the past fifteen years, no one has done more than Jim Collins to democratize the process of creating a great organization.

So when I found out that Jim Collins had a new book coming out, his first since the rather dark and depressing (but no less useful) How the Mighty Fall in 2009, and that he’d been working on this new book with his co-author Morten Hansen for the last nine years, I was ready for my next fix.

I finished the new book, entitled Great by Choice: Uncertainty, Chaos, and Luck–Why Some Thrive Despite Them All a few nights ago, and here are my thoughts.

This book comes from the same general neighborhood Collins explores in his previous books (I’d describe this neighborhood as “what makes some companies awesome and others… not so much”), but instead of simply rehashing the same principles, this book explores a particularly timely subject. From Chapter 1, here’s how Collins and Hansen set up the premise:

“Why do some companies thrive in uncertainty, even chaos, and others do not? When buffeted by tumultuous events, when hit by big, fast-moving forces that we can neither predict nor control, what distinguishes those who perform exceptionally well from those who underperform or worse?”

In other words, what common characteristics are found in companies that thrive when the going gets wacky? (Times like, for instance… right now.)

In this book Collins and Hansen clearly did an immense amount of research to answer this question. In fact, as with Built to Last and Good to Great, the appendixes at the end “showing the math” for how they reached their conclusions take a third or more of the book.

Their research led to a set of companies that they refer to as the “10x” cases because, during the study period, these companies outperformed the rest of their industry by 10 times or more. After looking at over 20,000 companies, the final organizations that made the cut were Amgen, Biomet, Intel, Microsoft, Progressive Insurance, Southwest Airlines, and Stryker.

Now you may look at this list, as I did, and say to yourself, “Okay, I get Southwest Airlines and Progressive Insurance… but Microsoft????”

Well, as it turns out, the period they were studying wasn’t up until the present day. Because this research began nine years ago, they were studying the companies from 1965 (or their founding date if it was later) until 2002. So in that context, the choice of Microsoft makes a lot more sense. In 2002, Microsoft was still firing on all cylinders (believe me, I remember).

I won’t spoil the whole book for you, but Great by Choice has an entirely new set of Big Concepts (TM) that will help you understand the characteristics that set these companies apart from their peers. This time around, we are introduced to:

-The 20 Mile March: Consistent execution without overreaching in good times or underachieving in bad times.
- Firing Bullets, Then Cannonballs: Testing concepts in small ways and then making adjustments rather than placing big, unproven bets (basically akin to the open source principles of release early, release often and failing fast). But then placing big bets when you have figured out exactly where to aim.
- Leading above the Death Line: Learning how to effectively manage risk so that the risks your organization take never put it in mortal danger.
- Return on Luck: My favorite quote from the book perfectly articulates the concept: “The critical question is not whether you’ll have luck, but what you do with the luck that you get.”

Many of these concepts come with an awesome allegorical story to illustrate them. That’s the great thing about a Jim Collins book: you can’t always tell whether you are reading a business book or an adventure book. In this case Collins (who is also an avid rock climber himself) shares tales from an ill-fated Everest expedition, the race for the South Pole, and a near death climbing experience in Alaska interspersed with specific stories from the businesses he is profiling.

Overall assessment: The book is a fitting companion to Built to Last, Good to Great, and How the Mighty Fall. Simple, accessible, easy to digest, and with some very actionable key concepts that you can immediately put to use. And, unless you read all of the research data at the end, you’ll find it to be a quick read that you can likely finish on a plane trip or in an afternoon.

So go on, pick up a copy and let me know if you agree.

Most of you probably know Mozilla as the organization famous for its open source Firefox web browser. But what you may not know is that open source is more than just a technology decision for Mozilla; the open source way is deeply ingrained in every aspect of its culture.

Last week, Mozilla Technology Evangelist Paul Rouget wrote a post on his blog entitled Mozilla Openness Facts. In it, he attempts to capture as many examples of openness in action at Mozilla as he can.

Here are just a few of the examples Paul shares (read his post if you want to see the rest):

1. An open door office policy: open source contributors are welcome to drop by Mozilla offices and hang out. In fact, Paul notes that he first met current Mozilla CEO Gary Kovacs (before he joined Mozilla) when Gary visited the Paris office where Paul works.

2. Transparent financials: Sure, many companies publish their financial results publicly… because they are public companies. Mozilla isn’t, but still does.

3. Open meetings: No strategy behind closed doors here. Not only are many of Mozilla’s meetings open to the public, they often post the phone numbers (and even video conference URLs) on their wiki.

4. Public product roadmap: Want to know Mozilla’s future technology direction? No need to hire a private investigator, you can find the product roadmap on the wiki too.

Not all of these examples are unique to Mozilla and some of them are simply a part of being a responsible member of the open source movement. But what is unique is that someone took the time to catalog the openness examples.

It’s a fantastic idea, and perhaps something that every company that bills itself as open should attempt to do in a public forum.

I reached out to Paul to ask him a few questions about openness and what motivated him to compile the list of examples. Here are some highlights from our conversation:

First, I asked him about some of the challenges that come with openness and transparency. One of the points he made that resonated most with me is that “being open is not a passive task.” It isn’t enough just to make information open—you must be active about helping people find it.

“Open meetings are meetings where anybody can come. But you have to promote these meetings. Make sure the contributors hear about them. Same for mailing lists and IRC channels, open channels, but you need to find them… Just keeping the doors open is not enough,” says Paul.

Paul also pointed out another crucial lesson of organizational openness, that being open doesn’t mean everyone has the right to vote on everything.

“Being transparent and open doesn’t mean we are a democracy. We listen to everybody, but we believe that the most skilled people should make the most important decisions. And you don’t have to be an employee to be a decision-maker.”

Finally, I asked him why he took the approach of “showing vs. telling” in writing the post (which I loved, very esse quam videri). Here was his response.

“I was trying to define openness. I failed. Much easier to show. Everybody is talking about how transparent and open they are. Even big and closed companies. I say b$%^&*!t, they are not. They just use openness as a new buzz word and a new marketing thing. If you are open, show me your meeting notes, show me your source code, let me be part of your team conference calls, let me look at your metrics, and let me work with you.

I wanted to show that being open is much more than just being open source.”

Well shoot, that sounds a lot like what we are trying to show with opensource.com:)

Nicely done, Paul. Nicely done, Mozilla.

[This post originally appeared on opensource.com]

After working with Eugene on the story of Wikimedia’s open strategic planning process, I’d remarked to him that the Wikimedia effort was one of the most successful, large-scale collaborative exercises I’d ever seen. Eugene replied that if I thought their project was big, I should read Power and Love to get a sense for the types of large-scale collaborative projects Adam tackles, often on the scale of nations.

It’s really a wonderful, introspective book, filled not just with successes but failures as well, and is probably one of the better-reviewed books I’ve seen on Amazon.

Adam is perhaps best known for his work facilitating the Mont Fleur Scenario Project in South Africa in the early 1990s. In an incredibly difficult, post-apartheid environment, Adam brought a diverse group of people together to collaborate on ways to smooth the country’s transition to democracy. He has since led collaborative projects in India, Guatemala, and Israel, among other places around the world, and describes many of these projects in the book.

As I read, I couldn’t help but notice one thematic appearing over and over. In many of Adam’s projects, there was little hope of getting everyone involved to rally around a shared purpose, something I view as a pre-requisite for building a successful community of passion. In fact, even when a fragile collaboration was pieced together in a workshop, it often would fall apart again quickly once the session was over.

In the open source world, we are usually lucky enough to be working with opt-in communities. Meaning, people are participating of their own free will, and have almost always joined the project because they share a common belief about what it might accomplish.

But reading Adam’s book has made me wonder, do the principles we regularly discuss here on opensource.com apply in communities where passion is strong, but not everyone shares a common purpose? Can open collaboration be successful in places where competing agendas are flourishing and not everyone has opted-in to the same project?

My experiences tell me that in communities without a shared purpose, productive open collaboration is usually incredibly difficult. Our current political environment here in the United States is certainly case study #1.

In the open source world, we don’t know how lucky we have it.

Do you think an open, collaborative approach can really succeed in environments where not everyone shares a common purpose and has joined of their own free will?

I’d love to hear what you think.

[This post originally appeared on opensource.com]

You’ve been using open source software or contributing to open source projects for a long time. Perhaps you are in a job where you utilize open source tools regularly, or maybe you are just fooling around with them for fun or to learn new skills.

You’ve been known to tell (possibly true) stories that highlight how long you’ve been a part of the open source world (from “I remember downloading the first version of Fedora” to “I was in the room when the term open source was coined”). But, most importantly, you consider yourself an active member of one or more open source communities.

Did you ever consider that your time spent participating in these open source communities might be more than just good technology experience? That it might prepare you for jobs completely unrelated to using or making software?

In college, I studied history and political science. Not because I wanted to be a political scientist or a historian but because, well… actually I’m not really sure.

But in retrospect, I’m really happy I studied these fields.

Why? They gave me plenty of experience doing research, writing, and learning to articulate my thoughts and ideas effectively. While I don’t remember how Alexander the Great defeated the Persians at the battle of Issus and I can no longer compare and contrast the views of Rousseau and Locke effectively, I use many skills I learned when studying these subjects on a daily basis.

At the risk of sounding like an advertisement for a liberal arts education, let me get to the point.

While you’ve been happily participating in open source communities because you have a need for a piece of software or want to help make it better, you may also be the beneficiary of an important side effect. You may be getting experience in how organizations of the future will be run.

Over the past few years, I’ve had an opportunity to work with organizations in many different industries, including finance, education, service, hospitality, even in the government and non-profit worlds. Many of these organizations are busy exploring how they can better compete using techniques that many of us in the open source world have already successfully put into practice.

For example, some are interested in testing large-scale collaborative projects involving people outside their organizations. Others want to know how to create internal meritocracies where people feel empowered and the best ideas can come from anywhere. Others want to begin to form more meaningful relationships with the community of people who care about their organizations. If you’ve been reading opensource.com, you’ve seen us highlight many examples in business, government, education, health, and elsewhere.

These organizations have a lot to learn from those of you who already have real experience using these practices in real communities.

In his book Outliers, Malcolm Gladwell introduced the idea that those who became world-class practitioners at their craft (he uses examples like Mozart, Steve Jobs, and the Beatles), have done so in part because they were able to get an inordinate amount of practice before others in their field. According to the research Gladwell cites in the book, a person needs about 10,000 hours of practice to achieve mastery.

How close are you to putting in 10,000 hours participating in the open source world? If you’ve spent 40 hours a week working in open source communities for 5 years, you may have your 10,000 hours in already.

But even if you don’t yet have 10,000 hours, my guess is you’ve already learned quite a bit about how open source communities work.

So if you believe that the organizations of the future may be run using many of the same principles that are currently being used to great effect in open source communities, and you already have plenty of experience working within those communities, could you be an asset to an organization that is looking for better ways to compete? And could you be an asset not just because of your open source technology skills, but also because of your open source thinking skills?

An example: My friends Dave Mason and Jonathan Opp, who each have well more than 10,000 hours of experience in the open source world, recently entered the joint Harvard Business Review / McKinsey M-Prize contest on the Management Innovation Exchange with a hack deeply inspired by their open source experience.

Their idea? Take the principle of “forking” as practiced in open source development projects and apply it to the way organizations are managed (read the full details of their hack here). Their “Free to Fork” hack was recently selected from a pool of almost 150 entries submitted by people from around the world as one of 20 finalists for the M-Prize. Pretty impressive.

So think about it: Beyond your technology experience, what else have you learned from working in open source communities that might be valuable to a potential employer? Are there hidden skills or ways of thinking open source has taught you that might be worth highlighting in a job interview or in making the case for a promotion or new assignment?

Start thinking of your open source experience as a new set of thinking and working skills that may be very much in demand in organizations hoping to remain competitive in the future.

By doing so, you might open yourself up to interesting opportunities you wouldn’t have considered before.

[This post originally appeared on opensource.com]