AI, productivity, and developer joy

Sven (0:00:06): But if you ask your developers, they actually know exactly what the problem is. So ask your developers. 

Marc (0:00:21): Welcome to DevOps Sauna Season 4, the podcast where technology meets culture and security is the bridge that connects them. We're back in the sauna. Hello, Darren. How are you today? 

Darren (0:00:44): Hey, Marc. I'm doing pretty good. How are you? 

Marc (0:00:46): Fantastic. It's a sunny Monday in Helsinki at the time of recording. Having come back from the DevOps Conference in London, we have a few post-games still going and one of my favorite talks was from the gentleman that we have as a guest today, Mr. Sven Peters, Developer Advocate at Atlassian. Hello, Sven. 

Sven (0:01:10): Hello, hello. Thank you for having me in the sauna. I hope it's not getting too hot here today. 

Marc (0:01:14): We'll take it a little bit easy on you today. 

Sven (0:01:18): All right. Thanks. 

Marc (0:01:18): Your talk at our DevOps Conference was on developer joy and I was absolutely fascinated by the topic and the presentation. The funny thing, Sven, I know almost every developer uses Atlassian products today, but I don't really think of Atlassian as the developer joy company or the first thing that I think of when I think of developer tools. But you brought this amazing viewpoint on developer joy. Can you tell me a little bit about how this came onto your radar and how you help teams in order to be more productive and have more joy in their development? 

Sven (0:01:57): Yeah. So, I mean, I'm a former developer myself, so I love to code, right? I love to write code. I love to solve problems. That's when I enjoy my work. Now, what we've seen in the last, let's say, 10 years in software development is that there has been a lot of things just like putting on top of the developer role for good reasons, right? For good reasons. We just like jumped on the DevOps train and we're now also responsible for observability, for being on duty if our microservices crashes and we have to do something. So we are owning more roles now. We are also responsible for the operational side. So I think there has been a lot of more cognitive note now to the role as a software developer and the pressure is on, right? Now everyone just sees we don't develop so much features anymore because we just work also on other stuff, right? We're working on the operational side. So how do we get back actually to the joy that we have with software development by getting less pressure from management and just enjoy what really this job is about? And I'm super excited about software development. I think this is the best job in the world, actually, that you can have. You can create with a few lines of code. You can delight your customers. You can create value, right? So how do we get back to that joy moment? 

Marc (0:03:21): I love it. And one of the ways that you framed this for us was developer joy. It's a Venn diagram between progress, quality, and value. And I kind of think of this in terms of it's like toil versus feeling great that you delivered something and you made a difference today. No matter how small that change may be, it's a positive step forward. 

Sven (0:03:45): Right. So yeah, that's actually when I work with great quality code, right? The code that is just like, I look at the code and just want to work with that code because it's such a good quality code. And I get things just like through the pipelines very fast, right? No really friction in the pipelines. I have an idea, I put down the code and I deploy it and then my customer can have it. And I create real value for the customers. They come back to me and say just like, oh, we love what you just did for us. That's the moment where I just like super enjoy the job that I have. And that's this Venn diagram that we have, there's like the developer joy in the middle and when all three things come together, I'm so pumped. I really love what I'm doing there. 

Marc (0:04:29): So let's go the other direction, Sven. What type of challenges do you see in companies and development teams that are not able to reach enjoy today? 

