Atlassian Corporation (TEAM) Earnings Call Transcript & Summary

Hello, and welcome, everyone, to our DevOps Tech Summit On Demand series. We have developed this series around you, your busy schedule and the demands of life by providing on-demand sessions, launching daily at 10 a.m. Eastern Standard time. This series will conclude on Thursday with a live fireside chat with my colleague, Brooke Gravitt, and will include this week's industry speakers. As part of that closing conversation, we will host a Q&A session, so be sure to bring your questions. Before I continue, allow me to introduce myself. My name is Darren Brown, and I'm the Atlassian Practice Manager here at Forty8Fifty Labs. We are excited to have you here for one of our sessions in our DevOps Tech Summit series. Now before we get into our DevOps tech summit with our industry speaker, I wanted to take a moment to acknowledge that we couldn't do this without the support of our technology leaders and partners. Forty8Fifty Labs is a platinum level enterprise Atlassian solutions provider. We are also an Atlassian authorized training partner, Atlassian Partner Advisory Council member as well as being named the Atlassian 2017 Partner of the Year as their rising star and the Atlassian 2019 Partner of the Year for technology innovator. Our company is also the developer of 2 Atlassian marketplace apps, Splunk handler for mail and the real-time Splunk connector for JSD. We are definitely a proud partner of Atlassian and true believers in their culture. Check out their short video around their core values before we move into our upcoming session, which focuses on leveraging DevOps principles to improve change management within your organization. How does your organization take a slow, inefficient but vitally important change management process and deliver true value faster? That is the core question, and our upcoming speaker, John Meier, will be addressing in his presentation. Now John is a senior solutions engineer with Atlassian and possesses a wealth of first-hand knowledge of the challenges that companies of all sizes go through when developing the right change management process for their organization, one that drives innovation by removing the barriers and delivering value faster. So with that, we hope you enjoy this upcoming session. [Presentation]

