Daniel Brunsdon

The problem

By 2019, Twitter's developer platform had a communication problem that looked like a content problem. Three API tiers — Standard, Premium, Enterprise — each with their own docs, their own terminology, their own navigation patterns. Developers couldn't find what they needed. Internal teams were duplicating work across hundreds of endpoints.

I was hired as a program manager in DevRel, which at Twitter meant something specific: you don't own one function, you own the connective tissue between functions. My job was to sit across product, engineering, marketing, and design — understand what each team was building — and piece together a unified strategy for how the platform showed up to the outside world.

The diagnosis

The docs weren't broken because the writing was bad. They were broken because nobody had made the structural decisions. Six content types applied inconsistently across hundreds of endpoints. Guides that had become dumping grounds. Tutorials that overlapped with onboarding flows. FAQs scattered everywhere with no ownership. The API Reference Index — 592K visits in a single quarter — was an incomplete list of links that didn't even include the newest endpoints.

The diagnosis was architectural, not editorial. So the intervention was architectural.

The redesign

I designed a new content framework that gave every endpoint a consistent progression: Introduction, Quick Start, Integrate, Migrate, API Reference. Each type had a clear purpose, clear boundaries, and clear rules for edge cases. FAQs were killed as a content type entirely — the same information got surfaced as contextual callouts where developers actually hit the confusion.

Then I built the templates that encoded the architecture. This was the strategic move. Content types are a design decision; templates are an operational decision. By embedding every structural choice into the authorship process itself, the system held up without me reviewing every page. Authorship time dropped 40%. New contributor onboarding dropped 75%.

Finally, I redesigned the high-level IA to organize around APIs rather than the legacy product-noun structure. Benchmarked against Stripe, Twilio, Pinterest, and Google. Proposed the single-page anchor-link model that eliminated duplicative content across the old tabbed navigation.

The results

5.9M developers served annually through the new architecture. 14% lift in satisfaction scores. An IA model that other teams at Twitter adopted for their own documentation.

The role required deep partnership with product (what are we building and why), marketing (how do we position it), design (how do developers navigate it), and engineering (what's technically feasible). The value wasn't in any one deliverable — it was in seeing the structural problem underneath the surface symptoms and building a system that held up without me in the room.

The takeaway

Most platform teams treat documentation as a writing problem. It's an architecture problem. When six content types are applied inconsistently across hundreds of endpoints, better writing doesn't help — you need someone to make the structural decisions nobody else is making, encode them into templates so the system self-enforces, and coordinate across every team that touches the developer experience.