Teamwork Graph Developer Experience
How I built a developer experience from 0 → 1, enabling third-party developers to build AI-powered apps that serve 200,000+ users.
Tools + Tech
Figma
Cursor
Markdown
Teamwork Graph is Atlassian’s unified data layer that powers Rovo, its AI platform.
For Atlassian to achieve their ambitious AI goals, we needed external developers and partners to be able to build on top of this platform — to add data to the graph by building custom connectors, and access data in the graph via an API.
While Atlassian had built the technical infrastructure to make this possible, what they didn’t have was a cohesive developer experience that made building on this feel possible to our users.
There were internal engineering specs but no strategy, no information architecture, and no shared narrative across the 5 teams who had built it.
And the technology itself — graph databases, a custom object and relationship model, two entirely distinct integration paths, complex permissions systems — was genuinely hard to understand without someone who had taken the time to learn it end to end. That is where I came in.
I ran discovery across the teams to understand the technology deeply enough to make strategic decisions — not just document what engineers handed me, but build a cohesive developer experience.
- 1
Learned the technology end to end. Understood graph data models, Cypher and GraphQL query languages, and the object and relationship type system that are key to building with Teamwork Graph.
- 2
Ran workshops with 5+ engineering teams to build shared developer personas and map the end-to-end developer journey, aligning 4 PMs and 2 Heads of Engineering who had never had a common language for the developer experience.
- 3
Made the strategic IA call to structure the docs around two distinct integration paths — API querying and connector ingestion — reflecting the two fundamentally different mental models a developer brings to the product.
- 4
Prototyped and iterated on the full information architecture, designing the conceptual-first, task-branching structure the docs follow.
- 5
Led 10 engineers across 5+ teams to produce and review 250+ pages against the strategy.
- 6
Established reusable content patterns and automated future generation so the content strategy scales as the product grows, beyond my direct involvement.
Clear building blocks for using Teamwork Graph in Forge apps (what data they can get, how to call it).
High-quality self-help resources – short docs, code samples, and error messages that make it easy to fix problems on their own.
Reliable behaviour over time – few surprises, and clear notice when something will change or break.
Easy first steps – simple examples and templates that help them build their first Teamwork Graph app on Forge quickly.
Real-world examples that show how to solve everyday problems at their company (e.g. seeing related work, team activity).
Basic troubleshooting help – clear errors and simple tools so they can see what went wrong and fix it without deep platform knowledge.
In the first 3 months of the early access program, we had 50+ developers onboarded, building apps serving over 200,000 users.
Additionally, the 8,000 page views during the early access program were distributed across overview, conceptual, and reference pages, indicating that developers were moving through the IA as designed, using it as an end-to-end guide rather than landing on a single page and leaving.
The content patterns I established were codified and partially automated, so future documentation can be generated and maintained consistently without starting from scratch. The strategy continues to scale even as the product grows and teams change.