Skip to main content

Community is a verb

Over the course of my career, I've been part of multiple initiatives to start internal communities at work. Some of them became something genuinely special — people showing up, contributing, looking forward to the next gathering. Others quietly died after a few months, victims of low attendance and dwindling energy.

For a long time I couldn't figure out what separated the successes from the failures. Was it the topic? The timing? The right people involved? I kept searching for the formula.

Then I listened to an episode of the ReThinking podcast last week where Adam Grant sat down with Dan Coyle — author of The Culture Code and his new book Flourish — and one thing Coyle said stopped me in my tracks.

Community, he pointed out, literally means shared gifts. And shared gifts aren't something you passively receive. They're something you participate in.

We've been thinking about it the wrong way

Maybe you’ve tried to build an internal community before. You scheduled kickoffs, crafted mission statements, send out invites, and waited for people to come. There's a meeting. Maybe a few more meetings. And then slowly, painfully, the whole thing fizzles.

What's missing isn't better planning. It's action.

Coyle makes a sharp distinction between complicated problems and complex ones. Complicated things — like building a car — can be solved with a detailed enough instruction manual. Complex things, like raising a teenager or growing a living community, respond differently every time you engage with them. You can't plan your way through them. You have to try things, see what happens, and adjust.

Internal communities are deeply complex. And yet we keep treating them like they're complicated.

Awakening, not building

Coyle reframes the concept: we don't build community. We awaken it.

It was already there. The desire to connect, to contribute, to belong — that's not something you manufacture. It's dormant, waiting for the right conditions. What those conditions require isn't a perfect structure. They require someone willing to say: here's the table, here's the invitation, come on Tuesday at noon.

He tells the story of Patrick Bernard, a shy, introverted journalist in Paris who, after retiring, decided to run a social experiment. He rented 80 long tables, set them up in the middle of the street, and invited his neighborhood to the longest dinner table in Paris. No grand strategy. No sponsorship deck. Just an action. What emerged from that single, slightly absurd act was a self-organizing network of book clubs, bike repair groups, memory circles, and mutual aid that transformed a previously snobbish neighborhood into something resembling a village.

Nobody planned that outcome. Nobody could have.

The pattern

Reflecting on my own experiences, the communities that worked all had one thing in common: something happened early. Not a vision document. An event. A small, slightly messy thing that gave people a chance to show up, contribute something, and leave feeling like they were part of something real.

The communities that failed? They were over-prepared and under-activated. We spent so long getting the setup right that by the time we launched, the energy was already gone. We built the stage but forgot to start the show.

Coyle calls this a bias for action. The worst advice about building community, he says, is "think it through." Communities don't spring from careful planning. They spring from experiments. From trying something, noticing what happens, and doing more of that.

Letting go

The counterintuitive insight Coyle returns to is that the best thing a community leader can do is let go. Not step back entirely, but stop trying to control every outcome. The leaders who kill communities are the ones who can't tolerate the mess — the uncertainty, the self-organization, the surprise.

Four words Coyle hears over and over in flourishing communities:

It's up to you.

Those words aren't abdication. They're an act of trust. They create the conditions for ownership, belonging, and genuine contribution. They're the difference between community as a program someone runs and community as something people genuinely inhabit.

And maybe this is not only through for building great communities but also great organizations.

The takeaway

Don't wait until everything is ready — it never will be. Pick a date, invite people, and do something together before you've figured it all out. Give people enough structure to show up, and enough freedom to surprise you. Then tolerate the mess that follows, because that mess isn't a sign something is going wrong. It's the community forming.

Go set up the table. See who shows up.

More information

The keys to a flourishing community with Dan Coyle - ReThinking | Podcast on Spotify

The keys to a flourishing community with Dan Coyle (Transcript)

Community - Etymology, Origin & Meaning

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...