"You gotta use data. You're going to have these feedback loops from developers, each team, each manager, each business unit, each organization, and the only way I believe that you can get a clear picture of that is be able to see that data."

Is your company relying on surveys alone to bridge the gap between developers and managers?  

In this episode of Dev Interrupted, host Ben Lloyd Pearson and Dan Lines, COO of LinearB, dive into the perceived misalignment between engineers and their leaders on improving developer experience. Together, they emphasize the importance of data-driven insights over relying solely on surveys, highlighting how quantifiable metrics can illuminate issues like technical debt and build times.  The conversation also touches on the power of setting clear, company-wide goals to boost developer experience and productivity.

Next, Conor Bronsdon, in his final episode as host, sits down with Andrew Boyagi, Atlassian's head of DevOps Evangelism. Andrew brings a wealth of knowledge on developer experience, emphasizing the need for transparency, the nuances of measuring productivity, and the crucial role of company culture in aligning development teams with business goals.

Show Notes

Transcript

Ben Lloyd Pearson: 0:07

Welcome to Dev Interrupted. I'm your host, Ben Lloyd Pearson, and joining me today is Dan Lines, LinearB's COO. Today, we've got a great conversation with Andrew Boyagi. He's the head of DevOps Evangelism at Atlassian. And this conversation is actually the very last conversation that will feature our host, Conor Bronson. he's since moved on to a new opportunity. you want to learn more about change and more of the changes that we have planned for Dev Interrupted, I encourage you to go. Back to the last season and listen to our holiday episode where we cover some of the the changes that are happening here. in a moment, we'll play this conversation between Conor and Andrew. But first, Dan, I wanted to bring you in to break down some of the topics that they discussed.

Ben Lloyd Pearson: 0:51

One of the things that Andrew said in his interview was that there's this misalignment between engineers and their managers on how to improve DevEx. So in all the conversations that you've had with engineering leaders out there, like, do you sense this misalignment?

Dan Lines: 1:06

Actually, that's pretty, pretty funny. I do not sense the misalignment. But I'll, I'll tell you why, and I think I know why. If you go out and let's say you do a survey and you ask a bunch of questions to many developers and many managers, you're going to get a ton of different answers. the thing is, all they're saying is actually the exact same thing, but from different perspectives, is the best way that I'll put it. Now on the flip side, with our customers, with LinearB, the engineering managers and developers that I'm interacting with, they're all utilizing data. They're using, data to measure productivity and then to improve productivity. And when you utilize data to do so, it's actually a universal language. There's no misunderstanding or misalignment. So for example, if you're thinking about something like, okay, you know, hey, We want to improve our developer experience, or we want to get more productive. Actually, managers and developers want the same things. They want to streamline their code to production. They want to ensure that they have the right investment balance in technical debt versus new feature delivery. They want to deliver their projects in new value on time. And they both want clear expectations of what it takes to grow a career. They actually want the same thing. Now they might verbally express that differently. That's the trouble you'll get with like a survey. but no, actually like the customers that we're working with, since we're more, I would say like data centric, they're actually pretty aligned on what they're looking for.

Ben Lloyd Pearson: 2:50

Yeah, it's, I mean, it's a great way to put it. everyone just wants to build new awesome things, but to get there. You know, you got to make sure that you're investing into DevEx and to keeping the lights on and to maintenance because, you know, that keeps your developers happy who in turn build better products, one thing that really stuck out to me was, Andrew mentioned that when Atlassian surveyed their developers, they got so much feedback that it could take him, he said like up to like two years to dig through it all, which is a little wild. and he mentioned that a lot of that data was also, process related. So how is an engineering manager, supposed to manage all of this feedback from their developers?

Dan Lines: 3:27

