Will It Blend?
The Community/Company Spectrum
Part 1 in a Series Exploring Designs of Different Kinds of Organizations
This morning, I was sitting in an airport bar having an airport breakfast doing some airport reading when my phone buzzed. It was my friend Carl Smith and he had a simple question:
“Do you think designing a community is the same as designing an organization?”
My instant reaction was to try to frame community as a sort or organization, but I then I thought better of this pedantic trickery. I realized that what he really meant was, “what do I need to pay attention to if I’m setting out to build a community vs. what I know from building companies?” I think this is a really fantastic topic. In my consulting career I have helped produce both sorts of organizations. I think I have developed enough sensitivity to intuit the differences, but I have never set out to describe them. Over the next few weeks, I’m going to spend some time exploring different sorts of organizations, organizational designs, and my thoughts regarding them. This post explores some of the top level ideas that emerged when I thought about Carl’s question.
On the Terms “Community” & “Company”
In org design circles, it has become increasingly common to talk about building companies as communities, or to try to foster community within organizations. I’ve even written about this topic myself. However, for the purposes of this article, we’re going to make a distinction between community and company, wherein a community is an informal organization of people gathered around a common theme(s) (intentionally vague: could be a set of ideas, interests, geography, problems, beliefs, etc.), and a company is a formal organization designed to offer a clear solution to market problem. You’ll notice that each of these terms are defined somewhat unconstrictively, so “community” could be an HOA or a Slack group, and “company” could be AMEX or a community nonprofit — they aren’t necessarily distinct. These definitions are not perfect, and aren’t exactly what I would use in general discussions on this topic, but they are suitable for the discussion we’ll have in this context.
Membership, Interrelationships, and Tooling
As I considered the differences that matter between designed communities and designed companies, one of the most basal distinctions is the what and how of membership. In a company, membership is relatively binary. Glossing over some in-between or exceptional cases like contract work and freelancing, you are either part of a company (in the US this means you’ll get an annual tax form from them) or you are not. Your relationship is transactional. You contribute, they pay. Communities are much more fluid. In some cases, one is part of a community by merit of simply being in a place (think of a neighborhood or communities of common experience). That is to say, it isn’t necessarily joined. They don’t always require active participation, and the relationship between community members is often more important than the relationship to the community organization itself.
So What Does This Mean As We Consider Design
When we’re designing companies, we’re building and/or using pretty hard systems and are able to bet on consistency across platforms (theoretically). Things like IM tools, email, physical office spaces, intranets, budgeting, etc. tend to be bound together by merit of the imminence of the company’s organizational structure. When we think about communities, these things are less consistent between members. Some community members might be Facebook power users. Some of them might want to get on Slack. Some are intimidated by or incapable of using technology-oriented systems. Membership in a community doesn’t necessarily mean platform regularity or consistency.
When we began working on Stoke., we rapidly realized that the tools we were using to be more effective as org designers could actually be disenfranchising to the community we were desperate to support. Recognizing that we were designing a community vs. a company meant emphasizing the group actions we wanted to facilitate even over the tools by which we intended to facilitate them. The lesson? What we design must be responsive to the values and constraints of the community’s constituents, and must allow them to choose their own ways of organizing and the tools to supports them.
Will it blend? Thinking about edge cases
Given the distinctions pointed out here, I have to wonder about the increasingly common refrain of building communities out of our companies. Is this possible or realistic? Is there a blended state?
From what I have seen, I think that the blended state isn’t only possible, it is imminent. We’re starting to realize that, for a lot of industries, the notion of a compartmentalized “work-life balance” isn’t realistic (the way that we often conceive of it), so it becomes ethically and functionally proper that we make work a place where people can find community. If we want to harness the dynamism of the human community to operate effectively in an increasingly complex world (and complexity is a good thing!), then we should be examining how to make workplaces and organizations spaces of wholeness. This means letting people show up fully, with the support to develop their greater purpose and the agency to pursue it every day.
Thanks for reading! My name is spencer pitman. I design organizations, ski in the backcountry, ride my bike a lot, and cook food on snapchat every night @alcescow. If you want, follow me on twitter or just generally reach out and say hello. I like talking to people about almost anything.
