Hear RedMonk’s Kelly Fitzpatrick chat with Andrew Boyagi, Head of DevOps evangelism at Atlassian, about the critical topic of developer experience. They discuss findings from Atlassian’s 2024 State of Developer Experience Report, highlighting the importance of understanding developer satisfaction, productivity, and the misalignment between developers and their leaders. Andrew emphasizes the need for open communication and the role of AI in enhancing developer productivity. The conversation also touches on the concept of ‘Developer Joy’ as a key objective for organizations to improve developer satisfaction and overall productivity.

Disclaimer: This episode of the MonkCast is sponsored by Atlassian

Links

• Atlassian’s State of Developer Experience Report 2024
• LinkedIn: Andrew Boyagi
• x/Twitter: @Andrew_boyagi

Transcript

Kelly Fitzpatrick (00:12)
Hello and welcome to this RedMonk conversation on developer experience, a topic very near and dear to our hearts at RedMonk. My name is Kelly Fitzpatrick and with me today is Andrew Boyagi, head of DevOps evangelism at Atlassian, who joins us from Sydney, Australia. Andrew, many thanks to you for navigating the time zone logistics to join me on the MonkCast.

Andrew Boyagi (00:31)
All good, Kelly. Thanks for having me.

Kelly Fitzpatrick (00:35)
And to start us off, can you tell us a bit about who you are and what you do as head of DevOps Evangelism at Atlassian?

Andrew Boyagi (00:42)
Yeah, apart from having an awesome title. So I’ve worked at Atlassian now for the past two years, as you say, as the head of DevOps evangelism. In my current role, I work with a whole bunch of Fortune 500 companies around the world on topics like developer experience, developer productivity, and platform engineering. A lot of the conversations we have obviously leverage the work that do at Atlassian, but also some of the things I did before joining Atlassian.

Kelly Fitzpatrick (01:08)
Yeah, and I feel like your areas of concern overlap with a lot of what we cover at RedMonk and what I have interest in. I am so excited to speak to you today. And our topic is developer experience. Atlassian recently released its 2024 State of Developer Experience Report based on a survey of developers and engineering leaders. I have had the chance to read it and there are some interesting findings. I think we could talk about this for hours. But for folks who have not had the chance to read it and don’t have hours to dig into it, Can you give us a of a TLDR on the report itself, what Atlassian was hoping to find with the research and where does the data come from?

Andrew Boyagi (01:44)
So there’s huge amounts of academic research that show that happy workers are productive workers and developers are no different. So by running this report, we really want to get a fresh look at how people are thinking about developer experience

And there are a few things that we wanted to learn about. One was we wanted to obviously understand the state of developer experience across the globe. We wanted to find out what’s working and what’s not working when it comes to developer experience.

And we want to take a look at the future of developer experience, including topics like AI. So we partnered with DX who provide a developer insight platform and with some research partners called Wakefield. And we surveyed 1 ,250 leaders and 900 developers across the US, Asia Pacific, and Europe to get their takes on developer experience.

Kelly Fitzpatrick (02:32)
And I think that’s a good amount of both engineers and leaders there. And as I said, I think there’s a number of takeaways in the report. One of the ones that really jumped out for me, which reflects what we’ve been seeing in the industry at large, is that terms like developer experience, developer productivity, and developer satisfaction often get kind of thrown together and mixed up in ways that I think developers especially may not always be happy to see. What are your thoughts on these terms and how we should be using them?

Andrew Boyagi (03:04)
Yeah, I’m really glad you brought this up because I see the same thing in conversations I have every week. So if we think about some of the definitions to start with, developer experience is really about how engineers think and feel about the tools and the frameworks that they use to deliver software within an organization. And it’s particularly focused on points of friction that they encounter when building and shipping that software. Now, productivity is interesting because if you look at the traditional definition of productivity,

It’s output over time. It’s how much are you getting out over a given period of time? And that’s awesome for manufacturing, but building software and digital products is very different to that. It’s more like an art form than a manufacturing process. And I think, well, I know we don’t actually want productive developers by that traditional definition. So if you take a look at the report and you see what’s the most common way people are measuring productivity, it’s by the lines of code.

