How Atlassian builds teams, gets buy-in, and launches new products

Executive overview

Large product orgs default to fear over play — feedback becomes polished, ideas become incremental. Atlassian's Megan Cook rebuilt psychological safety deliberately, then applied the same discipline to buy-in, CSAT investment, and new product launches.

The through-line: start small, expose your thinking early, and make it structurally easy for others to help.

The opposite of play is not work — it is fear, and fear kills bold ideas before they start.

Creating psychological safety and play

• Teams above ~15 PMs stop speaking up organically; formality sets in and feedback arrives pre-polished
• Peer feedback groups: small cross-level cohorts meet every two weeks; someone brings rough-draft work, everyone gives feedback — builds trust through repetition
• Half-yearly on-sites combine fun warm-ups, craft workshops, and senior leaders sharing failure stories
• Failure stories from leadership signal that bold swings are acceptable and celebrated, not just tolerated
• The $10 prioritisation game: list all priorities, distribute $10 across them to expose where time is actually going vs. where it should go
• Flow state requires play; play requires the absence of fear

Remote work practices

• Team Anywhere principle: location is a personal choice, not a perk — focus on how to be productive, not where
• In-person connection boosts productivity and connection by ~30% and the effect lasts months; three to four gatherings a year is sufficient
• Full cross-functional team weeks (engineers, designers, PMs) in a shared office floor replace daily proximity — part working, part workshops, part social
• Async-first: status updates go into Atlas (goal tracker) as written updates, not meetings; decisions and strategies are documented in Confluence
• Video recordings replace many written documents for remote colleagues in different time zones — casual, fast, conveys tone
• Deep work blocks: leadership team syncs calendars to protect two long stretches per week simultaneously; meetings become precious and reserved for problem-solving only
• One-on-ones stay short and punchy; flex time in the calendar handles the ad hoc deep-dives

Getting buy-in

• The mistake: treating buy-in as a single presentation moment where you pitch a perfect proposal and collect approval
• Buy-in is a journey — loop in every affected stakeholder early, with rough ideas, and return repeatedly as designs and data develop
• Stakeholders who are consulted early become advocates in the final decision meeting
• Separate facts from hypotheses explicitly in proposals; presenting "here's what I know, here's what I'm testing" builds more credibility than false certainty
• Executives see ten proposals a day — bring only the data points that help them understand the situation; know the detail so you can go deeper when asked
• Set up the meeting before you present: state whether you want a decision, feedback, or a specific hypothesis challenged — this frames how people listen
• Brief narrative frame: current situation → what changed → implications → problem/opportunity
• Falling in love with a solution blocks you from finding a better one; focus on the value to deliver, not the mechanism

Investing in unpopular but necessary work (CSAT case study)

• CSAT investment is easy to deprioritise because it is not a shiny new feature — but poor usability blocks users from accessing value that already exists
• Evidence stack: qualitative survey feedback with verbatims, customer interviews, usability sessions, and revenue impact modelling (new customer acquisition + expansion)
• Shepherd model for cross-team dependencies: platform teams each nominated a shepherd who reviewed designs and code from the CSAT team rather than bearing full development costs — made alignment achievable without aligning full roadmaps
• Start small to reduce the perceived bet size; show early momentum with regular updates to sustain excitement and investment
• Show, don't tell: before-and-after design walkthroughs and recorded customer sessions created emotional pull that data alone could not
• Dark mode — high coordination cost, high visibility reward — became a proof point for the team's capability

Launching new products at scale

• Signal for a new product: existing customers actively trying to use the product for jobs it was not designed for (non-developers adopting Jira Software → Jira Work Management)
• Internal innovation program: anyone can pitch a new product idea
• Stage-gate model — Wonder → Explore → Make → Impact → Scale:
  • Wonder: one person with an idea
  • Explore: two to three people, prototype, early customers, rough roadmap
  • Make: small full team (~10 people), build and test with customers, find product-market fit
  • Impact: self-sufficient on revenue
  • Scale: full launch
• At each gate, a leader assesses whether to continue, pivot, or kill — killing fast is a feature, not a failure (whiteboard product → Confluence feature)
• Small teams are protected from the processes that govern large products; different quality and scalability standards apply at early stages
• Speed of iteration matters more than polish at Wonder/Explore; learnings from small products can be pulled back into core products

Staying ahead of competition

• Healthy paranoia over arrogance: size does not make a company immune to being disrupted
• Weekly company-wide customer feedback email: random selection of verbatims and ratings — everyone gets a dose, not just the product team
• ShipIt hackathons: company-wide, competitive, surfaces new ideas and cross-team collaboration
• Central AI team predates the ChatGPT wave; when the wave came, a small carved-off team explored applications without disrupting the core roadmap
• Invest in seeding future businesses in parallel with the core, accept that some will be killed and that is expected
• Use your own products heavily — internal dogfooding surfaces real pain fast

Failure corner: the automation opportunity missed

• Built automation in Jira to detect code commits and update ticket status automatically — shipped it as a workflow editor feature
• It worked and users liked it — but the insight was too narrow: automation is not a developer feature, it is a platform capability for every product and user type
• Years later Atlassian acquired a company that had built exactly that; an expensive lesson in thinking too small
• The corrective question to ask of every idea: what would this look like if it were 10x bigger? Where could it go in three to five years, and should that change how we build it now?

Fight Club: structured conflict for leadership teams

• 30-minute weekly session with engineering lead and design lead — scheduled, expected to produce conflict
• Scheduling conflict normalises it: going in knowing there will be disagreement removes the anxiety of raising difficult topics
• Relationships improve because problems surface early, before they compound