mean, again, here's the thing, like, if you're sending out a survey, it's a very, like, academic, let's say, academic questioning of what's happening with your personal experience, and you go and do that for a hundred, It's not even developers. Let's just say people. You're gonna get a lot of information. Yeah, you mentioned that it would take them two years to sort through the data to find actually what is the real problem and what You know, should we do next, let's say, to improve productivity? Now, when it comes down to the engineering managers, and maybe you start talking about things like feedback loops, there's actually a lot of good feedback loops, I think, already built into the engineering practice and processes. Like, for example, most teams have an iteration retrospective. You're getting a feedback, Loop every two weeks or three weeks maximum. Most engineering leaders or managers have one on ones with their developers. You know, for us, we usually recommend once a week. I'm getting feedback all the time. I think the more important question is not around managing this insane amount of feedback, but more so getting everyone onto the same page. Again, I'm going to be more data centric and a data advocate. Let's look at the data. Let's see what the data tells us about what's going on. What's causing bottlenecks? What's causing planning accuracy problems? What's causing investment problems into DevEx? And let's see, does that relate to the feedback? Most of the time you'll get the answer of Okay, yeah, it's actually the data is describing it really well. Now it's more so a loop on what do we do about it. I think that's like, on the productivity side, at least the customers that we're with, you can kind of understand in a few minutes after using LinearB, where the bottlenecks are, the bigger question is, okay, what do we do now?

Ben Lloyd Pearson: 5:16

we recommend to a lot of organizations starting with Dora Metrics, you know, and I think that's one of the things I love most about it is they have this saying like, get better at getting better. You know, it's more about teams working together to get better and being empowered to be better together than it is about whether or not you have. enough feedback from your lowest level up to the highest level, so, diving a little bit deeper into these feedback loops. So, you know, you think about feedback loops as a way to, like, continuously improve environments. but that can be really hard to scale, right? Like, or some organizations like Atlassian look at surveys as a solution to scale that. But how would you, how would you recommend that engineering leaders scale like these, these types of feedback loops?

Dan Lines: 6:01

You gotta, you gotta use data. That's the thing. So you're going to have these feedback loops from developers, each team, each manager, each business unit, each organization. And the only way I believe that you can get a clear picture of that is be able to see that data. Again, I'll just go over the ones that I think are most important. You have efficiency, And Quality related data. That's more so what you were saying on the Dorametric side. You have Value delivery data, which a lot of people equate to Productivity. What value am I producing for the business? You can see that within Project Delivery. You have Resource alignment data, which is kind of that feedback loop of, Hey, we're not getting enough time. Focus on technical debt. You should know what percentage you're investing into technical debt and have an agreement with the business on what it should be. Everyone already knows that you're not investing enough into technical debt. That's been around since like the beginning of time since I've been a developer and developers have been voicing that in feedback loops throughout surveys or one on ones or whatever. It doesn't do anything. The difference is can you actually quantify it and then go to the business and say, can we make an agreement with you to say, At least 17 to 20 percent of our time is on technical debt. That's a good agreement. And then I would say the last thing on the feedback loop, again, it's on that career development. Are you looking at data? Is it very transparent of what it takes to grow your career from a junior developer to a developer to a senior developer to a principal engineer? And this is the one that actually, maybe I'll just take a minute to focus on a little bit more as it might even relate back to developer experience. If I'm progressing my career in a fair way, maybe I'm going to be having a good, it's one of the main inputs, I think, to having a good developer experience. Now, some of the complaints that I've gotten from developers at, you know, many size organizations is there's not a clear way for me to understand how to progress and developers that are a little bit more comfortable or articulate in how they can say how productive they were, seem to be advancing. And me as a developer, I'm trying to let my works, you know, speak. Maybe I'm a little more shy. So when you have like a developer coaching program that's data centric, again, I think that's kind of a, a fair way to do so. So, I would just say, yeah, there's a lot of different feedback loops that are already baked into the development process. We have those today. It's more so about, can we get on the same page about the data to actually improve?

Ben Lloyd Pearson: 8:42

Yeah, I think it, the way you describe it is a great job at drawing it from, you know, high level resourcing decisions, like deciding what things you strategically want to invest in as an organization, and then saying to your developers then, you know, we're going to establish working agreements around these priorities so that they always know, like, whenever they're working on something, does it fit within that, that strategic priority framework that. That you're giving them.

Dan Lines: 9:08

It always has to relate back. I mean, imagine going to a CEO and saying, we did a developer survey and the developers say we have a technical debt problem. It's like, dude, I, I already knew that. We've just, we've been talking about that for the last, last 10 years or eight years. Like it, that's not new information. A different way to do it is you go to the business. I'll use the CEO as an example and say, Hey, currently we have an 8 percent effort, investment effort in technical debt. I would like to move that percentage effort to 17 percent and because of that I can still give you a 50 percent new value. Delivery. But what it's actually going to do is decrease our change failure rate, which is very high right now. And it's going to make our customers happier. That's a better conversation.

