Inside Atlassian’s Developer Experience Overhaul ![rw-book-cover](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,w_1280,h_720/next/2024/07/Encouraging-a-culture-of-developer-productivity-2.png) 🔗 **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 > <!-- deep-read:sections start --> ## 🧭 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 from the interviewee. - ¶2: Atlassian starts by asking developers what's broken, not by buying the latest tool. - ¶3: 10% of developers' time is scheduled for build times, docs and technical debt. ¶4: 45% faster PR cycles and 51% of security vulnerabilities auto-resolved. Both are Atlassian's self-reported figures. #### 📄 ¶5-¶8 Ask developers first - ¶5 frames the temptation to buy the latest tools and contrasts Atlassian's approach: ask about bottlenecks and pain points, then respond. - ¶6: Boyagi says many companies fail because they don't ask developers what needs to improve. - ¶7: developer experience can raise happiness, but its strategic value is efficiency and effectiveness. - ¶8: run surveys to find the real challenges. The goal is removing friction for developers. No survey design, response rate or finding is given. #### 📄 ¶9-¶16 Removing friction and protected time - ¶9 is a section heading, "Removing friction for developers." - ¶10: at Atlassian, improving developer experience means reducing organizational friction that keeps engineers from meaningful, high-quality work. - ¶11-¶12: developers can spend 10% of their time on their own developer experience. Boyagi sees the dedicated time as a built-in priority, not something to fit around existing work. - ¶13: Boyagi describes the goal as meaningful, high-quality work with minimal organizational friction across deciding what to build, building and operating it. - ¶14: friction sources are build times, outdated documentation, technical debt and inefficient processes, plus time lost searching for information and working around bottlenecks. - ¶15-¶16: without dedicated time, improvement competes with features and operations. The interviewee says it's about giving space and time, not permission. #### 📄 ¶17-¶24 Being AI-first - ¶17 is a section heading, "Being AI-first." - ¶18-¶19: as Atlassian built AI-first products, it rethought its own engineering organization. Boyagi: to build AI-first products, the company had to become an AI-first engineering organization. - ¶20: engineers get access to leading AI tools and freedom to experiment through initiatives such as a hackathon. No tool names or usage numbers. - ¶21: Boyagi says AI agents cut pull-request cycle times by 45%, which the interviewee calls a key developer pain point. - ¶22-¶23: AI resolves 51% of potential vulnerabilities automatically. Boyagi: no developer likes resolving security vulnerabilities. - ¶24: the writer closes by saying the value is removing repetitive or frustrating work, not only speed. ## 📚 References The captured link list has 12 entries. All 12 point to leaddev.com pages. None points to an Atlassian source, a dataset, a survey, an engineering blog post or any independent study, so none is a primary source for the 10%, 45% or 51% figures. The link list gives anchor text and URL but not the paragraph position, so each placement below is inferred from where the anchor phrase appears in the text. What each linked page says wasn't checked because nothing was fetched. **Links that point to LeadDev's own content, matched to phrases in the text** - [engineering leaders](https://leaddev.com/the-engineering-leadership-report-2026/) matches the phrase in ¶5 ("tempting for engineering leaders"). It is a LeadDev report page. The text doesn't say it supports any claim in the article. - [bottlenecks and pain points](https://leaddev.com/velocity/recognizing-and-removing-project-bottlenecks) matches ¶5. It is a LeadDev article on project bottlenecks. - [developer experience](https://leaddev.com/reporting/metrics-measure-developer-experience) and [developer experience](https://leaddev.com/technical-direction/how-better-developer-experience-drives-results) are two links with the same anchor text, one about measuring developer experience and one about its results. The list doesn't say which paragraph each sits in. Both are LeadDev articles, not evidence about Atlassian. - [technical debt](https://leaddev.com/technical-direction/tech-debt-traps-avoid) matches ¶3 or ¶14. It is a LeadDev article on avoiding tech-debt traps. - [AI](https://leaddev.com/ai/best-ai-coding-assistants) is a LeadDev comparison of AI coding assistants. [AI tools](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) is a LeadDev buying checklist for AI coding tools. These two are commercially adjacent to the AI claims in ¶4 and ¶20, and the text doesn't disclose any relationship. - [AI agents](https://leaddev.com/technical-direction/how-to-prepare-for-ai-agents) matches ¶21. It is a LeadDev guide to preparing for AI agents, not data on Atlassian's agents. - [security work](https://leaddev.com/culture/why-security-everyones-responsibility) matches ¶22. It is a LeadDev article on security as shared responsibility, not data on the 51% figure. **Author and navigation links** - [Chantal Kapani](https://leaddev.com/community/chantal-kapani) is a LeadDev author-profile link. It supports the author credit. - An empty anchor and [Article hero – Encouraging a culture of developer productivity](https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul) both point back to the article's own URL. They read as hero-image or breadcrumb markup. **Claims with no matching link in the captured markup** - The 10% of developers' time policy (¶3, ¶11). - The 45% faster pull-request cycles (¶4, ¶21). - The 51% of vulnerabilities auto-resolved (¶4, ¶22). - That asking developers first explains Atlassian's results (¶5, ¶6). - Atlassian's hackathon and AI tool access (¶20). **Also relevant** - [Article URL](https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul), published 2026-10-01. - The interviewee is named in ¶6 as Andrew Boyagi, customer CTO at Atlassian. The capture has no link for the interviewee or for Atlassian. ## 🗣️ Paraphrase Atlassian says the first step in improving developer experience is to ask developers what slows them down, using surveys, before buying tools. According to the company's customer CTO, it then protects 10% of developers' time so they can fix their own environment: slow builds, stale documentation, technical debt and clumsy processes. The reasoning is that improvement work loses to feature deadlines unless it has scheduled time. The second half of the piece covers AI. The interviewee says Atlassian became AI-first internally because it builds AI-first products, gives engineers AI tools and a hackathon to experiment with, and has seen AI agents cut pull-request cycle times by 45% and automatically resolve 51% of potential vulnerabilities. The article reports these numbers without saying how they were measured, over what period, or for which teams. ## 📰 Newsletter **Ask first, then schedule the fix.** LeadDev's latest interview feature, with Atlassian's customer CTO, makes a simple case: run developer surveys, find what's slowing people down, and put the repair work on the calendar. Atlassian says it reserves 10% of developer time for this, and it lists outdated documentation next to build times and technical debt as friction sources. The article also reports 45% faster pull-request cycles and 51% of vulnerabilities auto-resolved from AI agents. Those are the interviewee's self-reported figures with no method, period or baseline given, so treat them as claims to test, not benchmarks. For docs and DevRel teams, the usable part is the principle: documentation is developer friction, and fixing it needs protected time. Link: [the article](https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul). ## ✅ Action items Only items the text supports are listed. Where the text has nothing specific, the line says so. #### DevRel - Developer advocacy: before building new content or tooling, run a short developer survey on what slows people down, per ¶8. Report the results with the question wording and response count, which this article doesn't do. - Education: no direct action from this source. Nearest relevance: ¶14 names time lost searching for information as friction, which workshops can address with a "where do I look first" map. - Developer experience: audit onboarding paths for the four friction sources in ¶14 (build time, documentation, debt, process) and log which ones DevRel can fix directly. - Developer marketing: don't cite the 10%, 45% or 51% figures as industry benchmarks. Cite them as "Atlassian's customer CTO told LeadDev" with the date, and note that no method was published. - Community management: no direct action from this source. - Internal/external: propose a protected block of team time for developer-experience fixes, modeled on ¶11-¶12, and report what it produced instead of copying the 10% figure. #### OSPO - Policy and governance: no direct action from this source. Nearest relevance: ¶15 argues improvement work needs scheduled time, which applies to maintainer-experience work. - License compliance: no direct action from this source. - Security management: no direct action from this source. Nearest relevance: ¶22 reports automated vulnerability resolution, and any adoption would need a definition of "resolved" first. - Software inventory: no direct action from this source. - Developer support: no direct action from this source. - Community engagement: no direct action from this source. - Strategic alignment: no direct action from this source. #### Community - Maintainers: ask contributors what slows them down (¶8) before adding new tooling to a project. - Contributors: no direct action from this source. - Sponsors: no direct action from this source. - Ecosystem: no direct action from this source. #### WordPress - Core: no direct action from this source. Nearest relevance: ¶14 lists build times as friction, which maps to local-environment setup time for new contributors. - Core Performance: no direct action from this source. - Core AI: no direct action from this source. Nearest relevance: if AI is used to speed up review (¶21), define the metric before claiming a gain. - **Core Program Team:** no direct action from this source. - Mobile: no direct action from this source. - Playground: no direct action from this source. Nearest relevance: setup time is a build-time-style friction point. - Community: no direct action from this source. - Training: no direct action from this source. - Marketing: no direct action from this source. - Support: no direct action from this source. - Design: no direct action from this source. - Documentation: treat outdated documentation as a friction source (¶14). Run a short survey of contributors on which handbook pages are stale or missing, then schedule fix time. - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source. - Accessibility: no direct action from this source. - Meta: no direct action from this source. - CLI: no direct action from this source. - Hosting: no direct action from this source. - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: no direct action from this source. - Plugins: no direct action from this source. #### The WPOCC - Programs: no direct action from this source. - Projects: no direct action from this source. - Funding experiments: no direct action from this source. Nearest relevance: a small grant to measure the effect of protected maintenance time would produce the data this article lacks. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. - Productized governance artifacts: no direct action from this source. ## 🧪 Hypotheses 1. A team that reserves 10% of developer time for developer-experience work shortens median onboarding time (first merged change) by at least 20% within two quarters, compared with a matched team that doesn't. 2. Developers who are surveyed first and then see a fix tied to their feedback rate their tooling satisfaction higher after one quarter than developers who get the same fix without a survey. 3. Replacing or updating the 10 most-visited outdated documentation pages reduces the count of related support questions by at least 25% in the following 60 days. 4. AI agents that pre-review pull requests cut median open-to-merge time on a fixed repository, and the cut shrinks when measured on merged changes that later need a revert. 5. An auto-resolve rate of about 50% for vulnerabilities falls sharply when "resolved" requires a human-verified fix and passing tests instead of a closed ticket. 6. Companies that run developer surveys before tool purchases abandon fewer tools within 12 months than companies that don't. ## 📊 Methodology - **H1.** Pick two comparable teams. Give one a calendar-blocked 10% for six months. Measure median days from hire to first merged change, build time and survey-reported friction. Pre-register the metrics and report the policy's uptake rate. - **H2.** Randomize 40 developers into survey-then-fix and fix-only arms. Use the same 5-item tooling satisfaction scale before and after. Report effect sizes with confidence intervals. - **H3.** Rank pages by traffic, fix the top 10, and compare tagged support questions for 60 days before and after, with a set of unfixed pages as the comparison. - **H4.** Use repository timestamps for open-to-merge and review-wait time, with AI-enabled and AI-free weeks for the same repositories. Track reverts within 14 days as a quality check. - **H5.** Sample 200 closed vulnerabilities. Two reviewers classify each as verified fix, suppressed, duplicate or false positive. Report agreement and the share in each class. - **H6.** Survey 30 companies on purchase process and track tool retention at 12 months, controlling for company size. - **Controls throughout.** Stratify by team size and tenure, record tool versions, and avoid counting self-selected volunteers as the whole population. ## ❓ Questions - How is the 10% of developer time scheduled and tracked, and is it mandatory or an opportunity (¶3 versus ¶11)? - What exactly does "45% faster PR cycles" measure, over which period and baseline? - What does "resolved" mean in "51% of potential vulnerabilities" (¶22), and how does "potential" differ from the "security vulnerabilities" wording in ¶4? - Did code quality, revert rate or reviewer workload change when AI agents cut cycle time? - What did the developer surveys at Atlassian find, and what changed because of them (¶8)? - Does the 10% apply to all engineers or only some teams, and who decides how to spend it? - Does outdated documentation (¶14) get its own owner and time, or does it share the 10% with build times and debt? - What would count as evidence that this approach failed, and did the interviewee describe anything that didn't work? ## 🔮 Future research - **Independent measurement.** An outside study of protected developer-experience time with a published method would test the 10% claim. - **Metric definitions.** Public definitions for PR cycle time and for "resolved" in automated vulnerability work would let companies compare numbers. - **Docs as friction.** ¶14 names outdated documentation, and no data in the source ties documentation currency to developer speed. A before/after study of doc fixes would fill that gap. - **AI and quality.** Whether faster pull-request cycles hold up on defect and revert rates (¶21). - **Survey practice.** Which developer-survey designs identify real bottlenecks and which produce noise (¶8). ## 💡 Implications - **Practice.** Schedule developer-experience work as its own priority, or it competes with feature work and loses (¶15). Ask developers before choosing a fix (¶8). - **Policy.** If a team adopts a protected-time policy, it should write down whether the time is mandatory, optional or capped, and how it's tracked. - **Security.** Automated vulnerability resolution needs a definition of "resolved" before a percentage means anything (¶22). - **Education.** Documentation and onboarding belong in the same friction list as build time (¶14), which is a framing teachers of developer onboarding can use. - **Funding.** Funding bodies that support maintainer or contributor experience can ask for time-tracked outcomes, since this article gives none. - **Vendor claims.** Treat company-reported AI gains as hypotheses until the metric, period and baseline are published. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level 12.4 and Flesch Reading Ease 34.0 on the captured text (562 words, 36 sentences, computed with a simple syllable heuristic that counts headings and short fragments as sentences, so treat it as an estimate). That's college level, driven by multi-clause sentences and terms like "organizational friction." #### 👀 Visual learners - Present: the captured text has no chart, diagram or table. A hero image link exists (see References) and its content isn't visible in the capture. - Improve: a simple table of the three figures with metric, period and baseline columns, and a diagram of the ask, schedule, fix, measure loop the article describes in prose. #### 🔊 Aural learners - Present: no audio or video appears in the captured text. - Improve: a short audio summary or interview recording would serve readers who prefer listening, since the piece is built around quotes. #### 🗣️ Verbal learners - Present: direct quotes from the interviewee carry the argument (¶6, ¶8, ¶13, ¶16, ¶19, ¶23), and the contrast between buying tools and asking developers (¶5) is clear in words. - Improve: define "pull request cycle time" and "auto-resolved" in the text. #### 🧩 Kinesthetic learners - Present: ¶8 gives a direct instruction to run developer surveys. - Improve: add a starter survey with five questions or a one-page template for scheduling protected time. #### 🧠 Logical learners - Present: the argument has a clear chain: friction causes lost time (¶14), unscheduled fixes lose to feature work (¶15), so schedule time (¶11). - Improve: show how each figure was derived, and separate correlation from the company's claim of cause. #### 🧑‍🤝‍🧑 Social learners - Present: the piece centers on asking developers and giving them shared time. - Improve: add discussion prompts for a team retro, such as "what is the one thing that slows you down most?" #### 🧘‍♀️ Solitary learners - Present: the short "Key takeaways" block at ¶1-¶4 lets a reader scan alone in about 30 seconds. - Improve: add a reflection prompt asking a reader to list their own top three friction sources before reading on. #### 🌿 Naturalistic learners - Present: limited. The language is organizational and abstract. - Improve: a concrete before/after scenario for a single developer's week would ground the 10% idea. ## 📊 Accessibility assessment Judged from the captured text and link list only. The rendered page, alt text, styles and any images weren't inspected. #### Screen reader semantics - Present: the text arrives as short paragraphs with a "Key takeaways" label (¶1) and two section headings, "Removing friction for developers" (¶9) and "Being AI-first" (¶17). Whether these are real heading elements, and at what level, can't be judged from the capture. - Improve: the link list has two links with the identical anchor text "developer experience" going to different pages, and an empty anchor. That risks WCAG 2.2 AA 2.4.4 (Link Purpose, In Context) and, for the empty anchor, 4.1.2 if it's a real link. Single-word anchors like "AI" also go to two different destinations. #### Keyboard navigation - Present: unknowable from captured text. - Improve: verify focus order, skip link and visible focus (2.4.1, 2.4.3, 2.4.7) on the live page. #### Contrast and readability - Present: contrast can't be seen from text. Paragraphs are short, typically one to three sentences. - Improve: check body text at 4.5:1 (1.4.3). Reading level is about grade 12, so a plain-language summary would help. The "Key takeaways" block (¶1-¶4) already serves part of that role. #### Text resizing and reflow - Present: unknowable from captured text. - Improve: test at 200% zoom and 320 CSS px (1.4.4, 1.4.10). #### Media and captions - Present: no media referenced in the captured text. The text mentions no audio, video, captions or transcript. The link list includes a hero-image label ("Article hero – Encouraging a culture of developer productivity"), which suggests a hero image with a descriptive name exists. - Improve: confirm the hero image has alt text that fits its purpose (1.1.1). #### Forms and interactions - Present: no forms in the captured text. - Improve: check any newsletter signup or event prompts on the live page for labels and error handling (3.3.2, 3.3.1). #### Standards reference - Gaps visible from the capture: 2.4.4 (identical anchor text with different destinations, one empty anchor). Everything else needs the rendered page. ## 🌍 DEIB assessment #### Cultural breadth - Present: the piece covers one company and one interviewee. No country or region is named in the captured text. - Improve: add examples from smaller companies, open source projects and teams without a large platform budget, since a 10% time policy is easier at scale. #### Inclusive language - Present: "developers" and "engineers" are used without gendered terms. The text uses no gendered pronouns for either named person. - Improve: "organizational friction" and "pain points" are business idioms that add load for translators and non-native readers. #### Neurodiversity support - Present: short paragraphs, labeled sections and a three-bullet summary block (¶1-¶4) make the piece scannable. - Improve: the three figures appear as bare numbers with no definitions, which makes them hard to check for a reader who wants exact terms. #### Representation - Present: one interviewee, one writer. - Improve: no developers at Atlassian are quoted, so the people whose experience the piece is about are described, not heard. A survey result or a developer's account would balance a view that comes from a customer CTO. #### Psychological safety - Present: ¶16 says the point is giving space and time, not granting permission, which signals that developers shouldn't have to ask for approval to fix their environment. - Improve: the piece doesn't say whether developers face pressure not to use the 10%, or how managers treat it in reviews. ## ✅ Logical validity This is an interview-based feature with a single source who speaks for Atlassian about Atlassian's own practices and AI products. The assessment weights how far the claims exceed the evidence offered. #### Strong reasoning - **Structural argument, ¶15.** Improvement work competes with features and operations unless scheduled. The reasoning is coherent and doesn't depend on any figure. - **Ask before buying, ¶5-¶8.** Surveying developers before choosing a fix is a low-cost principle with a clear mechanism: it finds the real bottleneck before money is spent. - **Friction list, ¶14.** Naming build times, documentation, debt and process makes "developer experience" concrete enough to act on. - **Qualified closing, ¶24.** The writer says the value isn't only speed but the removal of repetitive work, which avoids reducing developer experience to a single speed metric. #### Fallacies - **Appeal to a single authority, ¶6-¶8 and throughout.** Every claim rests on Boyagi's account, with no second voice. Fix: interview an engineer and an outside observer, or link a published Atlassian write-up. - **Unsupported empirical claims, ¶3, ¶4, ¶11, ¶21, ¶22.** "10% of developers’ time," "45% faster PR cycles" and "51%" are given with no method, period, baseline or scope. Fix: state the metric definition and period, or label them "the company says." - **Correlation implied as causation, ¶18-¶22.** The article places AI-first practices next to improved numbers and implies the practices caused them, without ruling out other changes. Fix: say what else changed. - **Survivorship framing.** The piece reports no failed initiative, low uptake or cost. Fix: ask what didn't work. - **Vague denominators, ¶4 versus ¶22.** The takeaways say "security vulnerabilities" and the body says "potential vulnerabilities." Fix: state which one the 51% counts. - **Conflict of interest, not stated.** The interviewee speaks for Atlassian about Atlassian's AI products (¶18-¶19). LeadDev sells events per the task metadata, and the link list includes an AI coding tools buying checklist and an assistants comparison. The captured text has no disclosure statement. Fix: a one-line note on relationships, if any. - **Takeaways block overstates, ¶4.** "AI is already cutting friction" is stated as fact, while the body attributes the 45% to what Boyagi "has seen" (¶21). Fix: carry the attribution into the summary. #### Tone of voice - Upbeat and promotional in effect, though the writer's own prose is measured. Quotes from the interviewee use aspirational phrasing ("meaningful, that’s high quality," ¶13). The article contains no skepticism, which is typical of a series that sets out to explain "what makes their engineering culture tick" (¶0). ## 🛡️ DARVO analysis Not applicable to this source. DARVO describes a defensive response to an accusation, and this is a company-friendly interview feature with no accuser or accusation. For completeness: **Deny.** Nothing is denied. **Attack.** No critics or groups are attacked. The nearest edge is the claim that "a lot of companies fail" at asking developers (¶6), which is a general criticism, not a response to a charge. **Reverse victim/offender.** No such move appears. ## 🎯 Conclusion The durable part of the article is a principle: ask developers what slows them down, then schedule time to fix it, because unscheduled improvement work loses to feature work (¶8, ¶15). It names outdated documentation as one of four friction sources (¶14), which supports treating docs as developer-experience infrastructure. The numbers are the weak part. The 10% time policy, the 45% faster pull-request cycles and the 51% of vulnerabilities auto-resolved are the interviewee's self-reported claims about Atlassian's own practices and AI products. The article gives no measurement method, time period, team scope, baseline, definition of "resolved" or independent data, and none of the 12 links points to a source for them. The body and the takeaways block also word two of them differently (¶3 versus ¶11, ¶4 versus ¶22). **Next steps for readers:** use the asking-first and protected-time ideas as hypotheses and test them on your own team. Don't cite the three figures as benchmarks. If you need them, ask Atlassian or LeadDev how each was measured. ## 🔄 Refactor Appendix — Inside Atlassian's developer experience overhaul > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the 10%, 45% and 51% figures > were not made atoms because each is a self-reported number with no method; they stay in Summary. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Companies fail by not asking developers > [!quote] [¶6] > Where I see a lot of companies fail is they don’t ask their developers what needs to be improved **Context & use**: - ¶6, the interviewee's core claim for the whole piece. It is one person's observation with no data in the capture. - Pair it with ¶8, which names surveys as the method. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Documentation sits among developer friction sources > [!quote] [¶14] > At Atlassian, developer friction often stems from build times, outdated documentation, technical debt, and inefficient processes. **Context & use**: - ¶14, the line that supports docs-as-friction for DevRel and documentation work. - It is a statement of what the company sees, not a measured finding. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H3] Improvement needs space and time, not permission > [!quote] [¶16] > It’s more about giving them the space and the time to do it. **Context & use**: - ¶16, the interviewee's reason for scheduling the 10% (¶11, ¶15). - Usable as a short line in an argument for protected maintenance time. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H4] Atlassian ties its AI-first products to its own practice > [!quote] [¶19] > To build AI-first products, we had to become an AI-first engineering organization ourselves **Context & use**: - ¶19, the interviewee speaking for Atlassian about its own AI products. It names the commercial interest behind the AI section. - Read ¶20-¶22 with this in mind. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H5] The 45% PR cycle figure is a self-reported claim > [!quote] [¶21] > Boyagi says the company has seen AI agents reduce pull request cycle times by 45% **Context & use**: - ¶21, the only place the 45% is attributed in the body. No metric definition, period, baseline or scope follows. - Keep any citation of this number tagged as "per Atlassian's customer CTO." **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Docs are developer friction and need scheduled time **Claim** (one sentence, Courtney's voice): Outdated documentation costs developers time like slow builds do, and it only gets fixed when someone schedules the work. **Evidence pointer**: [[#H2]] · [[#H3]] **Scope & conditions**: Holds where documentation is a real part of the developer workflow. The source supports it only as an assertion from one interviewee, with no measured link between doc currency and developer speed. **Links**: - [[Docs as developer experience]] — because extends - [[Protected maintenance time]] — because applies-in documentation team planning - [[Diátaxis documentation structure]] — because evidence-for treating docs as product <!-- atomicity: 1 idea ✓ --> #### [P2] Vendor-reported metrics need a method before I cite them **Claim** (one sentence, Courtney's voice): A percentage from a company about its own AI product is a claim to test until the metric, period and baseline are published. **Evidence pointer**: [[#H4]] · [[#H5]] **Scope & conditions**: Applies when the speaker has a commercial interest in the number and the article gives no method. It doesn't mean the number is wrong, only that it's unverified. **Links**: - [[Source evaluation]] — because extends - [[Conflict of interest in technical writing]] — because applies-in citing vendor claims - [[Independent measurement of AI productivity]] — because contrasts on who measures <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Ask LeadDev or Atlassian how the 10%, 45% and 51% figures were measured, https://leaddev.com/culture/inside-atlassians-developer-experience-overhaul #fleeting #inbox - [F2] Draft a five-question developer-friction survey for DevRel or docs contributors, modeled on ¶8 #fleeting #inbox - [F3] Find a published Atlassian source for the pull-request cycle time and vulnerability numbers, if one exists #fleeting #inbox - [F4] Article seed: "Docs are developer friction too." Using ¶14 plus my own audit data #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Ask the LeadDev editor how the three Atlassian figures were measured, article follow-up, 10 min #things - [ ] Draft a five-question friction survey for the docs team, based on the asking-first principle, docs planning #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Inside Atlassian’s Developer Experience Overhaul.md|Inside Atlassian’s Developer Experience Overhaul by Chantal Kapani]] ## Highlights - “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. ([View Highlight](https://read.readwise.io/read/01m3w1qa30jphkq9dh1zc2t7xq)) - Note: [H1] Companies fail by not asking developers - Tags: atom/literature/h1 - At Atlassian, developer friction often stems from build times, outdated documentation, technical debt, and inefficient processes. Developers can also lose time searching for information, navigating unnecessary processes, and working around organizational bottlenecks. ([View Highlight](https://read.readwise.io/read/01m3w1qcah38dm4az81s8eqjz4)) - Note: [H2] Documentation sits among developer friction sources - Tags: atom/literature/h2 - 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.” ([View Highlight](https://read.readwise.io/read/01m3w1qend7x5wbme9bp2n19y8)) - Note: [H3] Improvement needs space and time, not permission - Tags: atom/literature/h3 - “To build AI-first products, we had to become an AI-first engineering organization ourselves,” explains Boyagi. ([View Highlight](https://read.readwise.io/read/01m3w1qh4zx75q33pgq0sgffsj)) - Note: [H4] Atlassian ties its AI-first products to its own practice - Tags: atom/literature/h3 - 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 reduce pull request cycle times by 45% – addressing what he describes as a key pain point for developers. ([View Highlight](https://read.readwise.io/read/01m3w1qkem4j7f8ka8t451k9sb)) - Note: [H5] The 45% PR cycle figure is a self-reported claim - Tags: atom/literature/h3