Sven (0:04:40): There are certain, I mean, just like here, every team is different. Every organization is different. Every team has different challenges. So there is not this one single challenge that software developers have these days. If it's one challenge, I would say just like cognitive load is a big one here. But if we go a little bit deeper and see just like what caused this cognitive load, what is it that developers are challenged with these days? And I'm just like talking about internal from Atlassian because we just ask our developers regularly in a survey, in a developer experience survey, what is it that is challenging for you? And teams are different. So challenges are actually different. So what we do in these surveys, we summarize it for every team and give it back to the team to just see what's your challenge. And here you get some time back to just improve whatever your challenge is. I think this is super important that we treat teams differently. Now, I am also going to a lot of conferences and I ask always people at conferences, what is your biggest challenge? And I have a list of eight different areas actually that we also use internally in Atlassian, our developer experience survey. And there's a common thread actually that I discovered throughout my, I don't know, I asked maybe 1,500 developers in the last one and a half years that I'm running this survey live on stage. And the number one thing is actually in, I must say in Europe and the US, it's wait time. I recently been, and that's also fascinating and that plays to different teams have different challenges. I've recently been to a conference in India in Bangalore. And that was fascinating because I ran the same survey and I was just like thinking about just like, I get the same results, right? It's wait time. Wait time is the number one challenge that I saw in Europe and the US. No, in India, obviously, and it came to my mind that it must be obvious, it is execution independence, right? And if you look at Indian developers, they work mostly for big Western corporations, banks, insurances, all those things. And they have to just like, they get the user story and they have to do, they have to just like program down this user story. And of course for them, it's execution independence. That's the biggest challenge. And that plays nicely into this, wow, every team is different and wait time might be a challenge for one team. And maybe that's a common thread, but it's not for every team. I've also seen people that say just like, security and governance, that's our biggest challenge that we have. And obviously in some corporations, that's probably the biggest challenge that they have. So it's hard to just like say, what is actually a common thread because every team is different. 

Marc (0:07:34): There's an interesting thing here that you kind of touched on for me. So one of the things that we see a lot in the industry right now, especially from where we sit at Eficode is there's a lot of migrations towards big platforms. You know, Atlassian being a big platform as well. But one of the things that agile used to mean kind of falsely is every team has their own way of working in their own tool chain and all of this kind of stuff, which as we all know, it created lots of fragmentation, different ways of doing things. So when I started facing this challenge and trying to help teams overcome it, it's like, how can you dare take my Jenkins away or something like that? It's like, well, what if we gave you interesting problems to solve that allow your business and domain expertise in order to find innovative ways to solve those? And when you talk about this execution independence, like it kind of dovetails perfectly into that, that are we giving people problems to solve early enough so that they can actually innovate something in order to create, you know, neat solutions for it rather than just, here's exactly what we want from you and go away and do it. How that affects developer joy. 

Sven (0:08:40): Yeah, definitely. That's also something that I see a lot that there's a disconnection between development teams, the problem that they need to solve or that the customer has. Product teams, product managers, they just like have a good relationship for the problem. They care about what is it that the customer has, the problem, what are possible solutions and what they then do for development teams, they write a little user story, right? And the development teams are just like grabbing this user story and implementing it. And if the developer don't really understand what the problem is that they need to solve, I see a big, big problem of just like developing the wrong thing, right? It might be the user story is fulfilled, but if you don't understand the problem that you need to solve for customers, you might do something wrong or something that is not 100% the solution for the customer. So it's super important that we invite developers just like very early in the loop and help them to understand why are we building this, right? And what are possible solutions to involve them also in the whole process. We're not just like coders, right? We need to solve problems, especially in a world that AI can write code for us, right? What is our job, right? If AI can write code for us, what is our job as software developers? Yeah, we need to review maybe the code in the future that AI has written. Maybe the architecture, the AI doesn't get the architecture right. We can just like help that, but we're writing less code. That's probably a fact, that's what I'm seeing. So we need to just like pivot to become more product engineers instead of just like being code engineers, we need to become product engineers and care more about why are we doing this? What are possible solutions to help build the right thing for the customers? There are probably different techniques how you can do that if you wanna work closer with product managers. So for example, what we experiment with is for one thing or what we're doing is we're doing project kickoffs. So once the problem is identified by our product managers, they invite the whole team, designers, IT operations, quality engineers, everyone to the party and say, this is what we're trying to build. This is why we build it, help us to come up with great solutions. So this is one thing. On the other side, what we're also doing is we're nominating feature leads in the development teams. So these feature leads are building the connection between the product teams and the engineering teams. It's an engineer that is a feature lead, but this feature lead is responsible for telling the developers the why behind the what. So they have to translate for the engineers why are we doing this and make sure that we're building the right things. So they are still engineers, they know how they build stuff, but also they are acting as just a person in between to just translate the why to the what. And that helped us tremendously to go deeper into the real problem and we're trying to solve the problem that our customers actually have. 