Ben Lloyd Pearson: 10:04

exactly. to tie this to, to productivity a little more. So we've already talked a little bit about Dora metrics, and how, you know, I think one common misstep a lot of organizations make is they try to use Dora metrics to compare across teams. You know, when it really should be more focused on like a team saying, we're gonna work together to solve our priorities. so how do you view something like DORA metrics fitting into the overall productivity picture? Because I, I personally hear constantly that DORA doesn't measure productivity, which I think is probably right.

Dan Lines: 10:33

So here's what I would say. First of all, with any metric that you use, it's probably highly risky to compare that on a per team basis. So, whether it's like, the Dora metrics or amount of story points delivered, anything that you're going to compare on a team by team basis, I think there's like a lot of nuance and context on a per team basis that needs to be applied. So for us, when we're working with our customer community, we don't do that. Now, for your second question of how does it relate to productivity, I wouldn't say that Dora metrics are an exact equivalent to productivity. What I will say is that they're an input into developer experience that help with productivity. So, for example, having a streamlined developer development process where I can easily go from coding to deployment to production, That's a very, very important thing for efficiency and efficiency leads to productivity. It's one of the leading indicators. At the same time, if I want to be highly productive, if I'm looking at change failure rate or mean time to restore, I don't want to be pulled off of my value facing work all the time because there's an issue in production. That's what a change failure rate is. Metric is essentially saying. So I would say it's an input into productivity, and it's certainly if you're trying to improve developer experience, it's something that you want to measure and then improve. So I guess, like, uh, the last thing I would say on the team by team basis, it's not where you are, it's where you start and you're measuring and baselining. And now if you even make a 5 percent improvement. Each, six months or each year, your developers are going to say, wow, I actually do feel that I see that we're focused on it and we're getting there.

Ben Lloyd Pearson: 12:24

Awesome. Well, thanks for sharing all of your great insight with our audience today, Dan. We'll return after the break for our conversation with Andrew Boyagi from Atlassian. On January 29th, join LinearB in refactoring for a workshop on starting and scaling a software engineering intelligence practice for your organization. With a data driven approach based on qualitative survey responses from engineering leaders like you and quantitative metrics from the experts at LinearB, this workshop gets down to brass tacks with actionable examples. Check the show notes to RSVP your spot for January 29th, and we'll see you there.

Conor Bronsdon: 13:07

I'm your host, Conor Bronsdon, and Today I'm thrilled to be joined by Andrew Boyagi, Atlassian's head of DevOps Evangelism. We're going to dive deep into the current state of developer experience, explore the challenges software teams are facing today, and discuss what needs to change for developers to thrive in the evolving landscape. Welcome to the show, Andrew.

Andrew Boyagi: 13:27

Thanks, Conor. Thanks for having me.

Conor Bronsdon: 13:29

Andrew. Let's start with a big picture. Atlassian's State of Developer Experience report has highlighted some key challenges that software teams are facing today. Could you walk us through the main findings and what they mean for the industry?

Andrew Boyagi: 13:40

