How Atlassian measures and drives DevEx improvements

Abi: Preeti, so great to have you on the show. Really excited to chat with you today.

Preeti:  Thanks so much, Abi. I love your podcast and what you’re doing towards developer advocacy. I’m really excited to be here and to be chatting with you today.

Abi: Awesome. Well, we have a lot to cover, so I wanna dive right in. I wanna start with Atlassian’s journey with developer experience, and I’m particularly interested in this because of the new products you guys are developing, as well as a recent article from your CTO that made the rounds talking about Atlassian’s internal investment. I wanna start all the way at the beginning though. Tell us where the journey began for developer experience at Atlassian and what prompted it.

Preeti: Yeah, that’s a great question. You know, for us, we were pretty lucky that when Rajeev joined as our CTO, this was in 2022, he came in right away. And one of his priorities is to build a world-class engineering organization. And he truly believes that developer joy is the way to build this world-class engineering organization. And you know, for Atlassian, we’ve grown significantly in the last 20 years, right? 

We’ve hired a number of people, we’ve acquired companies, we’ve built new features, we’ve built new products. You know, there’s this tremendous phase of growth. And as is pretty standard here, the side effect of growth is all of these additional complexities and challenges that come up just as a result of that growth. And so this is kind of where our whole journey into developer experience started.

I mean, it starts way before that, but the focus started after Rajeev came in and made it a priority for us. So when we looked at this and when we looked at the growing pains and the consequences, we basically bucketed into three major areas. So the first thing that we found was there was just too much friction. We’d grown to the point where, you know, something simple where you commit something and you want to make it to production.

that’s just taken too long. There’s friction in that process. There’s friction in your PR cycle time. You know, as our teams grew and we got distributed, just this whole notion of who really owns the service? How do I get in touch with them? You know, where’s the run book for this thing? What do I need to understand? And so we really felt all of this pretty deeply, right? So that’s where the friction aspect of it comes in. And then,

The other problem that we saw was that our teams had a perceived lack of autonomy. And this is an interesting one, because at the end of the day, you go ask any development team, they can rattle off the top five things that are in their way of having a good developer experience, right? But the question is, knowing doesn’t mean that you feel empowered to act on those things.

This is what our teams were feeling and experiencing here. And so one of our company values is to be the change you seek. And so this fits right in with that, right? And then the other thing that we observed was we had a fear of breaking things. So this is probably something that a lot of us can relate to, right? You have code that’s been around for a long time.

You know that it is in the hot part. You know that’s a critical piece of code. But there aren’t enough people who understand the inner workings of it very well. You’re relying on tribal knowledge. Somebody comes in, they look at it and they’re like, eh, this doesn’t quite feel right. But you don’t know what the implications are of going and making changes there. You don’t know what’s going to break downstream. And so you do the safest thing, which is to layer on changes on top of each other, right?

So collectively, we looked at all of these and too much friction, lack of autonomy, fear of breaking things, and we knew we had to do something about it. And finally, the one thing that I want to add is we’re talking about all of these things, but at the end of the day, what we decided to do was just go ask our developers, how satisfied are they? And they will tell us. And that’s kind of the approach that we took and how we got started.

Abi: Really interesting journey. I have a lot of follow-up questions. First question is that you said “we” a lot. Who is actually championing and sponsoring the focus on developer experience at Atlassian. I mean, it certainly sounds like your CTO Rajeev coming in has been a big sponsor. There’s so many organizations I talked to where the sponsor is often someone a little bit lower level in the organization, maybe the head of infrastructure or even an engineer in the developer experience team.

Preeti: That’s right.

Abi: So in your case, it sounds like it’s really from C-suite.

Preeti: That’s exactly right. So when our CTO, Rajeev came in and he basically, him and his engineering leadership team, they really firmly believe that developer joy is what unlocks sustained developer productivity. He is our sponsor. We have a company OKR towards developer productivity. And so I think once you have that commitment towards it, at this point, developer productivity is just part of our normal conversation at Atlassian. So I really do feel that it has really influenced how we think and it’s trickled down to every single team. And I’m sure we’ll go into the specifics of how we do it, but that’s kind of like the big picture in terms of who our sponsor is.