Hi, everybody. My name is John Meier, and I am a senior solutions engineer here at Atlassian. Today we're going to be talking about how you can clean up your change management processes with DevOps principles. So today, let's start with the obvious. It's not news that developers and IT teams often work in silos with a variety of tools and sometimes conflicting objectives. One of the areas in which there are sometimes clashes is the change management process. Developers want to work swiftly and to ship value more frequently, whereas operations teams want to reduce risk and ensure compliance. Despite these conflicting objectives, both teams have many commonalities, the major one being both teams want to deliver products that meet the needs of the end user as well as the customer. The question we're addressing in today's session is how do teams transform a slow, inefficient way of managing changes into a streamlined process, while still fulfilling the objectives of a traditional change management process, traceability, transparency and risk management. To start things off, change management is about achieving intended outcomes when you add, modify or remove something that could have an effect on services. But this is challenging, as teams have different priorities. Shipping fast seems at odds with reliability. First, traditional change management is slow. A team builds something and then wait for it to eventually make its way to approval, often through an approval process that involves people who are distant from the original work. This is especially problematic in the dynamic environment we all operate in. We're providing a superior customer experience as a key differentiator, and shipping value to customers faster seems critical for success. Secondly, it's work-intensive and manual, because people often use redundant information in different tools. It's a one-size-fits-all process that is imposed on even the smallest of changes. Finally, the consequences of mistakes can be staggering, and sometimes it's hard to judge just how risky a change can be. The 2019 state of DevOps report also informs us that a more formal approval process does not associate lower change failure rates. In fact, it introduces potential for more risk with slower, less frequent, larger releases. With that being said, as enterprise software company, we at Atlassian know a thing or two about delivering change rapidly. Change to our products, including Jira, Confluence, Bitbucket and Opsgenie don't just happen out of the blue. Today, I'll be discussing how Atlassian's team have adopted DevOps principles that include processes, practices and mechanisms to help ensure that changes are deployed safely and quickly. We believe that our approach to managing change in software development can be applied to IT services and organizations, whether it's upgrading an existing network infrastructure, installing a new tool or implementing a brand-new technology across an entire organization. Before we start talking about Atlassian's approach to change management, let's start with a brief history of Atlassian. Atlassian was founded in 2002 by 2 university graduates who decided to start a software company because they didn't want to spend their time in the corporate world and wear suits every day. With that simple goal, Atlassian became real with the launch of Jira 1.0. Fast forward to 2020, and Atlassian has grown to over 5,000 employees with offices around the globe. The company has gone from a team of 2 coding in the comfort of their homes to thousands of engineers worldwide, a global team of many, writing code and releasing software changes multiple times a day, every day. Atlassian's engineering teams have seen firsthand how important it is to have a combination of principles, processes and mechanisms as the organization fulfills our mission to unleashing the potential of every team via our collaboration software products. Based on insights shared by our senior engineering leaders from here at Atlassian, the following best practices can help transform a slow, inefficient way of managing changes into a streamlined process, while still fulfilling the objectives of a traditional change management process. The first best practice is to embrace agile devOps principles to reduce human effort and error. Agile and devOps principles like an iterative approach, continuous delivery and automation are not new to startups in the software development industry, but it's often seen as less applicable to highly process-driven, heavily regulated industries like government and banking. But what if we told you that being able to leverage agile and devOps principles is essential to ensure a swift and seamless change management in today's business landscape. Andre Serna, the head of engineering for our server and data center products here at Atlassian, believes that agile and devOps principles can definitely work hand-in-hand with regulation and compliance. For example, when he was working for the commerce team at Atlassian, they were the first team within Atlassian to introduce regulation and compliance processes as we went through our IPO. They introduced lightweight, automated and effective processes to meet compliance and regulation requirements. Andre believes that automation should play a big role in this day and age as automation enables segregation of duties. For example, if a change meets certain criteria, say, 2 people have signed off on a code change via a pull request, it can be used as a sign-off for compliance. You will note that here, we are leveraging agile ways of working in devOps principles by introducing smart automation through sensible rules and thresholds to existing processes. Smart workflows, automation and agile processes are beneficial in any industry, including heavily regulated ones. The next best practice is valuing autonomy over authority for rapid decision-making. Many IT organizations that practice traditional change management are familiar with the information technology infrastructure library. ITIL contains a set of detailed practices for IT service management, focusing on aligning IT services with business needs. One widely known ITIL component is CAB, which stands for Change Advisory Board. The CAB delivers support by improving requested changes and assisting in the assessment and prioritization of those changes. This body is generally made up of IT and business representatives and might include a change manager, user managers and groups, technical experts, possible third parties and customers. While there are many benefits of CABs, they could sometimes contribute to slow decision-making as a group of people from the CAB would need to process change requests, prioritize these requests manually, assess the risks and impact of each change, go back and forth with multiple change request just to obtain necessary information, obtain alignment within the CAB and finally come to a decision. It's not uncommon for IT organizations to have change requests that take months or even quarters. This is very inefficient if a change request is small and doesn't warrant this kind of time commitment from all parties involved. At Atlassian, we opt for autonomy over authority when it comes to making decisions about changes. Jonathon Creenaune, our head of cloud foundations, believes in a daily release review process within his department to help determine risk of change and unleash the ownership to those rolling out the changes. They do this to be asking relevant questions. Now to be clear, daily release reviews, they're not like an approval step that you often experience within CAB. It's more subject matter experts asking questions to uncover blind spots so the person rolling out the change can make an informed decision about their approach. For risk assessment, the first-line manager has the accountability to determine how risky a change is. This is done before the daily release review process. At Atlassian, we are open and trusting. We communicate openly, and we challenge directly. This approach of autonomy over authority enables swift decision making while providing clear accountability and expectations. Failing to plan is planning to fail, and this also applies to releasing changes. However, the key is not to introduce a new process for planning but to integrate it with existing processes in performing the work. My colleague, Jonathon Creenaune, mentioned in the previous slide, described how this works and practiced in his department, cloud foundations, which is responsible for infrastructure, build engineering, deployment, provisioning and many other platform services that power Atlassian's products and development. So he's familiar with the best practices to perform change safely and swiftly where agile is at the top of everyone's mind but failures of systems have a direct impact on all employees' productivity. He said that their change management process starts from the very beginning, from when a Jira ticket is created for any type of work. They start thinking about risk management, identify how they're going to roll out changes effectively and what mechanisms they would use. For example, do they need to feature flag this change or not? What would be the ideal soaking period? What are our considerations on how to test or rollout, et cetera. So you must plan for releasing changes from the very beginning. The next best practice is minimize the negative impact of change by preparing for failures and incidents. We understand that one of the fundamental reasons for IT organizations to practice traditional change management processes is to minimize the negative impact changes can have on customers and businesses. Zak Islam is our Head of Engineering for the cloud versions of our flagship products. When it comes to minimizing negative impacts of change for cloud customers, he believes that it comes down to the mechanisms that we have. CICD sounds amazing, but in reality, it's difficult to be 100% sure about how something in a master code branch is going to work out in production. This is why you should have canary environments. At Atlassian, we soak our code changes in one environment first and deploy our code changes in stages. He adds that blast radius is the lever that he and his team used in ensuring safe yet fast deployments. They can move fast when they have a smaller blast radius. With a smaller blast radius, customer impact is small if anything goes wrong. He went on to say that the key for them is to make it easy for engineers to deploy to production in a way that is seamless, safe and fast. For example, for Jira Monolith, they used to deploy to all regions at the same time, but they realized that a breaking change could bring every region down and customer impact would be very large. That's not good, so now they deploy in stages. To elaborate a bit further, they have 6 AWS regions. So firstly, they deploy it to an internal production-like environment and then to a specific region in production. And then when they have enough confidence that the change is safe, they deploy it to all regions. Zak believes that as software becomes more ubiquitous and critical to running many businesses, it presents a new set of challenges. Confidence in your products working as expected in all regions and all environments is gained via monitoring, anomaly detection and alerting. All of this should be as automatic as possible. Lastly, Zak believes that it's good to trust your software and systems, but they change. There is a misconception that if you leave your systems in code alone, everything will stay the same, and that's simply not true. There are network changes, operations system upgrades and other changes that you may not know. Therefore, it's important to trust your systems but verify continuously through mechanisms such as war games and chaos engineering practices to make sure they're resilient. When something goes wrong, the failure should show up in monitoring tools and trigger an automatic alert. At Atlassian, the very reason for releasing changes is so we can provide better value to our customers, whether they're internal employees or external users of our software. We believe this is the same for many organizations. Paul Slade, the Head of Engineering at experience platform here at Atlassian is a big believer in continuously improving our processes and practices to become better. He emphasizes continuous improvement through finding and solving pain points of their organization and their customers. He believes that for us, our pain points stem from what we are optimizing for internally, safety and agility, versus what our customers want, stability and control. Our customers rightfully want to understand how software or a product changes impact their businesses, to know the time line of the changes and to have some degree of control. Internally, we are optimizing for reducing risk through small batch sizes and therefore, maximizing the throughput of change. We also want to learn from our change so that we can continuously improve and do better for our customers the next time. These 2 motivations can sometimes be at odds with each other. When asked about how Atlassian is handling those pain points, Paul continued to say that we are focusing on increasing the robustness of tooling and flexibility in how we roll out change so that we can give control back to our customers. As our tooling gets better, our ability to manage risk in a controlled manner improves, and we can then provide flexibility to our customers on how they would like to accept or implement the change within their organizations. To wrap things up, I would like to leave you all with some actionable advice. Start with the right best practices and then back them up with tools and constantly review your process. Then when there is a problem, whether it's a process or tool, don't invent a new solution. Instead, identify and solve the root cause. As more companies are becoming software companies, following an efficient change management process becomes increasingly important. In this dynamic environment, providing a superior customer experience is a key differentiator, and shipping value to customers faster becomes critical for success. It's now time to stop treating change with a one-size-fits-all approach and use smart automation, tools, technologies and practices to ship value faster without compromising on risk. Thank you all for your time today.