Marc (0:11:58): I'd like to ask a question from a little bit different angle. As a developer advocate for a company that provides tools not only to developers, but to developers, the way that you describe your work in decision-making kind of spans the work that is internal to Atlassian and the work that Atlassian's customers are doing. As a developer advocate, can you tell us anything, and I know you hold many hats as well, but can you tell anything about kind of crossing the line between staying warm inside the house and keeping your finger on the pulse of how developers are operating there and maybe even writing some code yourself and then going out and talking about this and helping other companies to improve how their developer experience is or their developer joy? 

Sven (0:12:49): So yeah, I mean, first thing, I'm not a full job developer. So I just need stories from developers inside of Atlassian, that's normally what I do. So I talk a lot to developers. I'm trying also, I'm still getting my hands dirty, whatever, to do it as in write some code myself, but this is not production code at any means, but I'm just like trying to play around, especially now with the new AI tool links and stuff like that, to see just like, what can AI do? So I'm still doing these things. But for me, as you see, my role is more about how do humans and the technology work together? Because I think you can give people tools, great, but that will never solve a problem. It's all about just like the ways of working. So I'm talking a lot first to our own developers, but I'm also hearing a lot of stories from our customers, actually, when I'm just like speaking to customers and they actually have different challenges. And I can't go to a big bank and say you need to operate like Atlassian. That's never gonna work, right? Because we have a different culture. We develop different kind of software, right? They need to just like take care about more, much more about security and stuff like that. Also security is a big topic for Atlassian, but it's on a different scale, right? So I need to also understand the customer challenges. And that's just like these two worlds need to just like written my stories and my experience and how I help actually to see patterns that I've seen in Atlassian, our stories, plus customer stories and this merging then. And with these stories, I can help a bunch of other customers to improve their developer joy. And at the end, it's just ideas and concepts and people have to take those and put that into their organizations. It's never just like a one fit. That will never, never happen. I can't use the way we work in Atlassian and say this is now how you should work. But what you can do is just like take some ideas, right? You have different organizations and I don't wanna just like reorganize your org. It is basically just the idea behind it or the meaning behind it, like the feature lead one. Probably not every company can have a feature lead or that's not in their way of working. But what they can do is just like, okay, the feature lead is bridging the two disciplines that we have. So what can we do to bridge two disciplines to let the developers understand the why better. Feature lead is a great idea, but there can be plenty of other solutions to that. So I think it's this, just like if I show people and talk to customers and say, this is how another customer has done it. This is how Atlassian is doing it. It inspires them to come up with their own solution. And that's even better, right? It's even better if it's their own solution and they don't just like copy things over that works at other organizations. It's their own solution, they stay behind it and it's their own DNA is in that solution. That's just like what I wanna reach when I go to customers. 

Marc (0:15:50): Awesome. We talked a little bit in the pregame about some of the things that we see, especially with large customers, where I can frame it a little bit differently that in the DevOps Handbook, it was talked about a North Star metric. So many people picked something like cycle time or release frequency or something like that. And then when Accelerate came, we came with the four Dora metrics. But then the thing that fewer people are talking about is what Nicole Forsgren continued to work and said that, pick a speed and a quality metric because you can have it both ways if you do things well. So what happens in large companies from our shared experience is so many companies, they'll come and they'll pick a metric or maybe even a couple. And then they'll try to compare team to team with the same metric, even though each team has its own microculture and has its own kind of challenges to solve. So have you seen anything in this kind of area or is there anything to share? 