Abi: Compared to a lot of organizations I meet and speak to, you’re in a very enviable position, having that C level buy-in and commitment to developer experience. I mean, not really going into Rajeev’s personal background, but for organizations, leaders, I mean, you yourself are an engineering leader. What do you think it takes to get to the point where you feel similarly about the importance of developer experience?

Preeti: This is definitely something that I’ve thought deeply about, right? I go talk to my friends who work for other organizations and I talk about, hey, this is a company level OKR and we are actually dedicated towards this. And that’s absolutely, you’re right, it’s atypical. So when I asked myself, so how do you pitch this? I think all teams inherently know what the problems are. So I think of it as two things, right?

You need to, if I am building a business case for something, which is what this is, you need to have some data. You need to use data to back what you’re talking about. So those key insights, how do you get insight that tells you what your problems are? And the second part of it is to be able to project the impact of investment here. So I think that’s the key, being able to get all of these insights, pour through them, get all of your insights.

And again, this has to be a combination of both quantitative and qualitative metrics, if you will, right? To me, I personally think that you can do everything. You can have the best DORA metrics that you want, but if the culture and the perceived experience isn’t great, that’s not sustainable. And so it’s both. And so as leaders, what we need to do is to deeply understand what the problem is, and be able to quantify why we want to address it. 

At Atlassian, what we do is we use the power of our tools. And so we track, we have a pretty good nomenclature around work categories. And so I can easily tell how much am I spending or investing into this area. For instance, if my operating cost goes up, then I’m able to have a conversation and talk about why is this happening and what can we do to make this better, right? So that’s where I think insights and data really help.

Abi: Yeah, I echo what you’re saying just as far as, you know, in our early research into developer experience, one of the things we looked into is why is developer experience so poor at so many organizations and what we found and heard from developers was lack of awareness and not just lack of awareness, but inability to quantify the problem. If you can’t quantify the problem in business, it’s hard to get investment in the problems that you care about. Which leads me to the next question and it’s around investment. I don’t know the ins and outs of, we’re gonna talk about DevEx at Atlassian today, but based on Rajeev’s article, it seemed like there’s significant investments being made. There are dedicated teams, platform teams, working on tooling. Product teams are given 10% of their time to tackle these problems. I wanna talk about that more later. 

But my question now is, how did you all arrive at this level of investment and how do you justify?

Preeti: That’s a great question, Abi. So, you know, once, so I want to sort of go back to how it all started in our initial learnings. So once we identified the three categories of problems, right, we talked about friction, lack of autonomy, and then fear of breaking things. 

So we were definitely inspired by Dora and space. And one of the things that we decided early on, we knew that we had a few key metrics that we needed to look at. So we looked at PR cycle time, time between commit and hitting prod or deploy. We looked at self-service documentation and then self-service dependency maintenance. So we had this quantitative data. And right away, we knew we also needed to get that qualitative data from our developers. So our first survey went out in September of 2022, our developer satisfaction survey. We went out and asked our developers, how satisfied are you with your productivity, right? That’s our developer satisfaction score.

What we found was that we were just under 50% in terms of developer satisfaction and that just wasn’t good enough. Like our goal is to be a world-class engineering organization and we are in the business of empowering and serving developers. And you know, we knew we had to start right at home with our own development community. And so with this learning, we put together a whole developer experience program.

And so that’s how it all got started. And part of that developer experience program, the thing that I love about it is you have the centralized perspective about what Atlassian is doing to improve developer productivity and the centralized investments into platforms and frameworks. That makes a lot of sense. What I think we do really well is giving localized control and autonomy back to teams. As an engineering leader, I can choose how I invest my 10% and what impact that’s going to have. And I think that’s where the results that you are talking about, we have evidence that this investment pays off. For instance, to give you some stats, right? One of the things that we’ve observed is that we have a 90% reduction in time that it takes for our share, for changes in our shared services to make its way to our biggest products.

