Williams uses almost every Atlassian product available. At Atlassian Team ’26 Europe in Amsterdam, Andrew Boyagi, customer CTO at Atlassian, takes the time to talk to us about what the company’s technology means for the Atlassian Williams F1 Team. What does Atlassian add to the already high-tech environment of a Formula 1 team? Read and watch to learn more.
When people see the Atlassian logo on a Williams Formula 1 car, they might assume it is a straightforward sponsorship deal. That is, that the two sides exchange logos and that the software is part of that exchange. Boyagi is quick to correct that assumption. Atlassian and Williams operate as a working partnership: Boyagi and his team work directly inside Williams to help drive its transformation, with the explicit goal of helping the team return to the front of the grid.
Also, Williams is a paying customer. Formula 1’s cost cap means that even if Atlassian wanted to provide its products for free, it could not. Williams buys every Atlassian product at the same price as any other customer and pays for professional services on top. Boyagi says this makes the partnership something Atlassian is genuinely proud of. Williams has chosen to spend its cost-cap budget on Atlassian because the tools deliver real value.
Atlassian wall-to-wall
The phrase wall-to-wall is not an exaggeration. Williams uses nearly every Atlassian product, with only two exceptions. It doesn’t use Jira Align and Atlassian’s customer service management product. That’s because those tools simply do not apply to the team’s business. Everything else is in active use.
From the Service Collection, Williams uses Jira Service Management to log and track faults with the car, and Atlassian Assets to catalogue every physical object in the organization. In under 18 months, the team has captured more than 450,000 assets, covering car parts, factory machines, and equipment.
From Atlassian’s Software Collection, Williams uses Bitbucket and Bitbucket Pipelines for source code, Compass as a software catalog, and DX to measure developer experience and return on investment for AI tooling. Across the organization, Confluence, Jira, Loom, and Rovo are in daily use. Jira Product Discovery is used to prioritize ideas by their potential impact on lap time, while Focus manages OKRs and company priorities, and Talent maps people to those priorities.
Software development matters in Formula 1
For viewers and readers unfamiliar with the technical depth of Formula 1, the volume of software development inside a team like Williams can be surprising. Most F1 teams develop the majority of their software in-house. They do this for two reasons: it is a competitive advantage, and under the cost cap, building internally can be cheaper than licensing external tools.
Williams develops aerodynamic software, wind tunnel software, and a wide range of highly specialized tools that are specific to the demands of designing and operating a racing car. The FIA does control the ECU (Electronic Control Unit) at the engine level, but a significant portion of the software that surrounds the car is developed by Williams itself.
The scale of the physical product adds to this complexity. A Formula 1 car contains roughly 80,000 individual parts. Each part follows a multi-stage journey: an aerodynamicist has an idea, the part goes through computational fluid dynamics analysis, a design team creates it, a small model is built and tested in the wind tunnel, the real part is manufactured, tested, and finally fitted to the car. That process touches many teams and must happen as quickly as possible.
Bottom-up, not top-down
The adoption statistics at Williams are impressive, that’s for sure. Confluence is used by approximately 93% of the organization, Boyagi states. Rovo sits at around 65%. Jira is used by roughly half the company every month. Loom is also in the 60% range. These figures span every department: aerodynamics, HR, marketing, finance, legal, and trackside operations all use Atlassian products in some form.
Interestingly, none of this adoption is driven by executive mandate, Boyagi stresses. No senior leader at Williams has instructed staff to use these products. People have chosen to adopt them because they see the value in getting their work done faster and at a higher quality.
The four flows framework for AI-era teams
Atlassian’s and Boyagi’s work at Williams has informed a broader framework that Atlassian now applies across its customer base: four flows that need to be healthy for teams to perform at a high level in the age of AI.
Purpose flow
Purpose flow describes how information about priorities, goals, and the context behind them move through an organization. When purpose flow is strong, every team knows how to prioritize its own work and understands how that work connects to the outcomes the organization wants to achieve.
Workflow
Workflow here refers not to a Jira workflow configuration, but to an end-to-end value stream. For Williams, the question is: how quickly can something go from an idea in an aerodynamicist’s head to a finished part on the car? Improving workflow means removing friction, wait time, and cognitive load at every step.
Knowledge flow
Knowledge flow is described by Boyagi as the foundation of productivity. It is the ability to find the information you need, when you need it, without having to ask another person. Of course, you need to also trust the information is accurate. When knowledge is locked in spreadsheets, emails, or slide decks, it is invisible to both humans and AI systems.
Intelligence flow
When the first three flows are healthy, intelligence flow, which basically means the effective use of AI, becomes possible. Without purpose flow, teams may move fast but work on the wrong things. Without workflow improvements, AI-generated content simply adds volume to existing bottlenecks. Finally, without knowledge flow, AI can only return generic answers rather than responses specific to the organization.
The role of the Teamwork Graph
The practical mechanism that connects Williams’ data to AI is the Atlassian Teamwork Graph.
Boyagi illustrates the value of the Teamwork Graph for Williams and the Atlassian Williams F1 Team with an example: if a Formula 1 fan asks a generic LLM whether Williams should upgrade its front wing this season, the answer will probably be yes, based on averages from the public internet.
If Williams asks the same question through the Teamwork Graph, the answer is entirely different. The Teamwork Graph acts as a context layer, ingesting data from Jira, Confluence, Assets, Focus, Loom, and even external sources like SharePoint and Google Drive. When that context layer is connected to a large language model, the question triggers an answer that considers current goals, available parts, upcoming race calendar, historical decisions, and whether the new part can actually be manufactured in time.
Boyagi is clear that this does not require organizations to abandon their existing tools. Williams still uses SharePoint. Atlassian itself uses Google Docs. The Teamwork Graph indexes and surfaces information from wherever it lives, is the message he wants to convey.
Real-time fault management on race day
The use of Atlassian products does not pause when Williams travels to a race. Every time the car leaves the garage, it is effectively a prototype. Between 300 and 350 different faults are identified with the car every race weekend. Every fault is logged in Jira Service Management.
The challenge in a race garage is that multiple engineers will often spot the same problem simultaneously. Each person logs what they see, with a different description and title, and multiple duplicate fault reports arrive at the factory. The factory then risks having several people start solving the same problem in parallel. That is a waste of time, which is scarce anyway when the next session may be days away.
Rovo AI agent deduplicates in real time
To address this, Atlassian has embedded a Rovo AI agent natively into the fault-logging flow. When a fault is submitted, the agent immediately alerts the user if a similar fault has already been logged, asking whether this is a unique issue or a duplicate. This prevents multiple copies of the same fault from reaching the factory.
When a fault does reach the factory, the same AI agent surfaces historical context. It identifies similar faults logged in the past, references the specific part number from Assets, names the person and team who resolved the previous fault, and describes how it was resolved. The goal is to reduce the mean time to recovery by giving engineers a head start rather than requiring them to start from scratch every time.
Watch and listen to the conversation we had with Andrew Boyagi now to get the full story on how Atlassian and Williams work together in the Atlassian Williams F1 Team.
Also read/watch: Atlassian’s Teamwork Lab researches and fixes broken work