Sure thing, Conor. So there are three main findings that I want to share with you today. The first one is that there's a huge misalignment between developers and their leaders when it comes to developer experience, and this is highlighted a few different times through the report. one of the, one of the key findings is that, the top issues that are impacting developer experience are, engineers and their leaders have wide, wildly different views on what they are. so if you ask managers, they say things like understaffing, New technology and build processes are significant impacts to their team's developer experience. But when you ask engineers, they say tech debt, core documentation and build processes are majorly impacting their developer experience. So there's a pretty big misalignment about what's going on. affecting developer experience, but they are actually aligned on one thing. And that is developer experience is very important. however, even though they're aligned on that, the reasons for, for being important are different. So from an engineering leader's perspective, it's important. They say it's important in terms of recruitment and retention of, of engineers to their organizations. and for engineers, they consider it when they are. Making a decision whether to stay or to look for a new job. So developer experience is important even if it's for different reasons. The second key finding is understanding and improving developer experience actually pays dividends. our data finds that there's a correlation between time spent on Understanding and improving developer experience correlates with better developer efficiency. there's a lot of companies out there looking to try and improve developer productivity. and this shows that, Investing in developer experience is a good investment in terms of helping developers be more efficient with their work. And then the third key finding that I want to share is that engineers and their leaders have wildly different views on the impact of AI. So again, if you ask leaders, they say that AI is the most effective way to improve Developer Productivity. But when you ask engineers, two thirds of developers are saying that AI isn't helping them be more productive just yet. So this misalignment, there's obviously a lot of this misalignment between engineers and their leaders, but If you look at what causes or what the impact of this misalignment could be, a lot of companies are spending some money and time trying to improve developer experience. who is driving that within a company? It's usually the leaders. So if they don't understand what's actually impacting a positive developer experience, It could lead to them investing in the wrong things, and every company I speak with, they have obviously some limited budget that they've got to spend on improving developer experience, and so you want to make sure that you're spending that money in the right area so that you're actually moving the needle for your engineers.

Conor Bronsdon: 16:46

I heard a bunch of great insights there, and so Andrew, I really appreciate you kind of walking us through some of the key things that Atlassian found in this report. A couple I want to call out here. One, that AI impact difference. We're hearing that everywhere where leaders are very much looking ahead to these efficiency gains, or they see small efficiency gains that stack up across the board, but for individuals, it's a lot harder to say, Oh, this has been massively impactful for me. maybe that's gonna change as we shift more to, like, agentic AI experiences versus simply, like, Socratically talking with a, you know, clod or something to help you with your coding. but there's definitely huge opportunities for improvement there, and to your point, it also speaks to the fact that many leaders today are Looking at different things. I am happy to hear at least they were aligned and everyone agrees, build processes are a problem. Great. Like that. We got, we got one, right. but if, if you are as an engineering leader are not either surveying your devs or ideally both leveraging qualitative, but also quantitative signals to understand what's happening with your development processes and what's happening through developers, it feels like you're missing out, um, because you're kind of assuming what your devs may find to be a problem without actually gathering data on it.

Andrew Boyagi: 17:59

Yeah, absolutely. And I think the AI example that you raised just then is a really good one. if you just look at AI and the promise, the promise that a lot of these products make, of course, you'd look at it and say, no brainer, I'm going to give this to my devs and it's going to improve experience and help them be more effective or efficient. but is it actually solving a problem that you have? And so it really depends. Maybe it is, maybe it isn't. But AI is a tool and just giving a new tool to developers, regardless of what tool that is, doesn't mean it's going to help them. and without a good understanding of the problems they're having, there's no sense in just giving them more tools. to try and improve things.

Conor Bronsdon: 18:41

Andrew, it's a lot easier for me, though, if I just give them more tools. Tools are shiny, they're fun, it's exciting. Like, it's a lot harder to do that, that work of like, understanding the problem and aligning on the right solution and then maybe getting a tool or maybe fixing a process or, or both. and I love that you're also thinking about this from a You use the words developer efficiency standpoint, but developer productivity as well, because I really think about developer experience and developer productivity is like two sides of the same coin where it's like, if you can improve the day to day experience for developers in the ways that they want. Your devs will typically deliver more, your devs are great problem solvers, your teams are there to solve problems, it's exciting, it's fun. help them do that more efficiently and you're gonna have that productivity gain that you want. So I love that Atlassian is thinking about this connection here because too often I think The industry will kind of hyper focus on one element or the other. and maybe if you're a scale up, you're thinking, Oh, I need dev prod. I really need productivity. I need to like innovate. I need to, you know, push features faster. And maybe if you're an enterprise, you're thinking, Oh, I have to retain people. But really these are, these problems are so holistically combined in so many different ways.

Andrew Boyagi: 19:55

Yeah, absolutely. I mean, if you look at what goes into developer productivity, it's really two things. You've got a great developer experience and a positive engineering culture. and they're the, they're the real two inputs into developer productivity. If you look at developer experience, it's around removing friction. It's around how do engineers feel frameworks that they have to deliver to their customers. Yeah. to deliver software in your organization. And if you look at engineering culture, it's about how things are done, the decision making process, and things like that. Those are the two key inputs to productivity. and so just, just saying we want to improve developer productivity, is, is like saying nothing at all. Really. It's really one of those two other things that you need to affect to improve that, that efficiency for developers.