Sven (0:16:45): Yeah, that's a common pattern that I also see that people come to me and say, Sven, what do we need to measure to improve our developer productivity? What is it that we need to measure? But it's actually the wrong questions what you need to measure because you need to ask the questions is, where are you struggling? What is your problem? And start from there. And once you identify this, you can just like have a metric to just like see, can we really improve it? And then, but then you ask the question again, have we improved it, right? The metric can show like, yeah, great. Cycle time is down. So we are just like improving, but does it really solve our problem of feeling that wait time is a problem? So let's say wait time is a problem. You fix the cycle time, right? And now just like you see in the metric, oh yeah, we are faster, right? But the developers can still think like, yeah, we are faster at some stuff, but still the build take way too long, right? And they're the, oh, so we need to measure the build time and just like improve that. So the metric is always just a number, but really what you wanna solve is the developer experience for the developers. That's actually the challenge that developers have. The metric can just like show you some signals, right? It's just like signals somewhere, but you need to just like know what is the main challenge you wanna solve? And Debit make progress on that. Debit do better in that. 

Darren (0:18:15): So it comes a bit down to the fact that lots of people are measuring the wrong thing, really. It always seems to come around to that where we make these kind of arbitrary metrics that just don't really mean anything outside of looking good for numbers. It's kind of interesting to hear it reframed in such a way, but then do you think metrics should be wholly developer centric? 

Sven (0:18:40): I think metrics are just like one part of the signals that we have. I always tell the story about if I give my developers a metric, right? Let's say deployment frequency, for example. And I just like review the metric every two weeks. And then I say, oh, deployment frequency went down. Then we need to do something, right? And then, but if you don't ask the developer teams, if you don't have the context, the developer team will say, yeah, you know what? Half of the team was sick or we're just like working on a very, very complicated part of the subsystem. We know that developer frequency is down, but it's not a problem, right? It's really not a problem. So putting things in context, and the metric is just a number, but it helps us understand better. Is that a problem or not? Is that a challenge that we need to solve or not? Yeah, so people just like look at numbers and just like, oh yeah, we need to do something there. But it's not the whole story. Yeah, it's much more complex that a software development is much more complex than just like saying this is the number. I also compare this. And I don't know, maybe this productivity thing comes from we're producing cars or some other goods or whatever, right? And then we can just like optimize everything, every step in the car production. But software development is not a car production. We can't just like measure it like that. It's a creative process. Every time we just like take a task from a Jira bot or use a story or whatever, right? We are creating something new, something that we have never done before, right? Otherwise we could just like copy it, but that's not the fact. So we're just like creating something new. It's a creative process. So we can't treat it like a manufacturing process like this. And we need to just like always see the context behind things and just like make human decisions on the numbers that we see and adjust it accordingly. 

Darren (0:20:36): And I think that part's critical because I think a lot of people view development as a mechanical process, as the idea of just making code to do a specific job, to function in a specific place. But I do think there's a lot more art to it than science a lot of the time. There's a lot more creativity that kind of goes unnoticed. And I think that's why we end up in this situation where we have metrics without context that are then just meaningless. 

Sven (0:21:04): Totally. Maybe also it's our own fault because we call it a development pipeline. And we think just like it is like a pipeline, right? You throw in an idea in one end and get the working software out at the other end, right? And all the time in between we need to optimize, but it's never like that. We're throwing an idea in, we figure out along the way, maybe the solution is not the best. We need to just like circle back or it's more complicated than we thought it is. We need another technology, adopt another technology or whatever. It's never like that. And the word development pipeline, I'm not a big fan of that because it gets us in the thinking of can throw in something in one end and will come out final at the other end. It's never working like that. 

Marc (0:21:53): There's something quite interesting here that I like in terms of the flow. And that when a developer is working on joyful code or beautiful code or well-written code or is creating code and feeling joy in the flow state, that's usually not happening at three in the morning under the pressure of a deadline. Or it's not happening under very difficult command and control type of situations. So well-written code is a product of a good culture, a good environment, a good understanding of developer experience, a priority of the human and cultural aspects of things which allow people to get into a flow state, use their creativity and create beautiful, maintainable, well-executing code. Where when we press and press, oh, it's just an assembly line and we want to press every single step down to its minimum. You know, all of this development value stream revolves around somewhere between taking a ticket and committing some code, right? So everything revolves around that. And all of the work that we do is to make that part as joyful as possible. 