And that’s a direct outcome of our investment into developer experience. I have a few more stats that I can share, but kind of big picture. That’s how we are thinking about the investment into dev productivity or dev experience and the outcome that we are seeing from it.

Abi: First of all, we’re gonna double click back onto the 10% time, because I think that’s so key in achieving success and improving productivity. But I wanna double click on this current topic. How do you arrive at the level of investment that you have? There’s certainly measurements, insights you’re gathering from your developers telling you we’re not where we wanna be, but how do you arrive at the specific number? And I guess the answer may not be that there’s a formula, it may be more about philosophical alignment. So yeah, is that what you would say it kind of boils down to?

Preeti: Yeah, at the end of the day, we have to build features. We have to provide customer value that is a direct value, and that’s part of it. And then we also have the cost of running the business that we have to account for, right? This is something that we are all familiar with, your tech debt operations and all of that. And so we came up with the 10% number as a reasonable way of starting this investment into developer productivity, a team might choose to do more because they know that this investment is going to have huge payoffs. Absolutely, they can invest more than 10% if they need to. So this is like a guideline, a ballpark. And so it’s a combination of both this autonomy with using this 10% and accountability towards what this 10% investment does for us.

Abi: That makes sense. And we’ll come back to this again later. Uh, I want to now dive really tactically into how Atlassian tackles developer experience and developer productivity. I mean, you’ve shared this conceptual model, the three buckets, the way you think about this problem broadly. But I mean, how is developer experience really defined at Atlassian and how do you talk about it internally to your organization.

Preeti:  Yeah. So look, I think developer experience is really about how you feel as a developer on a team, right? What frameworks do you have to support your lived experience as a developer? What tools do you have? How empowered are you to do things, right? And at the same time, experience is also this broader definition. Engineering culture plays a big role in what your experience is as a developer, right?

So we have really strong company values, which I think make a big difference. And then our engineering culture and the type of leadership that we have across the organization, all of this makes a difference. And so when we talk about surveys and culture, yes, we are talking about developer productivity and developer joy. An equally important parallel to that is just team help, right? And I think one part of it is just having as a developer, as an employee, I want to have clarity around why is my work important? Like, why am I even doing what I’m doing? Right? And so we always ask our teams, do you understand how your work fits into the larger ecosystem of Atlassian? Do you know which OKR you’re contributing towards? What about team connectedness? And so we ask all of this for the health part of it.

And then we have the developer satisfaction survey, right? So all of this goes into defining developer experience. And what we want is we define it as returning value back to engineers. And what is value, right? It is this lived experience of developers, it’s time saved efficiency, and it’s the ability to build reliable code, high quality code at speed, reduced fiction and being able to stay in your flow state. I think that’s the one thing. With organizational complexity, it’s so easy to go down a rabbit hole. I go and I search for one thing, and before I know it, I’ve spent an hour just going through various interrupts, right? And then my flow state is gone. So anything that we can do to minimize this, that’s all part of developer experience.

Abi: I love your definition and I was just having a conversation earlier today with a leader who described their job as providing a capability to developers. The product of developer experience platform engineering leaders is providing capability and your definition is equally eloquent. I want to ask you, these definitions you’ve shared, is this something that is concretely defined within Atlassian?

Are these definitions, is this charter, concretely defined - or is this still something that’s a little bit in people’s minds, a little bit nebulous? And the reason I asked this question is so many leaders that I talked to spend months, sometimes even years defining and redefining what their charter is, what developer experience means within their organization. So I want to kind of ask you, is this kind of an evolving work in progress thing at Atlassian or do you feel like you guys have arrived.

Preeti: I feel like the definition is broad enough that you can apply it to different phases and pieces of work that you do. As a definition, I would say that we have a pretty strong alignment and understanding across the organization of what we are talking about when we say developer joy. That’s the top level OKR that we have for the company. And then if you go a level further, you have different metrics and different bodies of work that feed into this.

And that’s the part where I expect that will evolve over time. And to be completely honest, right, we are at the beginning of this journey. I would not say that we have solved it, but as an open company, being in the, and you know, our work is around development teams, right? I mean, our mission is to unleash the potential of teams. And so we just felt that it was fair for us to talk about this, to talk about our journey, our learning, we are far from having solved everything.