Conor Bronsdon: 20:46

And I like that you're talking about it from an efficiency angle as well. I think there's. A lot of folks that when they talk about measuring developer productivity, I'll use the McKinsey study that came out last year now as an example, where they tend to hyper focus on Maybe some metrics that aren't the best, the best measures of actual efficiency for the team, actual improvement, and measuring productivity has always been challenging, whether in software development or elsewhere, especially with the pressures, of delivering high quality software at speed. And the fact that devs are spending less time coding and more time on other responsibilities due to the shift left movement, rise of microservices, AI, all these different, things are happening. How do you think companies should approach this given the complexities of modern development? How should they be measuring productivity?

Andrew Boyagi: 21:31

You know, I get asked this same question three or four times a week by different companies I speak with. They say, how should we, they jump straight to it. How should we measure developer productivity? Like, I want to know, why do we want to measure productivity? I feel like we're more obsessed with measuring productivity than we are measuring productivity. Actually trying to help developers be more productive. and how do we measure productivity? You can't measure productivity. There's been thousands of academics who have researched knowledge, worker productivity over years. And the closest they've come is to say that, high employee satisfaction. leads to better productivity, but they have not come up with a measure for productivity. So I think it's actually the wrong question to ask. The right question is how do we help our developers be more productive? And I get asked that question far less than I get asked, how do we measure productivity? And so if you ask me, how do we help? Developers being more productive. The first step is to actually understand what's stopping them from being productive. And from the evidence we have in our survey, you can see that not a lot of people are asking. That question of their developers. a few years ago, I spent two full weeks in an organization just asking engineers, how could we improve the way software is delivered in this company? After two weeks, I got so much information from developers. It was like a two year backlog. It would take us longer than two years to sort out the things that, that they gave us. And at that time, I was expecting a lot of Answers around tooling, around, build processes, some of the things that we've already spoken about, but there was also an overwhelming amount of feedback around the processes that the company used, to track and to, deliver software. And that was a real surprise to me. And it kind of completely changed the angle we were taking around improving things for our developers. So the first step I always recommend is, Ask your developers, speak to them, just ask them simple question. What's, what can we do to improve the way we deliver software? And you'll get so much information, so much rich information, that you'll have more work than you can possibly handle.

Conor Bronsdon: 23:47

Do you think part of the problem here is that too many companies are focusing on Individualized productivity versus like broad team efficiency and where there are problems and workflows. Or do you think it's something deeper than that?

Andrew Boyagi: 24:02

what I see from the company that I speak with is. If you look at what impacts developer productivity, and certainly over the last 10 years as complexity has grown, it's really around the fact that developers need to do more, they need to know more, they're under a lot more pressure these days to deliver high quality software at speed, like you said. And really there's two types of complexity that they deal with. There's intrinsic complexity, which is, Complexity associated with being a developer, which is things like, now we need to know about dev and ops and cloud and AI and machine learning and all the things, testing, you name it. Developers need to know everything now, and that's intrinsic and that's Intrinsic to the role. So whichever company you work in, you, you're going to face that challenge. And then you have extrinsic or organizational complexity. And this is the stuff that's specific to the company that you work in. It could be things like, regulations that need to comply with because of the industry. It could be processes, it could be governance, things that a company has implemented. And so we have all these, these two levels of complexity that developers need to handle. I often see. Companies trying to tackle one of those, they either try and abstract a lot of complexity, intrinsic complexity, so you'll see platforms that abstract and need to know about cloud and, and testing and all these other things, or you'll see companies trying to simplify their own environment by simplifying processes and, and things like that. Really, it's a holistic approach, is the one that wins. So it's around complexity, it's around understanding how much complexity. your developers face and how you can make their role and their lives easier with dealing with that.

Conor Bronsdon: 25:50

