Building, Together, Separate

On Friday, we wrapped up Development Seed Team Week 2026 and said goodbye to our Blagden Alley office. Our organization ("less of a company and more of a co-op", according to one) manages to bind sixty-odd people who are scattered all over the world into a mostly-self-organizing system. The whys-and-wherefores of our operations are constantly evolving, but there's some common themes that we've kept over the years¹.

I thought it could be useful to distill those down here, both to help clarify my own thinking and possibly help others who are trying to grow similar organizations.

Write your ideas

It seems obvious but it's so often forgotten — write your ideas down. Conversations (whether they're verbal, typed, or in some other mode) are wonderful for shaping ideas within a group of people. Once the idea is shaped, or it's reached the point where it needs decisions or research, write the idea down in a searchable, linkable, and shareable place. This gives you a checkpoint in your own reasoning, and allows others to inspect how you're thinking about a problem.

LLM-based tools are excellent at reading things that humans write, and are at their best when they're reading concise Markdown documents. Those checkpoints in thinking will be useful as inputs to LLM-based tools.

At Development Seed, we use Github repositories and issues for the vast majority of our communication-based writing. You might use a different medium, but whatever it is, write your ideas down and share them.

Public² by default

I would bet that 99% of Slack users have heard (or said):

I didn't put it in the public channel because it's too noisy.

Our hot take is that you should do it anyway. Here's why:

• You never know who might get benefit from reading your messages.
• Use threads to reduce channel noise. Don't like threads? Tough, learn to like them.
• When things feel awkward or too "meaningful" for a Slack thread, summarize the conversation as an issue and move the conversation there.

Obviously, there's exceptions around personal communications, privileged client information, and HR-adjacent issues. But in general, direct messages are an anti-pattern and multi-person DMs that are more than quick chats should be converted to public channels. The same goes for your ideas; unless there's a very good reason for them to be private, make them public.

Understand the difference between communication and creation

We don't do everything in Github at Development Seed. We use Google Drive for proposals and spreadsheets, and we use a huge suite of tools (Figma, Miro, etc...) for collaborative communication, design, and ideation. These tools are designed to produce a single artifact (proposal, documentation, design); they might have a "change history", but that's not the key output. For a proposals that's fine/good, but a conversation's history is as important as its final outcome.

Keep your communication in threaded mediums (e.g. Github, Slack) and keep them out of "artifact creators" like Google Drive or wikis.

Be flexible

We're constantly re-evaluating how we communicate and work at Development Seed. We have a strong culture of sharing out learnings, whether that's as a GitHub issue on our internal developmentseed/how repository, through live demos, or via video. However you design your system, make sure it has space to grow and change. Spend some time thinking about your grounding philosophies and principles before you start designing process, and you'll be ready to adapt when the next tech tooling revolution comes around. I don't think it's purely by chance that our model of public, written communication pairs extremely well with the LLM-based tooling revolution that's happening right now, and we've kept that model only because we've had a few core ideas that we can fall back on when it's time to make a change.