Now that actually aligns with the traditional definition of productivity, because that’s just an output measure. And as I said, we don’t actually want productive developers by that definition. What we actually want is high quality software delivered at speed, which translates to value for a business, because output doesn’t consider quality. And also with developers and their work, there’s a long term effect of that quality. It’s not so immediate like how we manufactured this thing. Now with satisfaction, the third term that you raised there, developer satisfaction and productivity for that matter are really outputs of a great developer experience. So if you think about what I said before, developer experience is focused on removing friction. Now you’d expect this improves developer satisfaction with their work. And those two things help developers be more productive. So all three are related, but they do get mixed up from time to time.

Kelly Fitzpatrick (04:56)
Yeah, they absolutely do, and to the point of the friction involved in developer experience, a term that at RedMonk we’ve been using for quite a few years now is the “Developer Experience Gap” to talk about some of the origins of that friction. And I think one of the other things from that whole kind of smushing together of terms in your conversation of it is the lines of code metric. Because I

very much feel like if you give developers especially something that they’re gonna be measured on like lines of code, the gamification of that is like, it’s so easy. You’re just being like, here, here’s a way for you to go and meet whatever metric we want you to have without necessarily producing quality code or you know, and the like.

So we’ve talked a little bit about some of my takeaways from the report. What are some of your key takeaways from the report?

Andrew Boyagi (05:42)
Yeah, there are a few key things that came out. So firstly, the most obvious one is there’s a huge misalignment between developers and their leaders when it comes to developer experience. And it’s highlighted in multiple areas throughout the report. So if you have a look at something simple like what are the top issues that are impacting developer experience, managers say it’s understaffing,

new technology and context switching, but you ask the engineers and they say it’s tech debt, it’s poor documentation and the build process that are affecting them. So at that high level, they disagree on what’s impacting developer experience. But the one thing that they are actually aligned on is that DevEx is important. So engineers say that developer experience,

impacts their decision, whether they stay or they find a new role. And for engineering leaders, they say a good developer experience is required to attract new staff and high quality talent to their organization. Maybe the second key takeaway is that understanding and improving developer experience pays dividends. So what we found through the data was time spent on understanding and improving developer experience correlates with better developer

efficiency. So that to me is pretty solid evidence that investing in developer experience is a good investment if you’re looking for happier workers who are more productive. And then the third major thing that stuck out for me was there are wildly different views on the impact of AI on developer experience. So again, another disconnect with the leaders. If you ask them, they say AI is the most effective way to improve productivity.

But when you look at the developers responses, two out of three developers are saying that AI isn’t having a significant impact on their productivity yet. So they’re the three major outcomes or the major things that I took away from the report.

Kelly Fitzpatrick (07:33)
Yeah, and going back to, your first takeaway about the misalignment between developers and tech leaders, like to your mind, where is this coming from? And I think that that almost affects some of your other takeaways too. So for instance, the different opinions on the role of AI in developer productivity.

Andrew Boyagi (07:51)
Yeah, like just on that misalignment, I think it’s so important for that alignment to be there because companies and everybody has a limited budget when it comes to improving developer experience. And I speak to a lot of companies who are genuinely trying to do that. But I see them investing in areas where it’s not really solving a problem for their developers. So, you know, when I speak to people and I try and find out, OK, where is this misalignment coming from? It really comes

from a few areas that I see. And number one is leaders are busy people. It’s always been that way. But in the current climate, they’re under pressure to get the most out of their team. And as a part of that business, I’ve noticed that retrospectives are actually on the decline between leaders and their teams. And so they’re not spending that time to go back and understand how things could be improved, which is unfortunate because retrospectives are the foundation of continuous improvement

for all matters, not just developer experience. I think that another common problem that I come across is that most engineering leaders were once engineers and they know in inverted commas what the problems are that their developers are facing. And so they don’t actually ask. So that’s another thing where they think that they know from the time when they were a developer what’s causing some of the problems. And then the final one is with actual engineers themselves.

So the way that they share problems with leaders and with their peers, a lot of the time this comes across as complaining, you know, this is so, or they kind of complaining about something. It’s really about how they frame the problem and how they describe the impact of that problem. So I think a lot of the time, if engineers reframe the way that they talk about problems and they describe the impact, they have a better chance of helping their leaders understand how to help them.