But I think we are doing a great job in that journey of discovery and implementation here.

Abi: You’ve already touched on this, but how you all measure developer experience, developer productivity and Rajeev’s article he listed, you know, several different metrics. You’ve touched on them already today, including your survey program, but can you take us through the journey? I’m sure you all didn’t wake up one day and said, Hey, these are the five or six things we’re measuring. I’m sure it was a process. What’s been the journey and the debate, the work to get you to where you are today?

Preeti:  I think it’s good for us to sort of talk about the program itself, right? So once we got this developer satisfaction score and we knew that we had to do something about it, you know, we spun up a program to go understand what needed to be done. That’s where the surveys came in. Basically, we came up with a three-part framework, right? The first one is building awesome tools. We really want to give our engineering teams awesome tools that they can use to improve their day to day lives. 

And in fact, my team that I work for Compass is a product of this investment. With the explosion of microservices, just organizational complexity, right, like team topologies, we talk about just how complex it is when you have dependencies and the communication overhead of going across teams. We felt this pain firsthand ourselves in our development journey. And we came up with a homegrown tool, which is a precursor to Compass. We saw that, you know, and then we realized that it’s not just us, our customers have the same problems too. That’s kind of the genesis of Compass and is one of the stories around awesome tools and that layer of investment. And then the second part of that framework that we came up with is empowered teams.

This goes back to that lack of autonomy, right? And so basically what this allows you is to empower our teams to go make changes. And I’ll give you an example. The Confluence team invested as part of Empowered Teams. They made an investment so that, you know, when they started out, only 12% of their changes made it out to prod within 48 hours. By in just one quarter, with a different set of investments, they bumped this number up to 32%. And this was all part of that empowered team bucket of work that they took on. And finally, the third bucket that we have is to foster an amazing engineering culture. 

This is where we spun off this Developer Joy Champion program. So this Developer Productivity Champion Program has participation from every engineering team. We learn from each other and we sort of talk about best practices and how can we do better. In fact, the papers that you publish, the things that you talk about, this is part of what we discuss and you know, where we are constantly watching for what’s happening in the industry around us. We want to learn from other companies and we also recognize that we need to be able to apply our own unique flavor of that learning to meet our teams where they are.

Abi: I want to ask you more about this Developer Productivity Champions program. Sounds like it’s a group of people, leaders across the company, getting together to disseminate or synthesize different best practices. How does this deliver back? How does this deliver value back to the teams?

Preeti: So this Developer Productivity Champions Program is one where, like you said, we have a central team who’s running this program, and then we have participation from across all of our engineering teams. So in addition to learning and sharing best practices, this is where this team champions all of the centralized changes that need to happen. For instance, local dev loop, right? Going back to what we measure and the metrics that we measure. So we actually measure issue cycle time instead of PR cycle time. And the reason behind that is that your local dev loop is such a huge part of where our devs spend their day to day, right? And friction in your local dev loop is a lot harder to quantify or to, you know, get metrics and analytics around. And so we started measuring issue cycle time. So from the time that your Jira issue moves to in progress to the time that it’s closed.

And of course, that includes PR cycle time also, but it gives us that insight into what we want to fix. And so as part of the centralized developer productivity champions program, one of the things that they’ve championed is investment into remote development environments. So that really helps minimize that friction that devs have with their local dev environment. Another example is around supporting mocking for shared services so that your local dev group is just a little bit faster than it used to be. And so the way that this program works is that they identify and fund centralized investments. And then the learning is disseminated into our engineering teams for localized changes. And for instance, you know, testing methodologies. And you might have a way of approaching flaky tests. I might have a way of doing it. How can we learn from each other and, you know, get better together?

And this group also sponsors our innovation programs, like our hackathons. We have a very active culture around innovation with our ShipIt hackathons. And just last time when ShipIt ran, we had over 160 submissions from developers towards this developer productivity. I think that’s a great example of how much we care about it and how much we enjoy contributing back and making our own lives better.