So as I start to implement that efficiency program, as I have, you know, talked to my devs, maybe I've done a survey and have begun understood some of the pain points. Maybe I've realized some of the pain points aren't ones that I thought they were. They're different ones. we've started to implement changes. How do you think? Teams should be tracking the success of these initiatives. Is it purely on the qualitative side or do you think there are quantitative measures that should be leveraged as well?

Andrew Boyagi: 26:17

Yeah, there's both. So, if you look at, if we, if we look at developer experience, let's say that you've spoken to engineers and you find out, there's three things, three major problems that's impacting most of the engineers in your organization. The first step would be to measure that. So you can't measure productivity, but you can measure things, right? And so let's say build times is a problem. Obviously you start measuring build times if, and you baseline it, if that, if that's what engineers are saying is a problem.

Conor Bronsdon: 26:44

But to your point, that's a workflow problem. It's not an overall productivity measure and we can't equate the two.

Andrew Boyagi: 26:50

Well, do you need to? I mean, if, if, developers are saying that build times is a major problem for them and it's impacting their productivity, then it probably is. Cause one thing that I'll often laugh at is people forget developers want to be productive. Right, like, everyone's like, we need to improve product, developer productivity, we need to do all these things. And they kind of talk about developers, it's like, hey, I'm here too. I want to be productive. And so, you know, if the way, the path to helping them be productive is to listen to them, to ask them and to try and work with them to resolve the problems that they're having. And so with a build process example, you'd measure Build time. You'd come up with a solution or what you plan to do to fix that. you'd share that with engineers just as a sanity check. Hey, we're thinking about doing this thing. is it going to make it worse? Will it make it better? you, you implement the thing, you re baseline, you re, you ask engineers again, did we solve the problem or not? and really that's the path to, improving those things.

Conor Bronsdon: 27:54

Well said. I think there's a lot of folks who take it a step too far though, and they say, well, we figured out build times are the problem. It must be your problem too. And it's so easy to apply these measures across companies, across teams, without doing the work of actually figuring out, is that the problem for your team? Is that the blocker in their workflow? Because like, yes, I can say generally tech debt is probably a problem with 90 percent of organizations, maybe more. but is it the primary problem that's holding your team back? that. Really depends.

Andrew Boyagi: 28:28

Yeah, absolutely. And like, something important to note is that what we see in the survey that we released, that's a generic view. So yes, Documentation and tech debt and all these things they're common answers you ask engineers from any company They're probably going to tell you those things. This is not a shortcut This survey is not a shortcut for you to say Oh tech that's the biggest problem in the industry and it affects all engineers So we're gonna we're gonna fix tech debt now. It may not be the problem It for your team. It may not, it may be a problem for some of your team, but not everybody in the team. And so there really is no shortcut here. And companies are really disappointed when I tell them, Sorry, there's, there's no shortcut I can offer you. really you need to put in the work to understand what's impacting the experience for your developers. If you look at Companies who do this really well and there's plenty of examples of them in the industry. They all have one thing in common. They spent a lot of time understanding the challenges of their developers and they set up processes and feedback loops so that they continuously get this information. and so the process as I see it and what I recommend is Yes, you speak to developers and get a general sense of what's impacting them. Now that doesn't scale. If you've got a few thousand engineers, you're not speaking to everybody. and so you, you get a general sense, then you run a survey. And go a little bit deeper and you expand in these, in these areas where, engineers have told you and you'll get a sense. Is it impacting everybody? what percentage of, of teams is it impacting? and then with that solid foundation of knowledge, you can go and come up with some initiatives that you can use to improve experience.

Conor Bronsdon: 30:11

Yeah, to your point, I think it's really easy to skip one of these steps or ignore different parts of it, instead of thinking about this holistic approach of saying, look, like, yes, I do want some quantitative measures of like, how are my build times doing, you know, where are their challenges when our PR is sitting too long? Like, what's, what's happening here? But, It's really easy to just pick a framework and apply it instead of saying, okay, let's get these measures. And also let's talk to our devs. And also let's survey our team. you know, Dora metrics, for example, they become very popular, very useful in a lot of cases, but as, as you and others have pointed out, they're not always, in fact, often are not directly aligned with productivity or with developer experience. How should teams contextualize these kinds of metrics to make them more relevant in their specific use cases?

Andrew Boyagi: 31:00

