Techzine Talks on Tour
Techzine Talks on Tour is a podcast series recorded on location at the events Coen and Sander attend all over the world. A spin-off of the successful Dutch series Techzine Talks, this new English series aims to reach new audiences.
Each episode is an approximately 30-minute discussion that Coen or Sander has with a high-level executive of a technology company. The episodes are single-take affairs, and we don't (or hardly) edit them afterwards, apart from polishing the audio up a bit of course. This way, you get an honest, open discussion where everyone speaks their mind on the topic at hand.
These topics vary greatly, as Coen and Sander attend a total of 50 to 60 events each year, ranging from open-source events like KubeCon to events hosted by Cisco, IBM, Salesforce and ServiceNow, to name only a few. With a lot of experience in many walks of IT life, Coen and Sander always manage to produce an engaging, in-depth discussion on general trends, but also on technology itself.
So follow Techzine Talks on Tour and stay in the know. We might just tell you a thing or two you didn't know yet, but which might be very important for your next project or for your organization in general. Stay tuned and follow Techzine Talks on Tour.
Techzine Talks on Tour
The Atlassian platform is a Lego box of collaboration tools
What happens when you study how millions of teams work and collaborate over 20 years? You learn a lot and can use those insights to help organizations operate more effectively. That's what Atlassian wants to achieve with its "System of Work" - not a product you can buy, but a framework for bringing teams together in tech-driven organizations.
Anu Bharadwaj, Atlassian's President, explains this approach to us and to you. It is built on four essential pillars: aligning work to goals, planning at scale, unleashing knowledge across silos, and making AI a natural teammate. The idea is that it all works like a box of Lego.
When we first heard about System of Work, we thought it all sounded a bit esoteric and wondered how concrete it is. As it turns out, it is very fundamental to how Atlassian approaches the market, and therefore also fundamental for (potential) customers. Even though the separate components may not change that much, the way they integrate and interact with each other will (and has already changed with the launch of several Collections).
Deeper integrations usually also have a lock-in ring to them. Bharadwaj is adamant that is not the case here, when we ask her about that.
Listen to the episode now to hear all about System of Work and what that means for tools like Jira, Confluence, Loom and Rovo AI agents and by extension for the market as a whole.
Welcome to this new episode of Techzine Talks on Tour. I'm at Atlassian Team 25 and I'm here with Anu Bharadwaj. She's the president of Atlassian and I'm glad I pronounced your name right again. We did some prep here and it's always good, so welcome to the show.
Speaker 2:Thank you so much. It's wonderful to be here you have a nice title, president.
Speaker 1:It must be nice to be president of something.
Speaker 2:It's wonderful to be here. You have a nice title, president. It must be nice to be president of something. Yes, indeed yeah, I've been at Atlassian for 10 years and I've gone through various different jobs in my time, but I started as the product lead for Jira and have done various jobs, including chief operating officer and now president. Okay.
Speaker 1:So we're going to talk about the system of work. That's something that I mean you came up with. I think the first publication I found about it was the last January or something. That's right. It is the result of 20 years of very deep thinking and research from your side. For me, when I see the term system of work, I don't really immediately have an association with it, so maybe the first question is what on earth is it? What do you want to convey with this?
Speaker 2:That's a great place to start. So Atlassian has been a collaboration company focused on teamwork and we've been around for the last 23 years and so we've thought very deeply about teamwork. Like you said, we have 300,000 customers and so we've seen millions of teams and seen patterns around what makes teamwork work and who are the kinds of teams and what are the kinds of practices they deploy to make it really shine and what kinds of teams are facing challenges and what their practices were and what their challenges were.
Speaker 2:So we took those 20 years of insight and distilled it into what we call the system of work. So system of work is basically a philosophy. So Atlassian has a strong opinion.
Speaker 1:It's not a product, let's put it there. So that's good to know. Right, so it's not a product, you can't buy it. No, that's good to know.
Speaker 2:That's right. So system of work is a philosophy of how tech driven organizations so not every organization, but really, if, for your business, technology plays a starring role, if you're a bank that has an online presence, if you are an insurance provider, a healthcare provider, anybody whose business depends on technology, if you're a tech-driven organization, the system of work really helps you build a blueprint for how to run your organization. How do you bring your teams together such that you can contribute to the growth of the company?
Speaker 1:So it has. One of the connotations I did have was with the system of record, right, so it has the sort of same fundamental implications, right? That's true, yeah.
Speaker 2:So system of record is basically a bit of an older concept around. How do you store different pieces of information?
Speaker 2:So, you can have a system of record for collaboration documents. You can have a system of record for customer information, system of record for development information System of work is really work gets done across various different teams with different kinds of work. But how do you put that all on one single system such that you can make sense of it when you want to? Because typically information and knowledge is available across a lot of organizations but it's locked in different silos, like your sales team knows the most amount of information about the customer, your marketing team knows the most amount of information about what performs well on campaigns and your product team knows the most amount of information about technical details. But putting it all together so that you have insight that you can unlock from information you already have.
Speaker 1:So you mentioned earlier there are the learnings in the in the past 20 years. And, yeah, and how you came to this philosophy? What were some of those key learnings? Can you be a bit more concrete about it too?
Speaker 2:yeah, so we have four fundamental pillars of the system of work. Think about it as we give our customers a set of Lego blocks, such that they can use the Lego blocks and then build a system that works for them, that is unique and customized for them, because every business is different. So some of the basic principles of the system of work is one we believe that work should be aligned to goals. As a company grows bigger, it's hard to say if the company goal is, let's's say, grow revenue by 15%. Is the developer working on feature X really contributing to that?
Speaker 2:Is the customer support person really contributing to that it's hard to prove those things and so the system of work designs an operating system through which you can track whether every person is contributing to a certain goal or not, and it doesn't all have to be the same goal, but at least you've aligned on a set of goals as a company. That's one. A second one is how do you plan and track work at scale when different teams are doing different things? How do you manage dependencies and handoffs and all of that? The third one is how do you unleash knowledge, like I talked about, different teams have different expertise and in any modern company, information gets stored across different applications, different sources. We at Atlassian believe that an open ecosystem is the way to go.
Speaker 2:it's a philosophical difference from other companies so what that means is we are able to look at information stored not only in Atlassian but in other third-party products and bring it all together on a connected data platform in the teamwork graph and help you surface insights. And the last one, that's least but last but not the least, is how do you make AI a part of your team? Because we are very much about teamwork, we think about how do you make AI an integral part of every team, such that it doesn't feel like, oh, ai is something I have to use, some tool that I have to use and do something alien and foreign in order to deploy it in my workflow. But think about if I have an AI-driven teammate sitting next to me doing a part of my job. How do I really work with them? How does human-AI collaboration work?
Speaker 1:So these are still high-level concepts to a certain extent. How concrete can you make it for, uh, for organizations? So obviously you've only started with this in january, so you've been thinking about it for a long time, but how concrete can you make it? So where do you start? What's, what's the? What do you need to do apart from calling you but yeah, calling at last can say I want your stuff.
Speaker 2:But so we've actually wrapped up the early access program and we're making teamwork collection our first step into a system of work generally available. So that's the exciting news we have at Team 25. And so we've had several of our customers and hundreds of users really already adopt the system of work. So concretely, what does it mean? One of our customers, procore, used the system of work to effectively eliminate a bunch of manual tasks that they had to do manual project management tasks that they had to do and reduced it by 4x the amount of manual time spent. Another of our customers deployed the system of work and saved thousands of hours in meetings by switching to an asynchronous form of work. Again, we strongly believe that distributed work is the future, and so async work would involve creating Loom videos and synchronicity.
Speaker 1:But even though it's a concept, it's not a product.
Speaker 2:Yeah.
Speaker 1:You say they use system of work to do X. What does that mean then? Using system of work, Do they use your tools? Do they use the correct configuration of those tools to actually get to sort of an overarching fabric that actually works in their favor?
Speaker 2:Yeah, that's a good place to orient. So the system of work can be implemented by using what we call collections. So Atlassian offers five collections and the central collection is called Teamwork Collection. So what is Teamwork Collection? It's a set of apps and agents and practices. So apps are Jira, Confluence, Loom and agents are robo agents robo teamwork agents and the practices are what I described earlier.
Speaker 2:So collectively, putting that all together, you can buy a license called Teamwork Collection. Together, you can buy a license called teamwork collection. Now, the way that Procore deploys teamwork collection or the way that another customer, harper Collins, deploys teamwork collection will look different across different companies, but the fundamental threads are the same that it's a connected data platform. You're bringing your technical teams, non-technical teams, all of them together to surface inside. So teamwork collection is the first step to implement the system of work. We believe that every knowledge worker in any company should have teamwork collection. And then we have four other collections for specialized teams. So within an organization there will be a small number of teams which are leadership teams. For them we have built something called strategy collection, which helps with enterprise strategy and planning. There will be a small set of product and software teams. That it teams that are involved in building software. For them we have software collection. There will be a small set of teams that are building products, so, especially in tech companies, for them we have product collection.
Speaker 1:And last, and the biggest one right now is the service collection, which are built for service management teams, hr teams, marketing teams how do you, how do you balance, how do you keep the balance between because you mentioned earlier that you're also open, so you also believe in connecting with other other sources of truth or data, whatever you want to call it how do you, how do you keep the balance between between getting as many people on as many different tools that you offer, between that and the openness that you want to describe, because you could also interpret this as a system of work and maybe the collection story. You can also interpret this as a sort of a lock-in story. We want as many people on as many tools that we have so we can keep them, and I get it because you want to make money and you're a business, but the reality is obviously that there's a very diverse landscape. How do you keep the balance there?
Speaker 2:That's a great question. So, in order to implement the system of work or use any of the collections I mentioned, there is no requirement for a customer to say use only the Atlassian tools. In fact, our tools get used a lot with other SaaS applications. We ourselves at Atlassian use other applications like Slack, salesforce, etc.
Speaker 1:Otherwise you would have to build a lot of extra applications, Right.
Speaker 2:So, realistically, we expect that every modern company will have multiple applications. The way we solve that is by building connectors. So what we've done with Robo is we've built 50 connectors to Google Drive, slack, salesforce, figma a number of commonly found applications. So the consumer doesn't have to do anything different. What they have to do is we've done the hard work of building those connectors. So all they need to do is deploy Teamwork Collection, which has Robo in it, and we are able to then take the data from various different sources and surface it where it's useful and relevant to the consumer.
Speaker 1:I mean basically that also sort of means that system of work is a natural progression of what you were already doing, right?
Speaker 2:Right.
Speaker 1:So it was. It was not necessarily an end state, because it's never finished.
Speaker 2:I get how it works.
Speaker 1:But it makes perfect sense from where you're coming from, where they're progressively integrating more and more so then eventually you get towards the point of system of work.
Speaker 2:Yeah, exactly so the system of work to implement it is not like one discrete point in time that you do it, but you're right in that you can progressively add more and more of the Lego blocks that I talked about in order to build the system you and why?
Speaker 1:is this something that only Atlassian can create? Or is it something that others could have, could have thought about or create, could have created as well? Or I get the impression that one of the foundational pieces of Atlassian, the teamwork graph, is also extremely important for this entire concept, right?
Speaker 2:Indeed yeah.
Speaker 1:You couldn't have gotten here without that.
Speaker 2:Indeed yeah.
Speaker 1:So is that the reason why you can create it and others don't, or haven't, or how do you see that?
Speaker 2:So there are two fundamental reasons why only Atlassian can create the teamwork graph. So the teamwork graph, to be clear, is the web of interconnections across different objects used by consumers and the connection between teams and work and where work gets done. Why is Atlassian unique One? We are the only company that offers a portfolio of five collections across five discrete sets of consumers. So you look at any other company, very few have the kind of breadth of portfolio with products that are already used and loved by 300,000 customers, like you mentioned. Second, we have the open ecosystem philosophy because there are these really large mega corporations that have the kind of portfolio that we have.
Speaker 1:We all know who they are.
Speaker 2:What they do, though, is they create a walled garden approach, where they want you to adopt all of their set of products and not others. You would like that too, probably, but like you said that's not realistic.
Speaker 2:Also, it's not how we build our tool set. So I worked at Microsoft for 10 years before I came to Atlassian and the thing that struck me was the philosophy is completely different, where we believe that we have to be in an open ecosystem, because consumers ultimately have choice, and the way we build is with extensibility built in into the product such that we integrate with other products, because our business model is self-serve. Our products live and die by. Do end users love your product or not?
Speaker 2:yeah right, so it's not like we are selling it in a large enterprise channel and therefore the two things about open ecosystem and the breadth of portfolio and the kind of users we already have. In fact, one of the things that surprised me when I got our last year was even ten years ago, the number of Jira users were non-technical users. Guess how big that number is. Over half of our users are non-technical users. I came in thinking, oh, jira is going to be used by a lot of developers and tech teams.
Speaker 2:You would think that right yeah but even 10 years ago, more than half our users came from non-tech backgrounds, so the breadth is quite mind-boggling.
Speaker 1:And when you bring pieces together and you form it into a more of a coherent whole, there is also you probably. I mean you're also breaking down silos and all that stuff which is good in a certain way, but also I always say that silos are not. You were built for a reason. Right, there was a reason once to build a silo, that's right yeah, and sometimes it may be a very good reason.
Speaker 1:So, conceptually, as we're talking philosophy anyway, and concepts and all that stuff, when you bring all these things together, how do you make sure that you keep the definition and the clarity in all the pieces that are very important to still understand? I think, as an organization that you have, that you don't get it into one big sort of blob.
Speaker 2:Yeah, so the system of work is fundamentally meant to be a framework that unites your tech and non-tech teams. Right? What that means is it's a compound system, so there are always going to be different blocks, but how the different blocks are demarcated and what the boundaries are depends on the company. So, for instance, at Atlassian, our product and development teams are very, very integrated, Whereas in a consumer retail company they're quite different. Right Makes sense. Therefore, the way we've built our collections is focusing on the anchor persona.
Speaker 2:And so the way that companies will construct their building blocks is going to be, for example, in a retail company, a product collection and software collection might be used by the same person, but in a tech company, product and software collection might be used by two separate teams. So what we do to drive the distinction very much is what's the job to be done? What exactly are you seeking to achieve? And as AI development and native development becomes common, I think we'll increasingly see a collapse of that. So more and more generalists will come about, which means more and more people will use the same collections on top of each other.
Speaker 1:And obviously the trick is to determine what the perfect balance is between all the tools that you have for your organization.
Speaker 2:That's right, and so the easy answer is really we say teamwork collection. Don't worry about any other collection, just deploy teamwork collection across the board, and that covers majority of the collaboration cases On top of that. Then you can worry about what are other collections for specialized teams. But for many teams that's the first step. Yeah, so you probably cover 80% of cases, of these cases anyway, right yeah.
Speaker 1:And you can fine-tune when and if needed, right? And do you need a lot of knowledge inside the organization of this concept to actually properly understand it and maybe fine-tune it to just maybe to your liking? How much do you need to do as an organization yourself about this?
Speaker 2:Yeah, that's a great question. So the kind of knowledge you need to implement system of work is really knowledge of your own requirements, right? So every company has their innate business model and their innate actual business and customer understanding. That's already available with experts inside the company. What we do is we work with those experts to say this is what the system of work looks like for Procore, this is what the system of work looks like for HarperCollins, and they might look very different in the end, but they're built using the same material, so it's really cement and water everywhere, but the end structure might look different.
Speaker 1:And our last question, because I think we're almost out of time when do you consider system of work a success? Or didn't you really put any sort of maybe intermediate stage kind of success markers on the horizon?
Speaker 2:Is there anything that you can say about when this is a success or not? So we think of system of work very much as a philosophy we espouse for our customers. So this is basically Atlassian's opinion on how tech driven organizations should work. So the markers of success is going to very much be dependent on customers. So why are we building the system of work? If I'm HarperCollins, I'm building this because I want to reduce my publishing time in half, or I want to have my productivity metrics such that are spent doing manual tasks. I want to reduce that.
Speaker 2:So, when we start deploying the system of work. Every customer defines their own success metric and we make sure that we deploy the system of work in a way that they can.
Speaker 1:Yeah, you could also think things like the collections you mentioned earlier. Yeah, if that's a big success, then automatically a system of work is also sort of by default. Yeah, so for us internally at Atlassian.
Speaker 2:Of course, the number of people using Teamwork Collection is an easy success marker. But we think about what can we do to make customers successful? And for that really we sit down and define those unique, custom markers of success for them.
Speaker 1:All right, thank you very much. I think I learned a lot at least, I hope the people listening to this as well, and otherwise, well, I'm going to stay, I'm going to keep covering Atlassian, or we're going to keep covering Atlassian anyway, so they can return to read or listen to other stuff.
Speaker 2:Well, thank you so much for coming to visit us. Thank you very much.