Sven (0:23:09): Yeah, totally agree here. I think like we're trying to make things way too easy if we just like think like that. It's much more complex, but it doesn't mean that we can't solve it, right? We just like want to produce great code. We want to produce good quality code. We want to build the right things for our customers, but we can't just like throw it in a pipeline. That's not working. We probably know that. 

Marc (0:23:34): So can you open up a bit on the AI aspects of kind of what's going on in your work and at Atlassian? What are you seeing there? 

Sven (0:23:44): I think we're just like still when ChatGPT came out, I don’t know, one and a half years ago, I thought like it will revolutionize everything in just like two, three months. We saw that it takes a little bit longer. How do we come from AI is great for writing us poems or whatever to some really useful stuff and Copilot, maybe GitHub Copilot and other tools like that helps us to understand where we might go in the future. But we're still like at the right beginning of to see what does it do with our work? What does it do with our teams? Do we just like still work in large teams or in just like in teams of let's say six, five people? Will we just like do smaller teams maybe with an AI assistant telling us what actually happened during the night when the AI assistant picked up a bug, a report and fixed the code and gave us a pull request. Are we just like working just like in this AI plus developer team, smaller team? What happens with sprints? Do we still need to do sprints or is that not necessary anymore because the AI can just like say, well, this is way, way more important. Product managers have put that feature right on the top of the backlog. So we just like grab it from there. We don't need a whole two week planning to know what we are building on. We're just like building the new thing. Retrospectives, probably still a good thing to have, right? To look back to things, but what will it do with the whole team dynamic and where these, we called it Atlassian AI teammates. And we just like announced a new product called Rovo that where you can build your own teammates, AI teammates. And we already showed some teammates that can just like remove feature flags or whatever. It's just the beginning where we see how does this interaction works with AI on one side and humans on the other side. And how do we work together if we write less code, what does it mean actually for the role as a software developer? Are we just like now just like reviewing the code? What happens to junior developers that comes directly from university? Can they, because they don't have enough experience, can they really judge what is good code that is written by the AI and what is not good code written by the AI? How all this dynamic comes, I have no idea, but I'm just like super curious. And I think it will change quite the role of a software developer. Like it will touch everyone's job probably in the next 12 months. But how did the dynamic change? There are some just like a lot of ideas in my head how things will work out. And is the AI more our junior person that we just like give some tasks, they just like the AI executes it and we just like review it? I don't know. And then we correct the AI and the AI is learning based on our input that we teach the AI. So there's a lot of unknowns right now what companies are actually building. But after this one and a half years that we just like saw now with ChatGPT, we see, all right, now we're getting into more the useful things that will really change things. And as I said, it's not the poem writing, let the AI write a poem or whatever, give me a workout plan if I wanna work out or whatever, right? Now we're getting into more like, okay, how does it really change the work? And I'm curious to see what happens, but I can't make any predictions here. But I'm fascinated by how this interacting humans and AI will work out at the end. 

Darren (0:27:21): There is one set of questions that I think which you're probably uniquely positioned to answer, which is about what AI will do to develop a joy. So if we go back and think about your Venn diagram of the joy being the intersection of progress, quality and value, and we start to shrink the value because the value is no longer being created by the developer, it's being assessed by the developer. And then we also shrink down the quality because the code qualities, as you mentioned, university students, junior developers might not have the knowledge to assess what is good code and what is not. So I think we're starting to see losses in these two as more code is being developed by AI. How do you think that's going to hit developers and their fondness for the job, their enjoyment of actual coding? 

