Inside Atlassian’s Developer Experience Overhaul  🔗 **Source:** [Inside Atlassian’s Developer Experience Overhaul](https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul) > [!note]+ Document Notes > --- > tags: [developer-experience, engineering-culture, ai-assisted-development, technical-debt, documentation] > author: Chantal Kapani > source: LeadDev > reference: https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul > date created: 2026-10-01 11:31 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Inside Atlassian's developer experience overhaul > ## 🧭 Table of contents > - [📝 Summary](#-summary) > - [📖 Main content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning styles assessment](#-learning-styles-assessment) > - [📊 Accessibility assessment](#-accessibility-assessment) > - [🌍 DEIB assessment](#-deib-assessment) > - [✅ Logical validity](#-logical-validity) > - [🛡️ DARVO analysis](#️-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > - [🔄 Refactor appendix](#-refactor-appendix--inside-atlassians-developer-experience-overhaul) > ## 📝 Summary > - **What happened.** LeadDev published an interview-based feature on 2026-10-01 in its Culture section, part of a series where staff writer Chantal Kapani "sits down with the people behind the scenes" of engineering cultures (¶0). The interviewee is Andrew Boyagi, customer CTO at Atlassian (¶6). The captured text is about 562 words in 25 paragraphs. The byline is not a separate field in the capture. ¶0 names the series writer, and the link list has a LeadDev author-profile link for the same name, so this analysis credits Chantal Kapani as author. > - **The claim.** Atlassian improves developer experience by asking developers what's broken before buying tools (¶2, ¶5), protecting 10% of developer time for developer-experience work (¶3, ¶11), and using AI agents to cut review and security toil (¶4, ¶21, ¶22). > - **Genre.** This is an interview feature with one source, not a study. Every claim about what Atlassian does and what its AI produces comes from the interviewee, who speaks for Atlassian about Atlassian's own practices. > - **Three figures, all self-reported and unverified.** (1) 10% of developers' time for developer-experience work (¶3, ¶11). (2) 45% faster pull-request cycles from AI agents (¶4, ¶21). (3) 51% of vulnerabilities auto-resolved (¶4, ¶22). The article doesn't give how each is measured, the time period, the team scope, the definition of "resolved", a baseline, or any independent data. > - **Commercial interests.** The interviewee represents Atlassian, and ¶18 says the company builds AI-first products, so the AI figures also describe the company's own product direction. Per the task metadata, LeadDev sells events. The captured text carries no disclosure statement on either relationship. > - **Why it matters for DevRel and docs work.** ¶14 lists outdated documentation next to build times and technical debt as a cause of developer friction. That's one sentence of support for treating docs as developer-experience infrastructure, not a finding with data behind it. > - **Key stakeholders.** Atlassian engineers, engineering leaders choosing tools, platform and developer-experience teams, and readers of LeadDev. > - **Risks and tradeoffs.** The piece reads as a success story. It contains no failure, cost, opt-out rate or dissenting voice, and no figure is tied to a method. Copying the 10% policy or the AI claims on the strength of this article would be copying an unverified number. > - **Capture notes.** The "Key takeaways" block (¶1-¶4) is a three-bullet summary written by the publication. It restates ¶11, ¶21 and ¶22 as flat statements ("AI is already cutting friction"), where the body attributes the AI figures to Boyagi (¶21) or leaves them unattributed (¶22). > - **Bottom line.** The asking-first principle (¶5, ¶8) and the protected-time idea (¶15) are sound and cheap. The three numbers are marketing-adjacent claims until someone shows the measurement. > ## 📖 Main content > **The core argument.** Engineering leaders are tempted to buy the latest tools to improve developer experience (¶5). Atlassian's approach, as the interviewee describes it, starts with developers: "run good surveys" (¶8) to find the bottlenecks and pain points, then respond. The interviewee says many companies fail at exactly this step (¶6). > **What developer experience is for.** Boyagi says its strategic value lies in efficiency and effectiveness, with employee happiness a side benefit (¶7). The writer's gloss (¶10) is that it means reducing organizational friction so engineers spend time on meaningful, high-quality work. > **Protected time.** Atlassian gives developers the opportunity to spend 10% of their time improving their own developer experience (¶11). The stated reason (¶12, ¶15) is structural: if improvement work isn't scheduled, it competes with feature development and operations and loses. The interviewee frames the benefit as space and time, not permission (¶16). > **Friction sources named.** Build times, outdated documentation, technical debt and inefficient processes (¶14), plus time lost searching for information, navigating unnecessary processes and working around bottlenecks (¶14). > **AI as friction removal.** The interviewee says that to build AI-first products, Atlassian became an AI-first engineering organization (¶19). Engineers get access to leading AI tools and room to experiment through initiatives such as a hackathon (¶20). Two outcomes are reported: > | Claim | Where | Who says it | How it's described | What the article doesn't give | > |---|---|---|---|---| > | 10% of developers' time for developer-experience work | ¶3, ¶11 | Takeaways block (¶3) and the interviewee's account (¶11) | "scheduled specifically for" build times, docs, technical debt (¶3); "the opportunity to spend" the time (¶11) | Whether time is mandatory or optional, how many developers use it, how it's tracked, over what period, any outcome from it | > | 45% faster pull-request cycles from AI agents | ¶4, ¶21 | Boyagi, "has seen" it (¶21) | AI agents reduce "pull request cycle times by 45%" | Metric definition (open-to-merge? review wait?), baseline period, which teams, which agents, sample size, whether quality changed | > | 51% of vulnerabilities auto-resolved | ¶4, ¶22 | Not attributed in ¶22; takeaways block (¶4) | "automatically resolving 51% of potential vulnerabilities" (¶22) | What "resolved" means (patched, closed, suppressed, merged), severity mix, false-positive rate, human review, period, source scanner | > **Wording drift to watch.** ¶3 says the 10% is "scheduled specifically for" three problem areas. ¶11 says developers have "the opportunity" to spend 10% improving their own developer experience. Those are different policies (a block of calendar time versus a permission). ¶4 says "51% of security vulnerabilities auto-resolved." ¶22 says 51% of "potential vulnerabilities." A potential vulnerability and a confirmed one are different denominators. > **Closing claim.** The value of these approaches, the writer says, is that they remove repetitive or frustrating work, not only that they make developers faster (¶24). That's a framing claim, not a measured one. > **Contested or unverified.** (1) All three figures, as above. (2) That asking developers first is why Atlassian's results are good: the article shows no comparison with companies that don't ask. (3) That the 10% time produces the AI gains: the article places them in separate sections and doesn't connect them. (4) "No developer likes resolving security vulnerabilities" (¶23) is a generalization from one person. > ## 🗒️ Notes > #### 📄 ¶0-¶4 Series note and key takeaways > - ¶0 is the series blurb: staff writer Chantal Kapani interviews the people behind engineering cultures. > - ¶1 is the "Key takeaways:" heading. ¶2-¶4 are the three bullets, written by the publication, not quoted fro [](https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul)[Article hero – Encouraging a culture of developer productivity](https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul) *In this series, staff writer [Chantal Kapani](https://leaddev.com/community/chantal-kapani) sits down with the people behind the scenes to explore what makes their engineering culture tick.* **Key takeaways:** * Atlassian starts by **asking developers what’s broken**, not by buying the latest tool. * 10% of developers’ time is scheduled specifically for fixing build times, docs, and technical debt. * **AI is already cutting friction:** 45% faster PR cycles and 51% of security vulnerabilities auto-resolved. It is tempting for [engineering leaders](https://leaddev.com/the-engineering-leadership-report-2026/) to implement the latest tools on the market in the hope that they will improve developer experience. Atlassian’s approach is different – start by asking developers what [bottlenecks and pain points](https://leaddev.com/velocity/recognizing-and-removing-project-bottlenecks) they are facing first, and then respond appropriately. “Where I see a lot of companies fail is they don’t ask their developers what needs to be improved,” Andrew Boyagi, customer CTO at Atlassian, tells LeadDev. While [developer experience](https://leaddev.com/reporting/metrics-measure-developer-experience) can contribute to employee happiness, its strategic value lies in helping teams work more efficiently and effectively, Boyagi says. “Speak to your developers, run good surveys, so you can understand what the actual challenges are. If this is about improving developer experience, it must be about removing friction for developers,” Boyagi says. #### Removing friction for developers At Atlassian, improving the [developer experience](https://leaddev.com/technical-direction/how-better-developer-experience-drives-results) means reducing the organizational friction that prevents engineers from spending their time on meaningful, high-quality work. One way the company does this is by giving developers the opportunity to spend 10% of their time improving their own developer experience. Boyagi sees that dedicated time as an important part of the approach: rather than treating improvements to the engineering environment as something developers have to fit around their existing responsibilities, it’s built into the schedule as its own priority. “Developers can do the work that they want to do that’s meaningful, that’s high quality, with minimal organizational friction. Deciding what to build, building it, and operating it,” explains Boyagi. At Atlassian, developer friction often stems from build times, outdated documentation, [technical debt](https://leaddev.com/technical-direction/tech-debt-traps-avoid), and inefficient processes. Developers can also lose time searching for information, navigating unnecessary processes, and working around organizational bottlenecks. Giving engineers time to address those problems is crucial, Boyagi argues. Otherwise, improving the way they work simply becomes another task competing with feature development and operational responsibilities. It is not about giving engineers permission to make positive changes. “It’s more about giving them the space and the time to do it.” #### Being AI-first [AI](https://leaddev.com/ai/best-ai-coding-assistants) fits naturally into Atlassian’s wider approach to improving how developers work. As the firm began building AI-first products, it also had to rethink how its own engineering organization worked. “To build AI-first products, we had to become an AI-first engineering organization ourselves,” explains Boyagi. Atlassian gives engineers access to leading [AI tools](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) and the freedom to experiment through initiatives such as its hackathon. AI is already being used to tackle some of the more time-consuming friction points in the development process. Boyagi says the company has seen [AI agents](https://leaddev.com/technical-direction/how-to-prepare-for-ai-agents) reduce pull request cycle times by 45% – addressing what he describes as a key pain point for developers. AI is also being used to take on [security work](https://leaddev.com/culture/why-security-everyones-responsibility), automatically resolving 51% of potential vulnerabilities. NYC 27 Pre sale ticket block image “No developer likes resolving security vulnerabilities,” Boyagi says. The value of these approaches is not simply that they make developers faster. They also remove some of the repetitive or frustrating work that can get in the way of higher-value engineering., Inside Atlassian’s Developer Experience Overhaul, Chantal Kapani, 01m3w1dxggs31nsbdyb2espd3j.