Design Research · 08b · The Atlassian Question

A System of Work

"The secret to exceptional outcomes lies in how your teams work together. The Atlassian System of Work provides a blueprint for your organization." Read that twice: a software company is no longer selling software. It is selling doctrine, with software attached. It feels basic. It is basic. And the basics are exactly what will matter. This is the second deeper dive following The Atlassian Question.

What It Is

The System of Work is Atlassian's codified operating philosophy: four pillars, each with named practices underneath.

• Align work to goals. Set only three to five goals per team annually; document them centrally so "everyone can see each other's goals"; share monthly progress.
• Plan and track work together. Write briefs stating "the problem you're solving, your primary audience, the impact you want to drive"; break work into clear tasks with clear owners; establish working agreements; build "reflection points into every project," pre-mortems and retrospectives alike.
• Unleash collective knowledge. Replace meetings with "high-quality written materials and videos"; keep content flagged with clear status ("organized transparency"); and, notably: "put everything online so AI can access it."
• Realize the full power of AI teammates. Build and test custom agents, foster experimentation, and "define clear roles for AI teammates" alongside humans.

Underneath, the pillars map onto their platform: goals in Focus and Jira Align, work in Jira, knowledge in Confluence and Loom, AI teammates in Rovo, all joined by the Teamwork Graph (see the companion note). They attach numbers: 75% project success rates, 35% fewer interruptions, 40% faster time to value.

Why Basic Is Right

Nothing in the list is new. OKRs, briefs, retros, documentation culture: this is decades of management literature compressed into a landing page. Dismissing it on those grounds would miss the two things Atlassian actually got right.

First, the insight underneath the packaging is true: tools don't fix teamwork; shared practice does. Atlassian spent twenty years selling tools and watching them fail in organizations with no shared way of working. The System of Work is their admission that the missing layer was never a feature. That admission is worth more than the four pillars themselves.

Second, the tool can carry the practice. The pillars aren't shipped as a PDF; they're fused into product behavior, defaults, and templates. The practice lives in the shape of the software. This is the move worth studying, and it is worth noticing that Collaboration OS already makes it, more sharply than they do:

• "Plan and track together" is, for us, a planned meeting: the artifact exists before the call, with its engagement, attendees, and intent already declared. The practice isn't recommended; it's how the pipeline works (see Meeting Artifacts).
• "Organized transparency" is Published, Not Leaked: everything private until deliberately promoted, so the calm view is the edited view.
• "Replace meetings with high-quality materials" is the artifact itself: essence, verbatim quotes, decisions, asks, and the recording, produced automatically the moment the meeting ends.
• "Put everything online so AI can access it" is literally the mirror and the pipeline: agents read the project, the studio library, and the pattern language before they act.
• "Define clear roles for AI teammates" is our authorship rule: AI visible as support, never impersonating humans, its text visually distinct from human voice.

The tool is the doctrine. Every affordance is a practice someone no longer has to remember.

Blueprint vs. Pattern Language

Their chosen word gives away the limits: blueprint. A blueprint is one drawing, finished elsewhere, installed top-down, identical for every site. It assumes an organization shaped like their customers: departments, hierarchies, an intact org chart waiting to receive the plan.

There is an older and better idea for this, and it is the one this project is already built on: a pattern language. Patterns are grown rather than installed. Each one names a recurring problem, the forces at play, and a resolution that adapts to context; patterns combine into a language a community actually speaks (see Through the Pattern Language). Where a blueprint says do these four things, a language says here is what we have learned, and why, and when it applies.

The practical version for the studio: the system of work should live in the library as named, written patterns, each with its why and its how, each readable by people and by agents. When an agent drafts an artifact or plans a project, the pattern language is part of its context. That is what "define clear roles for AI teammates" looks like when it's done with a language instead of a blueprint: the agent doesn't just have permissions, it has upbringing.

Moving Beyond: A System of Work Without an Org

The blueprint's addressee is "your organization." Ours often doesn't exist.

Iris is not a traditional studio, and the work is not always for traditional clients. The line between client and team member blurs, on purpose; some future projects won't have a "client" at all. What needs coordinating is a dynamic team of agentic individuals: humans with full agency, gathered around shared work, who may or may not belong to some other organization. Atlassian treats the company as the container of work. We treat the company as one possible shape a team can take, and not the most interesting one.

That changes where the system of work attaches:

• Practices attach to the engagement, not the employer. Working agreements, goals, and rhythms are declared per constellation, and everyone in the constellation sees them, whatever their affiliation.
• Goals are visible to the whole constellation. Atlassian's "everyone can see each other's goals" stops at the tenant wall. Ours can't: when collaborators and clients are the same kind of node, goal visibility follows the relationship (see The Teamwork Graph), governed by publishing, not by employment.
• Onboarding is handing someone the language. A new collaborator, human or agent, joins by reading the patterns: how we meet, how we decide, how we publish, how we ask. Not an employee handbook; a grammar.
• Reflection feeds the library. Their "reflection points" produce retro documents that die in Confluence. Ours should produce patterns: each project's lessons written back into the language, so that projects learn from each other through the very system that coordinates them.

Kept honestly, this is also the answer to "feels basic." The basics are what survive when there is no org chart to lean on. Three to five goals, a brief before the work, decisions written down where they happened, everything published deliberately: a constellation with no shared employer needs these more than a corporation does, because practice is the only structure it has.

Related Notes

• The Atlassian Question — the parent note: a syllabus, not a stack
• The Teamwork Graph — the companion dive: the person is the node
• Collaboration OS Through the Pattern Language — the language this system should be written in
• The Client Dashboard — publishing deliberately as a practice

Sources

• Atlassian System of Work — "a blueprint for your organization"
• System of Work practices — the four pillars in detail