Atlassian Company Culture: Inside the Team Anywhere Philosophy

Most companies that went remote in 2020 spent the next few years trying to walk it back. Atlassian went the other direction. It shut its 12 offices like everyone else, watched the world start negotiating its way back to five-day-a-week attendance, and then built an entire operating system around never going back. That system is called Team Anywhere, and it’s the clearest window into what Atlassian company culture actually looks like once you get past the values poster in the lobby.

What’s interesting about Atlassian isn’t that it lets people work from home. Plenty of companies do that badly. It’s that Atlassian treats culture the same way it treats software: something you measure, test, and ship improvements to. That approach shows up in four places worth digging into – how the company handles distributed work, how it protects psychological safety, how it tracks team health, and how its engineering culture turns values into daily habits.

Distributed Workforce: From 12 Offices to 10,000+ Locations

Team Anywhere launched in mid-2020 as a policy letting employees choose where they work, provided Atlassian has a legal entity there, the time zone works for their role, and their team leads sign off. Nearly five years later, a workforce once anchored to 12 buildings now logs in from more than 10,000 locations worldwide. That’s not a talking point – it’s a genuine operational shift, and it forced Atlassian to rebuild how teams are structured, staffed, and supported.

A few specifics make this concrete:

• Time zones over zip codes: Instead of grouping people by office, Atlassian’s research arm – the Team Anywhere Lab – pushed teams to organize around time-zone overlap, generally keeping people within two zones of each other so there are at least four hours of shared working hours.
• Async by default: Meetings are the exception, not the starting point. Written documentation and recorded video updates (via Loom) carry most of the coordination load, which matters when your teammate might be asleep for half your workday.
• Open by default: Most internal documents live where any employee can find them. This isn’t a courtesy; it’s a requirement when nobody can just walk over and ask.
• Intentional in-person gatherings: Atlassian’s own research found that planned team gatherings boost collaboration for four to five months afterward – longer than the effect of routine office attendance. So instead of mandating office days, the company funds periodic in-person meetups, internally called Intentional Together Gatherings.
• 90 days of flexibility abroad: Employees can work from another country for up to 90 days a year without it becoming a tax or legal headache, which is a small detail that employees consistently cite as meaningfully improving quality of life.

The results Atlassian has published are hard to dismiss: roughly 92% of employees say the policy lets them do their best work, and 91% say flexibility is a major reason they stay. The workforce has roughly tripled since the policy began, and job applications have more than doubled. None of that proves distributed work is right for every company. It does show that when the infrastructure and norms around distributed work are actually built out – not just permitted – it can hold up at scale.

Psychological Safety: The Part Most Companies Skip

Distributed work exposes weak psychological safety fast. When you can’t read a room, half-hearted “sounds good” reactions in a chat thread can hide real disagreement for weeks. Atlassian’s answer isn’t a training module – it’s baked into how the company defines its own values, starting with “Open company, no bullshit.”

That value sounds like a slogan until you look at how literally it gets applied. Employees knew the company was heading toward an IPO months before the filing. When Atlassian sold its chat products to a direct competitor, the whole company found out days before the public did. The logic, according to company leadership, is that trust erodes faster from information hoarding than from occasionally uncomfortable transparency.

Psychological safety also shows up as a design constraint in how Atlassian approaches engineering practices, not just as an HR talking point. In its own guidance on building a DevOps culture, the company explicitly names psychological safety and role clarity as the two ingredients teams need before they can move fast without falling apart. Skip either one, the reasoning goes, and teams either stop taking risks or keep making the same mistakes without learning from them.

For readers trying to build this in their own organizations, the honest caveat is that psychological safety is hard to mandate from above. It’s set largely by how managers respond the first time someone admits a mistake or pushes back on a decision. Atlassian’s contribution isn’t a magic fix for that – it’s a structural nudge, through open documentation and quarterly self-assessment, that makes it harder for problems to stay hidden.

Team Health: Treating Teams Like Something You Can Diagnose

This is where Atlassian’s product background bleeds into its culture in an unusually direct way. The company built a tool called the Team Health Monitor – free, publicly available, and used both internally and by outside teams – that asks a group to rate itself against eight attributes every quarter: team cohesion, having the right people in the right roles, shared understanding of goals, clear ways of working, value creation, support from the wider organization, suitable metrics, and continuous improvement.

It’s a self-assessment, not a survey imposed from HR. A facilitator runs a 90-minute session, the team scores each attribute red, yellow, or green, and then the group picks one or two areas to actually work on – deliberately not all eight at once, since trying to fix everything simultaneously usually means fixing nothing. Follow-up happens two to four weeks later to check whether things moved.

Why does this matter more for distributed teams specifically? Because the usual early-warning signs of a struggling team – someone going quiet in meetings, visible frustration in a hallway conversation – don’t exist when your team is scattered across ten time zones. 

A structured, recurring health check replaces the ambient signals that in-person teams pick up without trying. Atlassian isn’t claiming the tool is a cure-all; its own guidance is blunt: a team gets out of the exercise exactly what it puts in, and treating it as a box-ticking formality defeats the purpose entirely.

Engineering Culture: Where the Values Actually Get Tested

Atlassian’s five stated values are informal by design: Open company, no bullshit. Build with heart and balance. Don’t screw the customer. Play, as a team. Be the change you seek. Values statements are cheap, though – what makes them worth writing about is the mechanism Atlassian built to make engineers actually live them: ShipIt Days.

Started in 2005 (originally called FedEx Days, renamed after a trademark dispute), ShipIt gives every employee 24 hours, roughly once a quarter, to build anything they want with anyone they want. 

The only rule is that it has to ship- a working demo, presented to the company, by the deadline. This isn’t a side activity that gets waved off as “innovation theater.” Jira Service Management, now one of Atlassian’s fastest-growing products, started life as a ShipIt project. So did other features that quietly became part of the core product line.

The reason this counts as engineering culture rather than a company perk is what it signals structurally: that people closest to the code are trusted to notice problems and build solutions without waiting for a roadmap to catch up. 

Combined with the “open by default” documentation norm and a genuinely blunt internal communication style, engineers get unusually direct access to context most companies would keep behind a management layer. 

That’s a real trade-off – it requires trusting people with information that could leak or be misused – and Atlassian’s leadership has been candid that the payoff, in their view, comes from faster, better-informed decisions rather than from the openness itself being a virtue.

What Other Companies Can Actually Take From This

A few patterns are worth lifting even if your organization has no interest in going fully distributed:

1. Measure the thing you care about: “Team health” and “psychological safety” stay vague until you turn them into a repeatable check-in with real questions attached.
2. Build the infrastructure before the policy: Letting people work anywhere without redesigning how teams are staffed across time zones just moves the friction somewhere else.
3. Give autonomy a deadline, not just permission: ShipIt works because it’s bounded-24 hours forces action rather than endless planning.
4. Openness has to survive uncomfortable moments: A transparency culture that only holds up when the news is good isn’t really a culture; it’s a marketing line.

Atlassian company culture isn’t perfect, and the company says as much in its own public reporting – diversity progress, for instance, is something it has openly admitted is still a work in progress rather than a solved problem. 

But the Team Anywhere philosophy is one of the more thoroughly documented, data-backed attempts by a large company to answer a question most organizations are still guessing at: what does distributed work actually require to work well, beyond just turning cameras off and calling it flexibility?