Abi: Just how well you’re able to catalyze this mission of developer experience across the organization. It’s really interesting. I want to ask you about a couple specific metrics that are mentioned in Rajeev’s article that I haven’t heard of as much. So in this article, he mentions self-serve documentation and self-serve dependency maintenance. What are these metrics?

Preeti: Yeah, so self-serve documentation. I think this goes back to how software engineering has evolved over time, right? Today, you can think of code also being assembled rather than everything being coded up from scratch. So you have a ton of dependencies, both internally and open source dependencies externally. And so what happens when you are a distributed team across time zones?

And let’s say you have to integrate with the identity system. And you’re figuring out just how do I do this integration? First of all, where’s the documentation? Who owns this thing? Where is the Slack channel if I have specific questions? Is there any sample code that I can really use, right? And so when you just think about documentation, there are so many different aspects to it. And we found that this was something that was getting in the way of developer satisfaction.

And so this is part of our survey. This is a quantitative metric. We basically ask our developers to tell us how often they’ve had to look for documentation and what was the outcome of that. And then we have a formula to compute that into a number. And that’s kind of our baseline towards self-serve documentation.

And it’s something similar for dependency maintenance, right? I mean, again, open source, we have to keep up with those dependencies. You don’t want to wait too long to upgrade it. And so, you know, how can we make that? And in most cases, it’s just a matter of a simple update. You know, you just bump your version and but you still, a developer still has to go and do this, right? So how can we make that easier? How much can we automate that? So it removes the toil and the interrupts from your regularly scheduled sprint work. So that’s kind of how those two metrics line up.

‍Abi: That makes sense. And yeah, I expected that those were probably referencing qualitative or survey-based metrics. So I’m glad my assumption was correct. I want to ask you about qualitative metrics and how Atlassian is surveying its developers. I’ve heard a lot of things from the outside about surveys at Atlassian. I’ve heard some people tell me there’s a monthly program. Others have told me annual. Sounds like maybe there’s multiple survey programs going on. 

So in terms of developer experience, what is the survey program? What’s the cadence? How long is the survey? How do you guys run it?

Preeti: It’s a monthly cadence. We ask our developer experience surveys go out every month in addition to our team’s help. It’s just one survey that goes out every month. It’s a standard set of questions. And really, the idea is that it takes about five minutes at most for someone to fill this out. And of course, survey fatigue is real. That’s something that we all experience. And so we’ve experimented with different cadences and we’ve landed at the one month cadence and that’s been working very well for us.

And the way we kind of combat survey fatigue is we have these really well established team rituals. So what we do is when the survey comes out as a group, we just take the first five minutes of a standup for instance, to just all do the survey together. So it’s not something where, you know, your manager has to go send you a nag message to go take the survey because obviously this is all anonymous. So we don’t know who’s taken the survey and who hasn’t. So rather than, you know, at here and at channel all the time.

We just do it together as a team, and that’s really worked very well. And because we have consistent data coming in, it allows us to see trends and spot problems. And what I’ve observed is the problem areas evolve and shift as your team goes through various phases, right? And the thing that we do is in addition to just having this data from surveys, we also have some well-established plays that we have at Atlassian. So we have health plays around, How do you engage your team to come in and look at the survey result? As a team, identify problems, identify areas where you want to invest and improve things. And we’ve seen this. So once we’ve invested in a particular area, we’ve seen that area of the score better. And then we identify a different area for us to focus on.

Abi: And just to clarify, when you say a play, is that referring to like an internal guide on how to do something?

Preeti: It’s public actually. Atlassian has these run books or plays that we publish and this is like a health monitor play and then we have, yeah, so that’s kind of how you get the team engaged in this process.

Abi: That makes sense. To recap for listeners, it sounds like a two-headed parallel approach. You have the local teams going through their own results, figuring out what they can do at sometimes escalating things as needed. And then you have the centralized teams looking at the data across the organization to prioritize their investments. 

