Managing Developer Feedback Effectively | Atlassian’s Andrew Boyagi

**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, Connor Bronson. He's since moved on to a new opportunity. If you want to learn more about that 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 changes that are happening here. In a moment, we'll play this conversation between Connor and Andrew. But first, Dan, I wanted to bring you in to break down some of the topics that they discussed. 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, do you sense this misalignment?

**Conor Bronsdon** (1:06)
Actually, that's pretty funny. I do not sense the misalignment, but I'll tell you why and I think I know. 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. When you utilize data to do so, it's actually a universal language. There's no misunderstanding or misalignment. For example, if you're thinking about something like, okay, 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 a survey. But no, actually, the customers that we're working with, since we're more, I would say, data-centric, they're actually pretty aligned on what they're looking for.

**Ben Lloyd Pearson** (2:50)
Yeah, it's a great way to put it. Everyone just wants to build new awesome things, but to get there, you got to make sure that you're investing into DevEx and to keeping the lights on and to maintenance, because 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, up to two years to dig through it all, which is a little wild. 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?

**Conor Bronsdon** (3:27)
I mean, again, here's the thing. If you're sending out a survey, it's a very academic, let's say academic questioning of what's happening with your personal experience and you go and do that for a 100 It's not even developers, let's just say people. You're going to 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 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. 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 causing bottlenecks, what's causing planning accuracy problems, what's causing investment problems into DevEx. 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 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?