Introducing ccccharter

There's a specific kind of organizational tragedy that happens every day:

A team gets re-org'd (again). Someone makes a deck (of course). Everyone nods. The deck gets filed into the corporate catacombs. Two weeks later the same team is fighting about scope, authority, and who owns the gnarly work. Again.

In 2020 I wrote a post called "Software for Scaled Organizing," about how PowerPoint is a terrible tool for organization design, and leader- or HR-owned maps of reporting lines aren't the answer. So I finally did the thing I've been whining about for years: I built a small web app that lets any team create a charter that's easy to access, easy to edit, and hard to lose. Shoutout to my friend, Cullen MacDonald, for trying to help me make this a couple years ago. We were busy at that time, so we didn't really finish.

A new version of this idea is live at ccccharter.com. (Here's a dummy charter so you can go see a filled example.)

Why this tool exists

There's good evidence that team structure predicts outcomes, including code quality. But most orgs treat structure as something that gets decided during a reorg and then frozen until the next one. The people doing the work don't get to adjust the machine they're inside.

Part of the problem is the artifacts. Org charts, RACI matrices, slide decks: these formats look authoritative, but they're hard to edit, hard to keep current, and usually locked behind someone else's permissions. There's usually multiple versions of the same thing. All of this conspires to make org design feel like something that happens to you, not something you do.

Team charters: the artifact and the practice

A team charter is a compact guidebook for five things:

1. Purpose: why this team exists
2. Focus Areas: what we do, what we don't, where we're spending attention
3. Measures: how we know we're winning (metrics + behaviors)
4. Decision Rights: what we decide autonomously, where we consult, what we depend on (DICE format, because of reasons)
5. Roles: the distinct accountabilities the team needs

A charter is an artifact and a repeated practice. Make it together. Test it against real decisions. Review it on a cadence (65). Keep it accessible to stakeholders.

You don't need permission to clarify how you work

A team charter is supposed to be written by the people doing the work. But in most orgs, the "official" org system is locked behind HR admin workflows, licenses, or IT. So teams end up writing their charter somewhere else, like Notion, Google Docs, or Confluence.

Those tools can work. But they have two failure modes. First, access friction: the person who most needs the knowledge can't get at it (no account, no permissions, wrong workspace). Second, legitimacy gravity: everyone treats the charter as "unofficial" because it isn't in Workday. So the charter becomes a container for vibes.

But here's the thing: Workday was never going to answer these questions anyway. The org chart is usually a system of record for administrative facts: who reports to whom, job titles, headcount. A charter answers operational questions: what this team does, how we make decisions, who owns what work. These are different categories. Waiting for the org chart to clarify your team's scope is like waiting for your birth certificate to tell you what to do with your life.

What I wanted: a charter that is one URL, editable by the team without IT, easy to share across boundaries (contractors, partners, new hires), versioned so updates feel safe, and designed to be the thing you actually point to, instead of a "shadow doc" that defers to some "real" system that will never contain this information.

That's ccccharter.com.

A note on access: charters are public-by-URL but not discoverable. Security by obscurity isn't perfect, but it matches how teams actually share docs; a contractor can read your charter five minutes after you send the link, instead of five days after IT provisions an account. If you want tighter control, you can restrict editing to specific people while keeping view access open. Useful if you want a holacracy-style setup where only the secretary edits, but everyone can always see the current state.

How to use ccccharter.com

You can use the tool two ways: solo drafting or an actual workshop. Workshop is better.

Option A: The 2–3 hour charter workshop (recommended)

Create a new charter at ccccharter.com. Put it on a projector, share the link in the meeting chat. As a group, fill in the team name and mission, 3–6 focus areas, a handful of measures (mix outcomes and behaviors), decision rights (be explicit—this is where teams stop stepping on each other), and roles (real accountabilities, not resume lines). Assign one person to keep the doc real over time. Stewardship even over ownership.

Option B: Solo draft → team review (meh, but still workable)

Draft the first pass yourself. Share the link and ask people to add missing scope, decisions, roles. In the next team meeting, stress-test the charter using real examples: "Does this clarify what we say no to?" "Who decides this?" "Which role owns that?" Save. Revisit monthly or quarterly.

How I'd actually deploy this inside a team: Pin the link in Slack or Teams. Add it to onboarding. Link it from every project kickoff doc. When conflict appears, point to the charter like it's a constitution, because it kind of is. See rule of law (2).

BTW, there's also a Team Guidelines section that supports markdown, which is where I put the stuff that doesn't fit cleanly into decision rights or roles, like norms, rituals, "how we work" prose. It's the closest thing to a team README. All of the roles have little additional detail fields, if you need to add more context.

How it got built: Replit + ChatGPT

I built this working version in Replit, with ChatGPT to help me build technical specs for the things I wanted in the app.

I wrote a PRD and designed screens (clear UX, clear objects, clear constraints). I gave those to ChatGPT, which helped turn those specs into schemas, routes, components, and edge case checklists. I then used Replit to iterate fast, deploy instantly, and share my messy progress with a few friends.

The thing I keep learning about AI-assisted building: it's incredible at acceleration if you're willing to be the editor-in-chief. If you let it drive unsupervised, it will happily build a plausible-looking haunted house. It will build things (like you can see me troubleshooting in the image above) that "work" but don't work work. So you have to stay in the room, and your personal taste for what a thing should look like, feel like, function like ... it really matters.

Replit is also exactly what it should be: a prototype engine. It's great for shipping the first thing. It's not necessarily where you want to live forever if you care about uptime, scale, or private data. The long-term plan is the normal boring grown-up stack: GitHub, real hosting, proper database, proper auth. I'll probably end up using Claude Code for that.

But to get from zero to "it works," Replit + ChatGPT is a cheat code.

What's next: decisions that leave a trail

The feature I'm most excited to build is a proper decision record. Right now charters capture what a team can decide. But they don't capture what the team did decide, or how.

The plan is to build an objection-first decision workflow. Facilitator posts a proposal tied to a specific decision right. Participants join via QR, respond with one of three options (endorse, safe-to-try, objection), and objections require two fields: what will likely go wrong, and what would make it safe. When the facilitator reveals, objections show first, with names attached. Resolve them, record a final decision, and it becomes a permanent entry in the charter's decision history, otherwise known as a team logbook (57).

It's consent-based decision-making with an audit trail. Am still speccing it out, but if that sounds useful, let me know.

Try it, steal it, tell me what breaks

If you want to try the tool, go to ccccharter.com. Make a new one. Give it your email. Make note of the URL.

If you want the deeper pattern language behind it, that's in Hidden Patterns. including the Team Charter chapter and a bunch of other patterns that make charters stick.

And if you have opinions (you do! I know you do!), send them. This tool is early, and I'm building it in public on purpose.

The whole point is to stop letting our org design levers die in slide decks.