Another question I want to ask you is around this process you have, where teams do the survey in standups. Survey fatigue, participation rate – huge struggle for a lot of organizations that run surveys. How have you been able to actually implement that? I mean, again, is this something that’s just been championed from the CTO level down and has that driven it to a lot of companies? I think the process you were describing is quite far-fetched, unachievable.

Preeti: Well, to be honest, I think, you know, if you ask me to do a survey every month, and I see no changes coming out of it, nothing changes, then that naturally kills my appetite to go respond to that survey, right? So I think it’s a combination of not just asking people to tell us what’s going on, but also following that up with a conversation where the entire team is empowered to talk about

This is the problem area and here’s why. And then we talk about, okay, let’s make this our goal. Let’s pick one or two things and how do we address it? And of course, there is a desire to have high participation rates. And I’ll be honest, some months we have lower participation rates than others and that happens. But I think this is an ongoing conversation and ultimately in order to engage your team with participation, they need to see results.

Abi:  Absolutely. I want to also ask you about the centralized teams. We just talked about how, in addition to the local team improvement, there’s centralized teams tackling things that are cross-cutting. Can you paint a picture for listeners of what that investment looks like? I mean, we’ve talked about the 10% for the local teams. What percentage of Atlassian’s engineering organization is focused on those types of centralized investments and what are some active projects going on today?

Preeti: I don’t have a metric for you in terms of the percentage of investment that we have from centralized teams. But in terms of some of the projects that these teams are doing, right? So it’s things like optimizing remote development environments, really looking into what metrics matter, what metrics make sense for us to be measuring and going towards and investment into frameworks and the Atlassian platform itself and how that can drive change across all of our product teams. Those are some of the examples that I can think about. Optimizing our development flow, removing friction just in our pipelines and making it easier to consume. Like the self-service documentation, for instance, is something that the centralized team is championing and dependency maintenance and coming up with automated processes around that. Those are all examples of centralized investments that we are making.

‍Abi: Awesome. I want to come back around now to the 10% allocated to local teams to be able to improve areas that they choose. Because again, this is something I see as pretty remarkable. A lot of organizations I talk with are really struggling with making this leap. How did this happen? In Rajeev’s article, he mentioned that this wasn’t something that always was the case. This is something that was determined based on feedback and information you’d gathered. 

‍So share with listeners that journey and the internal debates, maybe pushback concerns along the way. How did you arrive at that 10% number for Teams?

Preeti: So I think it all goes back to what’s our goal, right? Our goal is to be a world-class engineering organization. And if you sort of start unraveling that, what does that really mean? And how can you achieve that goal? I mean, absolutely, we have to meet the needs of our customers. We want to deliver business value to our customers, and that’s our priority. But once you start asking yourself, about the how and what gets in the way, then it’s really clear that there are these other investments that you can make that pay out in the long term, right? For instance, we have about a 300% improvement in deployment frequency for some of our shared services. Now, this has ripple effects. It’s a shared service. So that’s going to influence and impact everything else that uses this, right? 

So you’re right, it wasn’t always the case. But we wanted to meet this goal. And once you start talking about the, how do we do this? It’s a balance between investing into business and features and, you know, the things that we absolutely love doing and we really enjoy doing. And at the same time, recognizing that how our developers work is equally important and we need to make those investments now to optimize how we do things.

Abi:  And how is this actually actualized? Because another pattern I see sometimes is, you know, leaders talking about, Hey, teams are autonomous. They can be spending as much time as they want fixing technical debt, et cetera. And then you talk to the teams and they say, we don’t have any, we don’t have permission to do that. We just have to hit our product. And so I’m curious, how do you all actually practically actualize that principle or is product management fully on board with that or… how does that work?

Preeti: Yeah, the thing that I love about Atlassian is this great trust across crafts, right? We work really well across crafts, product management, design, engineering, and all of the other crafts that play a huge role. And we all work collaboratively and together. And so absolutely all of our other crafts are also bought into this. And so when we save 10%, we budget 10% in our roadmaps for this work. It’s not do everything else that you need to do and figure out a way to make this 10% happen from somewhere else. There’s no hidden box of things where we pull it out from and this is all out in the open and discussed and collaborated upon. So I think that’s a key part of it. Like you talked about that buy-in from across the organization. And so I think part of this is also accountability, right?