Sven (0:28:12): Good question, great question. So a lot of thoughts here. I think first, we're still responsible for the quality and maybe we don't work with that code because the AI is working with the code, but we're still responsible and we love to see just like good code and see just like a solution built on great code. The second thing is I think the value, we're getting much more into the value creation. Even though the AI is just like writing the code for us or most of the code for us or part of the code for us, whatever will come, I think we feel more connected to the problem actually that we want to solve. So we actually go closer to the customer and to the problem that we solve. So on that, I see just like an increase because we're not just like taking user story and then we put it into code, but we just like have more time to just like really care about the problem that we want to solve, right? So I see that actually as an advantage in the longterm that we will hopefully create better value for the customer in shorter time. And the quality one, I hope we will keep the quality up and not just like accept everything that the AI will give us. So I just see that developer joy will be different because I'm not writing the code anymore, but I'm still responsible for what's in the code. It will be different, but I still think like there's a lot of joy in what we're doing because we still have this great jobs where we create stuff for the customer and we're getting actually closer, even closer to the customer, interviewing them with what's a problem that we want to solve. 

Darren (0:29:44): Do you think that's not like a very much management centric view? Like if you're thinking, if I think about the developers I know, they are interested in making code, they're interested in building cool things, they are not specifically interested in connecting with a customer. They might know they have to, but they want to make code, they want to code cool things. And just like we have with how DevOps kind of started taking developers into operations and increasing the cognitive load, I do not feel that AI is going to start dragging developers more so that they're less developers and more quality assurance people who are just checking the quality of AI generated code, taking them out of like the area they want to be. So I think from a management point, you might be right that we'll see them getting closer to the customer, but I don't think they specifically want that from, or maybe they do. Maybe I don't know enough developers. 

Sven (0:30:44): I mean, I don't know what happens, but I think if the AI can write code, the job will change definitely. And with every change, there will be some people that will say, oh, I miss the old times, right? But the advantages that we get with AI is just like so good because we can do things faster, but the job will change and we can't take that back again. We can't just like say, oh no, we're just like ignoring it. And we don't use AI for building code. If the AI can build great code, we should use that technology. I feel like in the past, I still learned to write machine code, right? Didn't enjoy it very much, but there were probably developers that enjoyed it to be just like bear down near the metal actually, but I didn't enjoy it. I love this high level programming languages, right? I love to just like program in Java, in Ruby, in whatever, Python, really love that to explain things in that kind of a programming language. I think it's just like another step up, right? We just like now use natural language to explain what we want to build, but we're still building stuff. I'm personally excited about that. And I can understand that not every developer is fine with that. It's a change and jobs will change with AI. I think we have to face that and can't say just like, no, I don't use it because I love to code. There will still be places where you can probably code where you need to just like do something really, really deeply, really new that maybe AI can't do. But I feel like, yeah, we just like need to adopt to the changes. 

Marc (0:32:19): I think you put a really good end point on that, Sven, which is that it's here. So it is something that we must adapt to because you can't avoid using AI in your work today really to be competitive in this landscape. You need to learn how it works for you. And there's kind of a, just an observation when we were first using Copilot around here and the older guys were really excited about it. And it felt like they had an army of junior developers that they could use to push things along. But the really hot young guys that literally do know everything basically, and they were like, I can write better things faster than this. Some of them are still continuing to do that. So it's gonna be really interesting to see how this plays out over time. And I can't predict it either, but I really look forward to watching it go. 

Sven (0:33:12): Yeah, great. Love it. 

Marc (0:33:13): So let's summarize a few things. So in your own words, would you like to define developer joy for us? 

Sven (0:33:21): I think if I'm just like super satisfied with what I'm doing, I am also super productive. 

Marc (0:33:27): Yep. 

Sven (0:33:28): It's often a balance for large companies of balancing standardization with autonomy. I see that, yeah, there need to be some standardization for large companies to just like standardize some things, but give developers also the autonomy to do things in their way. And that actually generates the joy. I sometimes compare it to, I don't know if you know the Ikea effect. The Ikea effect says, if you just like get building blocks from Ikea, you assemble things yourself, right? You just like put things together, you assemble your chair and you feel more proud of what you've been building. You love your chair more than just like taking the whole chair out of the shelf. It's the same with giving people the freedom to just like pick the building blocks that big organizations give you, right? In terms of, oh, here's your CI/CD pipeline and here are the things, but you build it together. You create your own ways of working for your team. And at the end, it is your ways of working. It is your way of doing things. And this is where the developer joy comes in, right? This is really when you enjoy what you're doing because you solve your own challenges by taking some standardized building blocks, but you put it together and it's your way of working. So that would be my kind of definition for balancing the standardization with the autonomy that you need to give teams to spark that developer joy. 