Kelly Fitzpatrick (09:44)
Yeah, and I think the like the common thread I see through through all of your kind of answers there is like it’s about perspective and it’s about framing. And I really like your insight into the engineering leaders who used to be engineers who think they know when in 2024, building software is different. It’s just fundamentally different than it was just a few years ago. So another question for you, from your perspective.

And I mean, your perspective encompasses not only the findings of this report and your current experience at Atlassian, but everything you’ve done before it and all the people you get to talk to. In 2024, how do we actually go about improving developer experience?

Andrew Boyagi (10:26)
Yeah, so the answer is really easy, I think. You just need to speak to people as a first step. So the first thing I recommend is speaking to developers and understanding from them directly verbally using actual words, maybe on zoom or in person. You know, just ask them a simple question. How could we improve the way we deliver software here? I spent a few weeks doing that in a different organization and

Over those two weeks, I got so many, so many rich insights about how we can improve things. I was expecting to hear a lot of complaints about tooling, which I did get, but also there was a lot of feedback about the processes that we use and the way decisions got made. And so, you know, we walked away from those two weeks with a two year backlog of things that we could improve on. But obviously speaking to people doesn’t scale when you’ve got thousands of engineers to look after.

And so that’s when you bring in surveys, which are a great tool to, once you understand some of those finer points, you can use a survey at scale to further understand some of the issues that are impacting the developers. and then once, once you understand, you can come up with areas of focus. You can start measuring those areas of focus. So, in the survey, build times came out as a problem, you know, obviously you would start to measure build times, you’d baseline it, you come up with a potential way to help resolve that problem, play that back to the engineers that you spoke to, make sure it’s actually going to fix the problem. Then you fix it, remeasure, and the cycle goes on.

Kelly Fitzpatrick (12:03)
And it strikes me that some of those elements are really easy to measure, like build times, others such as insufficient documentation and tech debt might require a little bit more finesse in the measuring. But I love this approach of, A, talk to people, B, iterate on what it is that you think you’re trying to improve.

Andrew Boyagi (12:20)
Yeah, I mean, like obviously fixing some of the problems with developer experience that an organization is having could be a pretty lengthy process. So that’s not the easy part. But to find out what needs to be fixed, it’s as simple really as speaking to people.

Kelly Fitzpatrick (12:32)
And that all makes sense to me. One thing I learned from the report is that for Atlassian, developer joy is not just like a thing. It is an OKR or objective and key result. Can you please tell me more about this concept of developer joy?

Andrew Boyagi (12:49)
Yeah. So as you mentioned, Atlassian developer joy is a company level OKR, which is the top level OKR. There are different levels, you know, by company and different departments. This one is tracked by everybody and we track it very closely. Since we started tracking and having it as an OKR, we’ve seen a 25 % increase in developer satisfaction, which is a huge increase in such a short period of time. Having it as a company level OKR really does ensure that the goal is clear across all levels of management rather than it being just an engineering OKR where there’s something that they focus on specifically. This one is at the company level and so everybody can contribute to it and everybody sees the visibility on how we’re progressing against that. We speak about it all the time as well and it is a top priority across our business. So I’m a strong advocate of having developer experience or developer joy as a top level goal for an organization.

Kelly Fitzpatrick (13:49)
So talk about a company that is selling something that developers use, actually kind of modeling a way to help developers operate better. All right, so we are about out of time, but before we go, Andrew, how can folks hear more from you? Where can folks find you on socials and are you planning to speak at all for the rest of 2024?

Andrew Boyagi (14:10)
Yes, I’m going to be at GitHub Universe. I’m going to be at AWS re:Invent and at the Atlassian Team event in Barcelona. You can find me on LinkedIn. I’m very active on LinkedIn. So come along and give me some comments and share any feedback you’ve got.

Kelly Fitzpatrick (14:25)
Well, many thanks again to Andrew for a great conversation on developer experience. My name is Kelly Fitzpatrick with RedMonk. If you enjoyed this conversation, please like, subscribe and review the MonkCast on your podcast platform of choice. If you’re watching us on YouTube, please like, subscribe and engage with us in the comments.