It doesn’t work if I say, yes, I’m going to invest 10% in developer experience, but then at the end of the quarter, I’ve, you know, as with anything else, you run into problems, unknowns come up. And so you’re like, I had to meet this deadline, therefore I couldn’t do this, right? And so what happens is accountability. And again, I don’t think there is a right answer. You have to do what’s right for the business, but your intention and planning should focus on

Don’t take up 80 or 100% of feature related work and then assume that it’s 80% and then say, okay, I’m gonna try and, it’s not a best effort, right? We commit to it, it’s intentional, the 10% investment. And then part of it is accountability. So we have this really good way of tracking our work and how we do it. We have this well agreed upon taxonomy in terms of how we categorize the work that we do. Of course, this happens in Jira.

We use Jira labels to do this. And this ties back into the three categories, in the three part framework that we have for developer productivity. So it’s awesome tools, empowered teams, and amazing engineering culture. And then in addition, we have work that we do towards changing the business and then running the business. All of our tickets are labeled and categorized. And then we use Atlassian Analytics to get insight into how we are investing our time.

That’s of course real time and that helps us understand how we are doing as a business and then what do we need to do? And the accountability part of it is where we come in at every quarter and we review our investment commitment and how we did against our commitment.

Abi: I love the piece around accountability, especially because it’s without that feedback loop of checking back on whether you’ve actually done what you’ve said you would do, it’s hard to stay true to those principles. 

I want to now turn the focus to Compass. Of course, you’re the head of engineering of Compass. I wanna start with the backstory behind this new product at Atlassian, because as I understand it, this has been something that’s actually been an internal tool at it lasting for a very long time. You touched on this earlier, but take listeners again, through the story of where this idea even began and the journey to building it.

Preeti:  Yeah, so you know, when we started our own transformation to be a cloud-first company, right? We were in a position where we had more services that we owned, we went through this microservice journey and we’ve grown. Atlassian has had a period of tremendous growth with people, with products, and we were one of the first companies to be distributed first even before COVID, right?  

Once you add all of that complexity in, I think we had this going on all the time where there would be an incident and it’s like, okay, I think this incident is in this particular service, so how do I reach this theme? Or maybe it’s not even an incident, you’re trying to use a service and you don’t know what needs to be done. And so we built a homegrown tool just to catalog all of our services and to put in all of that critical information that you need. And we had a number of other homegrown tools that we built over time. And then we also realized that this is a problem that our customers have. And, you know, we figured out a way of solving it for ourselves. And so that’s how we decided to productize and build Compass. And that’s our journey. And, you know, it’s really awesome to be working as an engineer.

I think there’s a special joy in working on a product that solves the lived problems that our key personas have. And so it’s been an incredible journey to be here and to be able to talk about Compass as a GA product.

Abi: Compass is, I’m not sure what product category to put it in, because it’s sort of a still emerging space, at least in my view. So for listeners who aren’t familiar with what Compass is or even tools like Compass, give a quick rundown of what Compass does and who it’s for exactly.

Preeti: Compass is a developer experience platform. You know, you hear this go by multiple names: some people call it a developer experience platform, it’s also referred to as an internal developer portal. But essentially you’re talking about the same thing here. The problem that we want to solve is that developers are spending far too much time trying to find the information that they need to do their job.

So this is where a developer experience platform makes a big difference. In fact, Gartner predicts that by 2026, 75% of engineering organizations will have built an internal developer portal. So Compass is meant for all engineering teams. And there are four ways in which Compass helps. So I’ll call them out and then go into a little bit more detail about each of these different pillars.

So at the heart of it, Compass is a centralized component catalog. We then have health and scorecards. We also have software templates. And then finally, the last pillar is extensibility. Compass really empowers developers by giving you a centralized component catalog with all of the relevant information baked right into it. So, you know, if you look at it this way, your team API is baked right into your component catalog.

