01The problem
Media, legal, growth, narrative and a dozen other teams all depended on each other. A video couldn't go out before legal had seen it; a growth push needed the narrative team's lines first. The rules for those handoffs weren't written down in one place, so the only way to learn them was to ask the right person.
My brief was to write it all down in a form people would actually use.
02The map
Every team page lists who it depends on and who depends on it. Put together, that's a network of 100+ coordination edges.
03What I built
- 16 team pages, 80+ workflows written as standard SOPs across media, legal, growth and narrative.
- A glossary and a coordination-edge schema in the data layer, so each page can show its dependencies without anyone maintaining that list by hand.
- A "journey bullets" format for each team's story, so all 16 pages read the same way and a new lead knows where to look.
- The SMCC playbook: 11 chapters on running hyperlocal digital operations across 280+ assembly segments.
- All of it as a static web app, 5,700+ lines, with no server to run.
04Three weeks to sign-off
Sixteen teams reviewing one after another would have taken months. So the interviews with subject experts ran in parallel, and review happened asynchronously: each team's SOPs lived in markdown in a GitHub repo, experts commented on the draft, and every change had an owner and a history.
One template for every author. Once all 16 teams were writing into the same shape, reviewing got faster with each team instead of slower.
05Decisions
D1Markdown and GitHub reviews instead of shared docs
Versioned, reviewable, and easy to turn into web pages. Every SOP change could be traced to a person and a date.
Trade-offLess familiar than a shared document for non-engineers, so the review flow had to be kept simple.
D2Model the handoffs as data, not prose
The coordination edges live in a schema, and the pages are generated from it. Change a dependency once and every page that mentions it updates.
Trade-offMore modelling up front, before the first page looked finished.
D3Gate it first, then make it quick to update
The handbook is internal, so it went behind Netlify Identity, with login for 50+ team leads. Later I moved it to a GitHub Pages mirror, which halved the time it took for updates to reach stakeholders.
06Results
07Under the hood
What I designed or built myself:
- app 5,700+ lines of static HTML, CSS and JavaScript. No server, no build step.
- data A glossary and a coordination-edge schema; all 16 team pages render their dependencies from it.
- content The journey-bullets format, which renders each team's story the same way on every page.
- auth Netlify Identity with redirects, protecting the handbook for 50+ team leads.
- deploy A GitHub Pages mirror that halved the time for updates to reach stakeholders.
- workflow SOPs kept as markdown in a GitHub repo, with every change reviewed there.
08Looking back
Documentation goes stale the week after launch unless someone owns it. If I ran this again, I'd name an owner inside each team on day one and give them a monthly review in the same GitHub flow, so the handbook stays as current as the day it locked.