Why improving developer experience is the key to unlocking developer productivity | Chris Davidson

Good morning, amazing people. So great to be here. I hope the coffee fill-up is good and the coffee is going down well. Hearing Helen's talk, talking about flow, team networks, networks of flow, - awesome speech. It's inspired me for this talk here now, - having everyone in the room, theconversations we're having. But really, we're going to talk to you about, we talk about this joy, - this passion that comes from developer joy, - and we put this developer experience message - that developer experience is the secret to unlocking developer productivity. When we talk about developer productivity and the context of - developer productivity, how do you help unlock this productivity - with this developer experience by bringing this joy back? In this talk today, we're going to talk through four insights that we've had, - and I hope we can inspire or give you examples, - just give you from these four things, - some things that you can take away and explore yourselves, - ask more questions, and inspire you at this event today. We're going to talk about the secret of unlocking that developer joy - so that we unleash that productivity, - and we're going to go through four insights that we will share with you. So I'm Chris Davidson. I'm a solutions engineer at Atlassian. I work with our customers. I look at their ways of working, - the flow of value to customers. How can we help your way of working - to get that flow of value to your customers? I also, you know, in my other job, - I'm a part of a team that makes and creates all of our demo environments, - all of the data, all of the configuration. We give it to all of our teams inside Atlassian, our partners, - and then of course our customers as well to explore and use. A bit like a platform team really, but more to come on platform teams. So this developer productivity question, - the pressures and trends, where is this coming from? We know you only have to look at the newspaper - to see what is the global growth rate? What is the growth of companies and the forecasted growth? And it's struggling. It's struggling to get back up to pre-COVID levels. We've got this sort of pressure on leadership teams - and boards to drive that growth, and it's struggling. But interestingly, at the same time, - we've got an increasing deployment. Over 53 percent of CIOs are deploying more technology. Yes, we'll say the A word in there as well. We know that's a big part of where that 53 percent is going. But you've got this interesting dynamic, right? You've got - growth struggling in the economy, - more technology and that's going to drive pressure. That's going to drive a pressure to say, I want more with what I've got. I need to show the benefit of this technology that I'm deploying. Where is that productivity coming from? And of course, we've still got half of organisations hiring more talent, - new people coming in, seeing that network slide of Helen's, - like the complexity, the microservices challenge of potential dependencies. How are we going to get this new talent up to speed and safely work on - building value for customers? There's some sort of context all these - different trends that are happening out there is what's driving - this developer productivity conversation. But actually, we have been here before. This conversation about productivity, - and especially in the context of vast, - impactful technological change and technology adoption, - we've been here before. I'm going to take us back a little bit like a time machine, - but there is a story here. We are in post-war era Britain. And we're recovering from the war. We've got to get productivity up. We need productivity of our coal mines. We need to provide energy and steel - and all of those things. So the coal mines need to be productive. At the same time, all the technology that we've developed, - we need to apply that technology in our coal mines - so that we get this productivity gain. And there's a key actor in this story. His name is Fred Emiry. Now, you might not know Fred. He's actually a hero of mine. We have a lot in common. I say a lot in common. We were both born in Australia. Fred's from Western Australia. And we both travelled to London, England. We both came to England. Now, Fred, - he's a researcher around socio-technical systems. How do you put social, psychology, people, technical systems together? What happens when that goes on? And he's a leading researcher. I'm not a socio-technical researcher. I started my career... I joined a company called Symbian in London, - making an operating system for a mobile phone. I love being back up in the Nordic regions. So much love up here. I was in the systems engineering team. I don't want to say this, but I was a project manager at the time. I have had my teeth cut on developer experience from trying to work with - kernel engineers who I love passionately and have been taught - many a lesson by many an engineer as a time as a junior project manager. Emery formed up with Bamforth and Trist, awesome team. Bamforth was actually an ex-miner. They're looking at what's happening, productivity gains, new technology, - what's happening in these coal mines. Now, if it's okay, and I think it will be with this audience, - if I can just geek out a bit so that you understand the story of - what Fred Emery discovered, the insights on why we can use them today. In mining in the 40s and 50s, - it was traditionally done in what was called the hand-gotten method. And the hand-gotten method, you'd think about a single coalface, - a small coalface, that a single team would work against. And that single team, if I was to use that sort of speak, - is a cross-functional team. You've got someone in there cutting the coal, - the person who does the cut. Then you've got someone working the roof to - make sure that the roof stays up as the coal comes down. Then probably the most important, they say the most important person - was the trammer. The trammer is the person that's getting the coal, - putting it in the tram and getting the coal out, - the output, the value to the customer. Awesome stories around how these teams were formed in terms of - how knowledge was shared, senior people to junior people. How the different skill sets would merge and blur depending on - the situation, and also how, - you know, coal's nature, right? Some coal's soft, some coal's hard, - how these teams would set their goals around how they would attack - this particular coalface. But then along comes the longwall method. And the longwall method, well, hey, let's make that coal face a lot longer. Imagine we have a whiteboard here. I've drawn a big, long coalface. So let's make it much longer. Then what we'll do is get all of the cutters and we'll just line all of the - cutters up on the wall. Then we'll get all of the people doing the roofing. We'll put them in a wall. And then finally, - we'll get all the people collecting the coal. And we'll run this in three shifts. We'll run this in shifts, big waves of people. And we don't need to consider what's really happening with, - say, how the goals are set off the team - based on what's happening on the coalface, - how the different roles are interacting and talking. We don't really need to think about that because we can look at the individual - productivity metrics of each function that we're performing, - and guess what? We have got some awesome tools. We've got amazing blasters that blast holes. We've got incredible travellers that move coal out. We've got these awesome tools. We're going to throw the tools at the rolls, - and we're going to make this way more productive than this method here. Fred Emiry and team, what did they actually find? Was it faster? Was it faster? They proved that in many cases it wasn't. When you assume 100 percent operation of the long-wall method - in a laboratory-type theoretical environment, - sure, faster, they proved it wasn't. Secondly, what about the outcome for the customer? Did we get more coal out? Did we ship more coal? And the bottom line is that Emiry proved in both quantitative - and qualitative ways that no, in particular cases, - the volume per worker was higher in the hand-gotten team-based method. And why was that? Why was that? And why is he my hero that I try and learn from - when we're looking at your system of work and how systems of work - and tools, socio things, like psychology and tools, come together? It's because he identified a couple of things. Let's remember, that nice little picture up there of the coal mines, - that's happening in a deep, dark, dangerous place. We talk about psychological safety and sort of human safety, - the conditions that they're working in. We talk about those social bonds, - communication, connection, motivation, morale. When we saw the longwall method, what the people designing that system - with their obsession with the output metrics - or the activity metrics didn't realise is that you were destroying, - breaking apart that connection between information flow and knowledge. They found much higher staff absenteeism, - much lower minor satisfaction and motivation. And the bottom line of that? In these mines, in these examples, 200 tonnes a day. So while the system on paper looks great and you can optimise every bit - and get the awesome tools and give them the tools, - if the whole system doesn't work as a social construct, - as a psychological safety, you're going to lose 200 tonnes a day, - and that's what happened and why they could prove it. I won't go into it now. You've allowed me to geek out enough. We'll bring some of the connections up into the story - as we go through the four things as to how we can help - developer experience improve productivity. If you do want to geek out later, afterwards, please come and see me, - because the long-wall method did actually survive. It's going through its own moment now with AI. Won't go into it now, - but why did it survive, even given this insight from Fred? That's one for the bar later. I'd love to tell the story there. In short, Fred proved the productivity benefits of thinking holistically - about your systems. That's important as we come to why developer experience - is that developer experience, we've got to take that holistic view - and we've got to be cautious and intentional - about how we use our metrics, - our data, and our productivity measures. There are many ways. We're going to go on this process of measuring productivity. How are we going to do it? Many ways to do it. The classic lines of code, right? Probably enough of that one said. Maybe we could think about, - hey, issues to done. We're getting into flow, - measuring flow, done, done, done, done. Perhaps, potentially, maybe we could get into the story points. Everyone's got the same size story points. Another fairly tricky area, T-shirt sizes. We do know that when we talk about cycle time, - that's an important thing when we think about value to customers. Developers, the joy that comes - from seeing your stuff being used by customers, - seeing the joy of customers, hopefully the joy of customers - when we release our things, our products. And flying deployment frequency, back to that flow to customer. All of these are potential areas for us to look at - in terms of how we can measure our productivity. But I think I saw in one of Helen's quotes, - we are talking about a multi-dimensional metric, - multi-dimensional picture here that we've got to bring together. And because it's multidimensional, - we like to say it's all about helping developers to be more productive. That's what we're really here for. Help developers be more productive. They know their craft. They're at the coalface. They know. And talk about a statistic. Developers love their craft. We think about open-source projects. Bit of a story there as well. My story, it's Symbian. I joined the Symbian Foundation and open-source Symbian. Open source is a whole topic of discussion I won't go into now, - but 430 million contributions in open source projects. Many, it would be safe to say, many are done in developers' own time, - developers' own commitment and engagement. That's an amazing passion. They love their craft. We should just be embracing how we unlock that joy. That's really what we're about. It's like, - how do we unlock that joy? Because if we do that, - we'll get to the productivity. That's what we're going to talk about today. So we're going to say, - how do we get to focus on developer experience being the right thing? How do we make this true - so that we can get that organizational performance enhancement. And we know that the pressures, we saw those trends earlier on. Constrained growth, increasing technology investment, - huge expectations on things like AI. There is going to be a demand on us - for the continuing future to show that productivity. And we know from DORA, the Google research, - that if you get it right, if your culture, very clear, - I sometimes think with DORA, that people, - especially in the wrong hands, they see the measurements, - they see the activity number, people can make assumptions. Huge elements, as I'm sure many of you know, - is about the culture, generative culture they call it. Generative culture, psychological safety, - and of course, the proof, the insight, - the evidence of visibility of metrics. But that's what we're aiming for. So how are we going to get there, how am I going to hopefully inspire - or give you some things to think about for today when you go back - and put into action or think about and discuss with colleagues and teams? We're going to move on to the four insights, - four ways we think that you can help unleash that developer joy, - lead to developer productivity. The first one, - we think about our teams that Fred Emiry was discussing, right? You know, empower teams, right? When you're working away as a team and you're close to the work, - you have the best knowledge. You have the best knowledge to make decisions. And how do we trust you or help empower you? It is the foundational point to developer joys, empowering teams. And there is no simpler way to do it than to simply ask your developers. So at Atlassian, - we've been using a simple eight-step method. How do we keep coming to this broad social-technical connection? How do we get broad coverage so we don't make those mistakes - of aiming in on a particular metric and getting led off the wrong path? We have these eight steps. Think about speed to ship quality code, - good stuff to customers at good quality, - not coming back to be fixed. Waiting time, the bane of all developers' life. I'm sure there's research here that I've seen some of our colleagues do - that the waiting time is the thing that drives developers around the loop. So how do we address that? Execution independence. If you enable and empower the team that has the right knowledge, - the right tools, how independently they can execute is going to increase - developer joy, it's going to increase productivity. Access to tools, processes, and practices. I sometimes think this one access should be to - the right amount of tools, processes, and practice. We'll talk a little bit about process down the track, - but access to tools, processes, and practices. Being enabled. External standards, particularly when we talk about compliance - and security and things like that. And increasingly, - we're seeing that go further into the stack. It's getting closer, - more cognitive load, more jobs to be done, - more load on developers, things that can be friction - to slow us down from being productive. And optimising how we ship code, our pipeline, our infrastructure, - and ramp-up time. We saw that we've got new people joining an organisation, - complex environments. How can we help them be enabled more quickly, - more easily, safely, giving them that psychological safety from the start? And ultimately, how do you feel? Ask your developers, - how do you feel and get that discussion going, - like some of the discussions we're having here today. So eight-step process. We ask developers these questions. And then simply, we look at, OK, - how are people thinking in terms of their satisfaction? Where are they in terms of - highly satisfied, less satisfied? But actually, - as a team, as an organization, given our goals, - what is the importance of each of these? Because know there's always a list way longer than you will ever get to. And so by putting this stack rank, we can start to get a picture of our - importance, satisfaction, where we've got high satisfaction, - kind of good on our importance levels. That's great. Maybe want to draw attention to where our importance is a little high, - but our satisfaction is low. That could be a good target. Take one thing at a time, pick a thing, - focus on it, set a goal, improve it. That is a developer experience survey. That practice, that play we've just put there, - it's available on the team playbook publicly for everyone. Recommend you jump in. Really easy play, really powerful. So we've got to empower our teams. We've given them a survey. We've given them an insight. But there's something like this leadership conversation. I was just having it with Mark, the leadership conversation, - because it is about teams. But if we take Atlassian, - for example, we've got a new CEO some time back, Rajeev. He's written a lot about this topic as well. But I think that the sort of impact that leadership has to help create - the environment for a great developer experience, great developer joy, - it has to be helped from the top. Now, in Rajeev's case, - as a leader, as a commitment, - he has come in and we have a company-level goal - that says we're going to spend 10 percent of developer time, - capability, on improving developer experience. Now, there's another great Aussie systems thinker, - a guy called Ray Iverson, and I love something he says. He talks about being responsible. "Oh, right, developers, you are responsible for productivity. You are responsible for going faster, better quality, safer, secure. You are responsible." There's a big part of that word called able. You need to be response-able. And we think that you need leadership to help with that job of - making teams able to be responsible. And that's a powerful thing at Atlassian. And it's no simple thing. I can imagine there's people sitting out there today which is, - I'm here at this conference. I've got questions coming from teams. I've got all this work on my plate - of just keeping the lights on or indeed delivering new capabilities. On top of that, what we're going to do is - we're going to bring in that 10 percent of developer capability. That is what we're doing. And it is a whole of business motion. It's a bit like going to the gym. You've got to get fit at the start. But once the business starts to work, we can really connect goals. We can increase joy. That joy can lead to productivity. And so we do this in a simple method. We just label our work. We use some automation rules to connect - that labelling up across all different work as it grows. Then thinking about some of the things Helen said, - you've got to have the insights, you've got to make the data visible. It's going to be important with how we talk to leadership, - keep leadership on board. What we're looking at here is a simple chart. We call it buckets of work. So we've got - change the business, run the business, develop productivity, make it visible. Be responsible, able. Okay, that's the first thing. Empower teams, most important thing. The second thing, remove friction. How do we remove friction? So we know that the shift towards cloud, - the shift towards cloud for Atlassian has been a real journey. Multi-million line monolith applications broken down into microservices, - velocity change increasing. It's a huge cognitive load that is shifting left, - as we sa