And then with health and scorecards, we give you insights into the health of your architecture, your component, your team, and this really goes a long way in giving you those really important insights. With software templates, you now have a way to have consistency across your organization. And finally, we recognize that we really believe in the power of an open tool chain. And so Compass has been built to be extensible from the ground up.

So, you know, all of our APIs are public. You can use the Forge platform to extend Compass. And ultimately, we are built on the Atlassian platform, and we have deep integrations with Jira service management and Jira software. What this gives you is this way to bring developers and IT closer together to solve problems that our teams have.

Today, we are really excited to introduce Compass, and we have a number of customers who already use Compass. Companies like Dropbox, KFC, UK and I, ExpressVPN, Borden, all of these companies use Compass to improve their developer experience. And we’re really excited to bring it and share it with all of you. Finally, I want to touch upon pricing. The component catalog is free for all users.

Now, that’s a pretty generous free tier and you get a lot of value out of Compass from Day 1. And the standard offering is at $7 per user for these enhanced capabilities. And really, if you look at it for 100 developers, you’re looking at about $700 a month. And this helps you empower your teams and really build and invest into that developer experience that we’ve talked about today.

Abi: It sounds like Compass is a powerful platform. I want to ask you a question about your experience leading the engineering side of it. Just earlier today, I was talking with a platform engineering team leader, talking about the challenges of building an internal facing product within the company. In your case, you have an internal facing product that also now has external customers. How do you navigate that balance of serving your internal customers as well as the external customers at the same time? 

Preeti: Atlassian is an important customer for Compass, and that is absolutely something that we prioritize. And ultimately what we found is that what we need internally is also what our customers need. And so there is this blend of us being able to meet the need of Atlassian’s. And because Compass is extensible, we have over 15 customizations and extensions that we have today with Compass. So you can see this really empowers our teams to go to extend companies to meet their needs.  

Abi: Well, thanks so much for the overview, Preeti. So many listeners of this show are interested in developer portals or maybe even trying to build their own. So if you’re listening, I highly recommend going and checking out Compass on Atlassian’s website. Even if you’re trying to build your own right now, I think there’s a lot of interesting principles and learnings to gather from your journey. So highly recommend it. 

One final question I have for you with Compass is, when you look at the landscape, there are a lot of organizations that are approaching this problem in different ways. I know when I worked at GitHub, we built our own pretty primitive service portal, service catalog internally. 

What does Compass offer in your view that’s unique and different from the alternative ways organizations can tackle this problem?

Preeti: I think at the end of the day, we all recognize that there is a problem here that we need to address, right? It’s an emerging market. Gartner predicts that by 2026, 75% of organizations will have invested in platform engineering. So when you go about it, or, you know, they predict that 75% of organizations will have an internal developer portal. So when you go looking about it, I mean, definitely you can build, and this is your classic build versus buy conversation, right?

And so what you need to factor in is the upfront costs, you know, your ongoing costs, you know, if you want to self-host something, you have to develop it, you have to maintain it. And then the question becomes, where are you providing the best value for your development teams? Is that in building and maintaining a homegrown tool, or do you want to go take a SaaS product so that you don’t have to be in the business of maintaining and running it, right?

And this is where a solution like Compass really makes a difference because it’s easy enough to get started out of the box. It integrates with all the other Atlassian products and it’s built on the Atlassian platform. So you can leverage the benefit of integrations with Jira software, with Jira service management, and it’s built to be extensible. So I think that’s the question. That’s the question I would ask is to figure out where do I want to invest my time and energy? Do I want to get started delivering value to my development teams through this developer experience platform? Or does it make sense for me to build my own?

Abi: Preeti, thanks so much for sharing Atlassian’s journey with developer experience. I love the way your company is thinking about this problem. I love that you’re sharing your learnings publicly along the way. And I love this new product that you all have launched to help other organizations on their own journeys. Thanks so much for coming on the show today. Really enjoyed our conversation.

Preeti:  Thank you, Abi. It’s been great to be on the show and to talk about it. So thank you for having me. And I look forward to our integrations with DX. I think the qualitative part of it is something that I’m really excited to bring into Compass.