I speak to a lot of companies who pick up a framework or a tool and they try and apply it directly into their organization. And I have never seen it work. frameworks and tools are excellent. You take the bits that are applicable to your scenario. you might change them a little bit and then you apply them that way. You raised Dora metrics. That's a really good example of taking an excellent tool and using it for the wrong thing. Dora metrics are not intended to measure productivity. Now I think Dora metrics are great. They're so accessible now. Like a few years ago, it was pretty, yeah, it was pretty hard to, you know, to, to, to get access to Dora metrics, whereas now pretty, pretty much every developer tool out of the box will give you some of the Dora metrics, if not all of them.

Conor Bronsdon: 31:47

We offer them out of the box. I think a lot of folks

Andrew Boyagi: 31:49

Yeah. So, know, they're great. There are great metrics at the team level for the team to track for themselves. They're not something that I would compare in my organization between teams. And I've seen this happen quite a bit where, you might have a digital Team in a company and where they're working on a modern tech stack and their Dora metrics look fantastic. And then you have another team who's working on a legacy application and maybe their Dora metrics are not looking so crash hot. Well, it could be for them, but when you compare them, you see a big disparity and then people are asking, Oh, why is the difference? Why isn't that team on the legacy thing? Working as well as the other team, which is not the case at all, because it completely misses the context that that team operates in. and so, you know, DoraMetrics are great. A lot of these frameworks that are available are fantastic frameworks. I haven't seen anything that I would pick up and apply directly in an organization.

Conor Bronsdon: 32:47

And I think this is where a lot of people like, frankly, just take a framework and they think, Oh, this is the way, instead of thinking, this is something I need to adapt to make sure it fits the context of my company. And, there's a lot of great. Context you can gather both externally and internally, like, yes. Talk to your devs. Yes. Survey their devs, check out Atlassian's state of DevEx report, understand some of the common problems. You can look at what the Dora survey says. And there's a ton of information there too. I'll say LinearB has our engineering benchmark. If you want to look at Dora by industry and Dora by company size, so you can contextualize, Hey, what does this mean for my team and my company, but it's, it's so easy for that to be misapplied. If we don't have these conversations and think about, Oh, What does it actually take to implement this? it'd be so easy for me to say, Hey, tech debt, tech debt is a common issue. but it obviously means different things, different companies. So how should my team approach it and approach understanding and managing tech debt in a way that aligns with my productivity goals? I'm sure your advice on that would be different depending on the type of team I'm running, the type of company. And what our goals

Andrew Boyagi: 33:50

Yeah, I mean, look at a startup. It's perfectly acceptable for a startup to have high levels of tech debt because they're looking for product market fit. They're not looking for, long term stability just yet. They don't have a huge mass of users or customers. And so, you know, higher levels of tech debt in a startup would be much more acceptable than high levels of tech debt in an established enterprise, where it really starts to slow things down and impact developers. I

Conor Bronsdon: 34:18

One of the themes that's really coming through in this discussion is the challenge of alignment. Whether it's aligning your platform team to the right problems, Aligning your devs and your leadership on what the problems for developers are and how to improve developer experience or aligning your software development team to broader business goals. You've mentioned before that alignment is often more important than being right as a leader. And frankly, I agree. How do you ensure that alignment happens in practice?

Andrew Boyagi: 34:47

Yeah, this happens at a few different levels. so if we look at the company level, within Atlassian DeveloperJoy is a company level OKR. So it's at the top level, everyone can see it and we track it really closely. And since we've had that as an OKR, we've seen a 25 percent increase in developer satisfaction. So when we talk about alignment, every leader knows that the best way to align your teams is through context and through setting goals. And there is no better way than to set a company level goal around developer experience to align teams. Because having it at that level makes sure that there's alignment between levels of management. and it goes across the entire business that everyone's pushing towards the same goal, which is to have a great developer experience and to improve, developer joy. So I think number one is. having a solid goal right at the top, uh, that everyone has visibility to and, that it's tracked really closely. The second, the second part of it is really around, being able to get that buy in from managers and from across the organization. So it's good to have, a goal, but what are you going to do when it comes to moving the needle on that goal? A lot of the time engineers will raise problems or they'll raise ideas and to be quite honest it sounds like whinging or complaining. and so it's really about framing the solutions and framing what you want to do in a way that's going to help the business and explain the impact associated with what you're trying to do to improve that company level goal.