Marc (0:34:56): Awesome. Can we shift left the problem solving? We talk about shifting left everything, but can we actually shift left the cool part? 

Sven (0:35:03): The problem solving part, shift left? 

Marc (0:35:05): Yes. 

Sven (0:35:06): We should try shift left also on the problem solving part. We should try, we should do that. I think like we need to involve developers more in the problem to understand, to get the bigger picture, to understand the why beyond the what. So I think that's really necessary to also just like, if you create the value, if you understand, wow, the customer had this problem, I created that part of software. And then this is really helping the customer to succeed. You will also enjoy more what you've been building. 

Marc (0:35:34): All right. And to summarize, what are some of the biggest challenges that you've seen? 

Sven (0:35:38): In terms of developer productivity, developer experience, developer joy? 

Marc (0:35:42): Yes.

Sven (0:35:43): Biggest challenges. I think the thing is that people don't think, get the time enough to really improve their ways of working. It's always just like feature work, feature work, feature work, grab the next user story from the backlog, grab the next user story from the backlog. But giving people time to really improve the ways of working. I haven't seen that in a lot of companies, to be honest, to have that specific time. And to say, you actually, in this sprint, you get, I don't know how many story points or whatever, or 10% of the time or whatever, how you want to measure that. On improving the way you work, to improving your own challenges. I think this is something that companies or managers, developer managers don't feel comfortable with because they're taking time away from what they think value creation. But at the end, it will pay off, right? I talk now for 45 minutes about developer joy and how great it is and how productive developers are. If they enjoy what they're doing, giving them the time will pay off at the end, right? So I think this is a big challenge that I see. 

Marc (0:36:54): And is asking them what their biggest challenge is probably more valuable than trying to come up with another metric in order to measure? 

Sven (0:37:04): Yeah, a hundred percent, right? A hundred percent. You need to just ask your developers. It's a good balance to just have a survey that you can ask your developers what is the real problem and then have the metrics to just see, did we improve something on the challenges? But yeah, you need to ask your developers. There's no way around. They often know, you can have a big metric, right? Let's say you have 20 metrics. You sit in front of your dashboard and pinpoint out, and this is our problem, this is our problem. It might be, but if you ask your developers, they actually know exactly what the problem is. So ask your developers. 

Marc (0:37:48): Awesome. Thank you so much for joining us today, Sven. I knew that this would be an awful lot of fun and you certainly brought joy in my life today. 

Sven (0:37:58): Thank you. Thank you for having me. Yeah, I must say the sauna wasn't too hot. It's just like, it was the right temperature for actually for me here in that sauna. 

Marc (0:38:08): Perfect. And thank you once again, Darren. 

Darren (0:38:11): Thanks, Marc. Pleasure as always.

Marc (0:38:13): All right. We're gonna heat up the sauna now and we'll see you next time. Thank you. Goodbye. We'll now give our guest an opportunity to introduce himself and tell you a little bit about who we are. 

Sven (0:38:28): Hi, I'm Sven. I'm a developer advocate for Atlassian, which means I talk to a lot of customers. I speak at a lot of conferences. I talk to press and I talk to a lot of developers. I love to talk to developers. I've been a former developer myself. So I love to help them to overcome their challenges. That's what I'm doing day in and day out. That's what I live for. That's what I get up in the morning every day and I love my job. It's a great job to have. 

Marc (0:38:53): Hi, I'm Marc Dillon, lead consultant at Eficode in the advisory and coaching team. And I specialize in enterprise transformations. 

Darren (0:39:01): Hey, I'm Darren Richardson, security architect at Eficode. And I work to ensure the security of our managed services offerings. 

Marc (0:39:08): If you like what you hear, please like, rate, and subscribe on your favorite podcast platform. It means the world to us.