Conor Bronsdon: 36:30

What strategies are you using to ensure that your engineering teams are aligned to other business objectives? While still having the opportunity to innovate and experiment.

Andrew Boyagi: 36:40

Yeah, such a great question because every company is under pressure and we're no different to get new features out and do things that our customers want us to do. and so, you know, experimentation and innovation are really critical, critical parts of that. So, I'd say there's, there's, it happens at two levels. Within Atlassian, we've got something called ShipIt, which is our, we have a quarterly 24 hour hackathon where, engineers or anyone in the company, I participate as well, can work on whatever they want for 24 hours. You form a team or you join a team, and you can work on anything that you want for 24 hours. Now we've had some really great success come out of ShipIt. We have a product called Jira Service Management. It's one of the leading ITSM products, in the market. And that came out of a 24 hour hackathon out of one of our Shippets. And so, yeah. And so, you know, if you have a look at, at Shippet, there's been so many cool things that have come out of it. and so that's, that's one level of giving engineers space and time to do that sort of thing. the second thing that we do is we give engineers 10 percent time. And so this is 10 percent of their time that they can spend, working on things like, resolving tech debt, around improving their own developer experience. they're given 10 percent of their time to, to do engineering things that, they need their time to do. And so I think, yes, we are obviously working at pace. We have a lot of commitments, to our customers that we want to keep, but you do need to reserve time for that innovation and experimentation as well.

Conor Bronsdon: 38:18

I'm sure it can become challenging though, to maintain the level of alignment, the strong team culture that you've talked about as you have these pressures, like great, you have the time set aside to solve tech debt or, you know, work on other projects, but there's obviously this rapid pace of change happening in the industry. And there's a lot of pressure on businesses as you've outlined. How beyond just, you know, setting goals. Do you kind of balance this need for speed with this need for strong alignment?

Andrew Boyagi: 38:48

You mentioned culture there. I would reframe that a little bit. Culture is what actually helps you work at pace and innovate and do all these things. Culture is everything. and so, I don't see them as mutually exclusive. you can work on culture and you can have a strong culture through great leadership and an engaged team that help you achieve those goals. and so, you know, reflecting on when I joined Atlassian, one thing which I've never experienced in any other company became really apparent to me was the values that we have and our, every company has values. The values are talked about three or four times a day. I hear someone mention at least one of them. they live them. They're genuine. they're, they're plastered all over our offices. they're everywhere. We can give internal kudos for different things, and they're always based on values. and so we have really strong values in Atlassian and it's something that I haven't seen anywhere else. and those values are really what drive a company's culture. And so I would say culture is a strong contributor to helping teams move at pace. It's a thing that you rely on when there's pressure on and you need to get something out. I would say that's an aid rather than. you need to do both things, deliver software and worry about culture.

Conor Bronsdon: 40:07

Andrew, this has been a fantastic conversation. Before we wrap up, what advice would you give to engineering leaders or engineers who are listening and trying to navigate these challenges of today's developer experience landscape and building that great company culture?

Andrew Boyagi: 40:21

Yeah, I'll probably summarize my feedback into two points. One, obviously there's a clear misalignment between leaders and engineers. you know what I'm going to say, speak to your engineers. I'd say that this misalignment is probably the leading cause for a poor developer experience. so speak to your developers, be transparent about what you're able to fix and what you need more time to fix. to work on. so alignment is the first one. The second bit of advice is learn to write a good business case. This is not a strong suite for a lot of engineering leaders, but it's really important so that once you know what needs to be fixed, you'll, you're able to get the support and the funding to fix those things.

Conor Bronsdon: 41:06

Andrew, thank you so much. It's been a pleasure. Uh, great having you on the show

Andrew Boyagi: 41:09

Thanks for having me, Conor.

Ben Lloyd Pearson: 41:12

That's all that we've got time for today. If you want to be a part of the Dev Interrupted universe, we're always looking for new people to share interesting and unique stories with us. If this sounds like you, reach out to Dev Interrupted on LinkedIn, or you can contact me directly, Ben Lloyd Pearson. Thanks everyone, we'll see you next week.