 So the first question, I'm going to start with an easier one. So the developer experience is wide in scope and has many facets. From the tooling, the processes, best practices, culture, what elements of the developer experience do you feel are most impactful on productivity and innovation and why? And this is just from your own experience. So there's no, obviously no right answers to this question, but what's the importance for you? So who'd like to go first? I always think when there's an issue of dealing with people, it's all about the context of the person, like the development experience for a junior developer on a mature project is completely different to the development experience needed by a senior developer on an experimental project. So it's fitting the experience to the context. To me, that's the key rather than just focus not just as what we're going to do. Yeah, I definitely agree. And developer experience is something that's subjective, I think is a good point. Everyone has a different experience, so accommodating for all different levels of what that means. Andrea? Yeah, I mean, they're all important, but if I have to pick one, maybe I would go with culture first. Personally, I mean, I've been contributing to open source for a bit more than 10 years. And when I started doing open source, were convinced me to stay there for the next 10 years was really the culture and how you work together, how you build trust relationship with the other, how you really rely on like peer reviews for your work and you value the feedback that you get. And you also kind of build and maintain your tools and you know that you're doing that for your team and the other developers. So yeah, it's all very the culture that is behind it. It's very important. From my perspective, the most impact you can have is fostering continuous improvement as part of your teams, because we've all fallen victim to this is good enough, the status quo is fine, right? And that's not gonna lead to innovation, that's not gonna lead to creativity, that's especially not gonna lead to a developer enjoying the work that you're doing. It just becomes monotonous. But if you're feeling like you are contributing to something that's going to improve yourself and improve the business, then you feel a wider sense of satisfaction in what you're doing. So continuous improvement is a good first step for teams especially. Yeah, and I wouldn't have much more to add to any of those. Mine was gonna be culture. The other kind of piece of that was just gonna be kind of that freedom to fail, which kind of is a mix of culture and continuous integration of ideas and such. But it's letting your developers know that, okay, failure, if you don't learn from failure, that's one thing, but you're never going to get to something new if you don't have some failure. It's okay. But the old thing like fail fast. It's important. That's how you get to a good developer experience is being able to figure that out. Awesome, thank you. I'm not part of the panel, but I definitely wanna make a comment on the culture one. So I'm glad that was brought up as a key one there. And what I think Jeremy alluded to there is something we referred to as psychological safety, is the new buzzword. Back in the day, we just call creating a trust environment where people can fail fast and feel comfortable doing that. I think that's super important. And you can't really talk about developer experience without asking a developer, do you feel comfortable to make a mistake here? Because if you don't, you're not gonna get your best performance out of developers. They have to feel that they can try things, they can stretch a bit and that there's a blameless culture. So to hear a culture come on top there is super, super important and it definitely resonates with me. So let's see what next we can talk about. So, you know, let's talk about the technical aspects for a developer for a moment. So technical stuff obviously plays a huge part of the developer experience. So how important is it to streamline workflows? For example, CD or security and how does that impact the developer experience? In my talk I said, if you are not engaged with the entirety of the process, if you can't commit and see where your code goes, then you feel like it's a black box. And so being able to show from beginning to end, I think it's incredibly important and enabling. I also think people have to be committed to it. If people see that it skipped once and it skipped for somebody else, then it really diminishes the importance of why would I do it? So it has to, even though that sounds like a contradiction of what I said before, that it's context, but it has to be a level playing field for everybody because otherwise people see the results of their tools and they see it skipped for somebody else. So some sort of fairness. Yeah, I agree that it's important for developers to have visibility in what's happening in all the stages of the pipeline. But it's also a lot to know about. So if you're developing your pipeline and you need to suddenly become like a platform expert and security expert and a testing expert and everything, it's too much. And so I think in terms of streamlining, it's important to have platforms that enable developers to focus on what they have fun doing and what they produce value for the application or the service they're working on, but to keep visibility. And I guess that links back to some presentation from all, for instance, like if you have testing, your test suite sending events or you have all your tools sending events and you can expose what's going on to your developers through some standard approach that really helps with that. I think when we think about developer experience, the amount of things, I kind of mentioned in my talk around, the amount of things that we now require, your dev teams and your ops teams to do, creates a lot of that cognitive load that can, the more you do it, the more chance you have for mistakes. And so that's why we've seen this rise of platform teams, platform engineering, is like taking the internal developer platforms that kind of take away that a lot of the manual work that's needed to be done, like we as humans were really, really bad at manual repetitive tasks. We just are. And so wherever that can be removed from the process for a dev to spin up a new environment, like if they need something instead of having to put in a request to the dev, to the ops team and the ops has to go through all these different processes, even with a good dev ops cycle, you're still talking about a lot of cognitive load. And so the platform team kind of step up of like, let's try and create these IDPs that make it a little bit more streamlined, make it a little simpler to roll out that basic thing. If everything is all in the same environment, then there's an opportunity to make that an automated task and then you don't have to get that cognitive load and I think that gives a better, and it helps with the visibility of everything it's going because it's been a platform. All those things kind of trickle down from it, but I think that's where you've really got to kind of start is remove that cognitive load or else you're gonna, like the more you add, then we already have enough distractions, like adding more is just gonna make it worse. Awesome, yeah, Anna, yeah. Totally agree. And what was interesting in your brief that you described earlier, the one that you did not write, but that exists somehow in the ether, you said unlocking developer creativity. And something I think it's really important for us to talk about is the manual and automation frees up your brain space to do actual problem solving and value driving work. And so that streamlined process incredibly helps, but something else that is not technical that you all really, really need to learn about is advocating that you as a developer are creative. So I work in product marketing, so as you can imagine, I see both of the engineering side of the house and the business side of the house. And I'm here to bridge the gap between those two because you could ask any person who might be in sales or perhaps leadership that elusive C-suite person and they might say developer creativity, is that an oxymoron, is that a real thing? Right, and so it's very much about being able to communicate that yes, developers are creative, you all are problem solvers, that's what you're here on earth to do. And so being able to allow you to do those things is going to be the biggest impact. Awesome, awesome, it's like we rehearsed this, you're setting them up here. I just care, I care about it. Absolutely, but you know, and that is one of the things, companies hire very bright people, very technical people, and they did tell them how to do things. Hey, this is how we do it here. And people can feel stifled and don't have that creative freedom. And you're really, you're impacting your best resource when you go and tell people how to do things. You hire them because they're bright, so give them free reign to explore and experiment and stay curious and find new ways to do things. Which, something I heard there was transparency is really important and reducing cognitive load, making it frictionless is important for engineers because it's going to give them more time to be creative and solve problems. But one thing I've heard about, you know, I've heard, I've read about it, I've heard about it is, developers can often face resistance to change. Technical processes can be in place a long time and companies can be quite conservative about wanting to change them up. And you can have someone who has a really smart idea and say, hey, we can do this much better, more cost effective, more efficiently. No, no, no, no, let's focus on the deliverable here. Let's not mess with the, you know, we're focused on the date here, we're focused on deliverable. I don't know if you guys any experience in that sort of a challenge for developers versus delivery and still, you know, recognizing this important creative freedom and allowing those changes to happen when you're against, you know, managers who have delivery dates and don't want to rock the boat because it works as it is. Appreciate your input, but maybe on the next cycle, anyone familiar with that stuff? Oh, maybe the IBM and Ericsson folks might have something to say about this. Oh, dear. We're really keen on that one. Absolutely. But I think it again comes back to people and the context of people. The people who are being, I will say, conservative about process change, they are probably most definitely doing their job and they are doing their job as is specified to them. And as soon as it becomes an us and them, you've already lost. So it's really, really important to get that there is a team that's working together to get that changes because the developers are probably, the creative developers are probably proposing changes that process compliance people are having nightmares about. They're creating stress there. So if there isn't a team working across it, the developers being happy, they're not more important, I think, than the compliance people. But equally, the compliance people have to not be more important than the developers. Yeah, I think it's about, you mentioned the compliance people. Security's another one, the security people are super conservative about changing anything up. It's secure now, if you go and make changes, I'm not sure is that gonna be secure or more secure, but I don't really wanna take that risk. And depending on the security level or the production rating of what it is, they can be more risk averse than looking for creative ways to improve things. So yeah, and you mentioned some of their relationships. Bringing down the barriers between different groups is super important and obviously transparency plays an important part of that. But I think as developers, we can think about things technically, but really relationships are super important to get things done and bring it down the barriers. If you can understand the context of why someone's trying to do something, you can absolutely get more on board and support where they're coming from, which kind of lets talk for a couple of minutes about collaboration and communication. They're obviously key parts of the developer experience and we've heard around different subgroups within companies, communication and context between those is super important. What methods or technologies, keep this open, can we use to leverage and improve that collaboration, that transparency, that communication so that we can all be more on the same page? And then totally open. It can be a technical, it might be, one thing for example we've seen is people doing more light shares, sharing their code and explaining it in real time, rather than just opening a PR, so that can be developer to developer. In my role, I've had to set context with less technical people around why we're doing something and break it down, which is an important one as well. Sometimes it's easier in person to talk true stuff and get someone on site and then they can support their people and you can all get aligned. But alignment is not like a one-way street where it's like, everyone read this and we'll all be aligned. So you really have to, you know, there's technical alignment, there's business alignment, but have you any experiences in those kind of arenas where you might have some advice or opinion? Well, I first wanted to say something about the previous question still, if you don't mind. So, okay. So I think to really, you know, promote like creativity, try new technologies and so forth, one problem is often friction that you may have. So like if you have a system where you have your platform, you have your security checks, you have your evidence or a lot of components integrated together and you want to experiment with one of these components and you want to see if it goes well, then you may risk creating job for the other teams because, okay, now, yeah, it works fine for me, yeah, but what about the compliance team? What about the other teams? And so they need to go and verify and integrate with what you're trying. And so it becomes all very more complicated and more work for everyone. And I think in this context, really, what we are trying to do also as a city foundation, trying to build a more interoperable ecosystem so where tools can work with each other out of the box, this would really help, like, experimenting with new technologies because if you can bring in a new tool and, you know, replace it with a, or use it in parallel to the one that you're using now, but this tool out of the box will create like data that your existing platform can consume. So then you have this data and you can go to the other teams or to the stakeholders and say, well, look, I'm using this tool and this is how it behaves. This is like what the data they produce and then you can take a decision on that without having to, you know, rebuild everything from scratch. I wholeheartedly agree with that because I think that's the biggest, single biggest problem is when change, when one change just has this monstrous ripple effect through the whole system, then everybody gets afraid of it. Once it happens once, then everybody's terrified of any change in the future. The whole idea of something like CD events can help to separate that out. I think it's a key thing. So to go to your question. And just, yeah, so this is around how we can, I guess, improve collaboration and communication, is this? Is that what I asked last? Yeah, yeah. So I think the key, if we're not, I mean, I don't wanna say this. It has to be modeled from the top down. If leadership, and especially like from C-suite down, if they're not modeling that level of transparency and that level of communication and, you know, asynchronous and like all of those practices, it's not going to happen. It's kind of like whenever you have a process in place and then someone says, oh, well, we're using Asana, let's now start using Trello instead. Well, it's great, but if it doesn't fit into your normal thing and not everybody's doing it and then there's five different teams using six different things, none of that happened. It has to start from the top. And so your leadership has gotta just really drive into communicating and being transparent and talking about the tools that they use and using them themselves. I know so many companies that the CEO, the CTO, all the C-suite, like they don't even use the tools that everybody else does. They get special exception so that they can use their own little thing and next thing you know, they happen to be in a Zoom call and they happen to share their screen for something and everybody's like, why are they not? I've seen it happen time and time again and that doesn't create a level of trust around any of the processes you use when those in leadership don't do them. So I think that's like a core piece for that. And I will hearken back to my earlier diatribe about continuous improvement. And I think that building communication is a skill. And so if you endeavor to try to do it every single day, just like you practice coding, just like you practice problem solving, you practice communication too. And it's okay to not be good at it, right? It's not about being a good communicator. It's about being on the level of your team and your team is communicating what you're doing, the value you're producing every single day and it's trickling up to the people who are gonna write your check and it's also going back to the other teams who you're working with. So just endeavoring to be more communicative in your job is already a first step versus just siloing yourself off. I love that, Jeremy, love that. That's definitely something that's important. Having technical leadership, sometimes when you go up the chain, especially as a company scales and I think that does impact the developer experience. The developer should be able to look up the chain and feel inspired and feel that the people in leadership get it, technically, understand the challenges, have awareness, have insights, can offer support on what those challenges are. I mean, the worst case scenario is very hierarchical big company where when you go up the chain, they have no idea what you're working on. They've heard the buzzword but they don't know what it is. I think that can definitely affect developer motivation and can also affect the credibility they have that they're doing the right thing and they have that support. So I think that's super important. We're going for the big guns today. Let's keep it non-political here. I don't have a job at the end of this. But you're spot on though, absolutely. Technical leadership is a huge part of the developer experience. The good part is only the good ones are watching this. Spot on. Touche. One thing you mentioned there, Anna, and maybe you can start with this one. You mentioned around, not everybody communicates the same way. And something that we're hearing a lot about now is around neurodiversity and cognitive diversity. People think about problems differently. People see problems differently. People communicate differently. And we've seen that companies who are very successful in this space have very, very, very diverse groups within their company. They don't, you know, it used to be, for example, we used to hire in a particular way in IT in general where we'd look for someone coming from third level and you know, you end up a group think then. You're hiring, people have come from the same lecture for the last five years and they're all thinking the same. And now companies are recognized the value of hire someone who didn't go to college and try to do a start-up and has all these different experiences that feed into developer experience and technical experience. So companies becoming more open to that, more aware of that. It's a huge subject. But when you think about neurodiversity or diversity in general, what comes to mind? Because it's long gone in the days where diversity was just gender-based. Diversity is so layered now and impacts development. And I'm sure you guys all have an opinion or, you know, something to say about that. But Anna, what do you think about that? I was like, oh, you singled me out. I wonder why. Must be the autism. You were like, oh, geez, definitely. No, it's true. It's much more intersectional than it used to be. Diversity isn't just gender. It isn't just race. It isn't just background. It's also different ways of thinking across all of those things. And so if you are bringing in people of other not neurotypical ways of thinking, then your problem-solving capabilities are expanded. That's the very foundation of it. It's like, if you're trying to solve a problem, that's what products do, that's what software does. And if it's not doing that, what are you even in here for? But if you're trying to solve a problem, then you need creative thinkers. You need like a Benedict Cumberbatch, like a Sherlock, right? He can go into his mind palace and come up with some crazy thing you wouldn't have never thought of. So yeah, I think neurodiversity improves, but it also is intersectional with other cultural differences that you need to be aware of. Yeah, I'm just starting on that, yeah. You know, I remember a large company at least five years ago, maybe more, and they started to actually focus on people who are autistic and creating, like they want to have a 1% workforce who is autistic and actively seek out those people for an advantage over, probably. I think they're still quite successful. I can't remember the exact names, so I won't guess, but it was a huge company. But back when they did that, it was transformational and seeing as, wow, this is so progressive. And now it's like, if you're not doing that, it's like, you're dated. So things are starting to change pretty quickly, which is fantastic. And I think it's giving companies a competitive edge to expand their creative paint palette, if you will, by looking at all types of, you know, non-neurotypical, which is a great term, people, which I think all of us, to some extent, are non-neurotypical, I think. Andrew. My experience, this is, there are some people, and we've talked a lot about here about creative and problem solving and all of those good things that we want. And for an amount of people, that's terrifying. They wanted to be the same as it was yesterday. And that's their safe space, right? And actually, that's their productive space. Putting them in a continuously changing environment, they just, they're just not productive at all. So I think even in our creativity, we have to make sure not to be exclusion, excluding those people, because we need those people. Those people, in a lot of ways, are much more productive. If they're happy and producing, what have been, they will do a job that I'll never do because they'll do the same job and they'll do it again and they'll do it well. I'll try to change it and break it and everybody will be unhappy. So we have to match up both. Excellent point, yeah. What to add? Well, in my personal experience, if I'm, especially if I'm trying something new, trying to continue innovation or improvement, sorry, I guess the worst feedback that I can get is just total agreement. Like, yeah, you're doing the right thing or yeah, that's fine. So I, you know, you need kind of feedback, like different ideas, different opinions, someone like challenging what you're saying. Is it, well, do you really want to do that? Do you really want to do it that way? Or why do you want to do that and so forth? And I found in my personal experience, again, like more challenging diverse environments from different point of view. And this is also something that I started experiencing more when I started doing open source, because you have people from working for different companies, so coming with different cultures, working in different countries as well. So you find very different kind of diversity there. And I find that really stimulating and enriching experience. Yeah, and I think that that's, I guess what we were saying around creating the environment where it's okay to have an opinion that's maybe counter to what's currently happening. And not only is it okay, it's encouraged. Hey, what are your thoughts on this? I don't agree. Oh, okay. Why not? And have those conversations and be comfortable having them that you're not challenging someone who's a grade above or who's made this and developing that communication where you can communicate around your opinion and something where people get offended because everyone knows that's the culture here and you can be respectful and give your opinion and it's respected, which is really important. And I think as well that does come from the top down, which we already said, people when they join companies, they do look to leadership. What's the established culture here? What's the established norm? So super important. So just a couple more questions then. I denote I'm happy developers. Developer happiness is obviously a key part of the developer experience. So for yourselves, what does that mean to you in your role? Maybe you're not hands on keyboard every day. What developer happen is what does it mean to you guys? Cause I think it is definitely subjective in many ways. Yeah, we'll give it to the guy with the beer. He knows how to have happiness, right? It's all, it's just pizza and beer, right? That's all you need for development. Boom, my drop. They'll work 40 hours a day, you know, if you just give him pizza and beer and you can do it 40 times a day if you're a, you're 40 hours a day if you're a 10X developer, right? Sorry, bad joke. No, I think, yes, it is subjective. And I think it's important to, I mean, as it comes to a leadership culture, I think is a good, probably a big part of that answer. Because just as we've identified, like not everybody does things the same way and you know, not everybody responds, all of those things, not everybody is happy the same way. And so the leadership and it's really important for them to understand those that are on their team. And make those reasonable accommodations for, you know, how you interact as a leader with those on your team to understand the things that they do. Understand what makes them want to, you know, want to work. What makes them want to do, you know, really drive a new feature. What are they, like, what is it that makes them get up every day and want to come into work? I mean, some people it is the paycheck and that is okay. This whole thing about like, well, passion, you know what, no, it's okay for people to come to work the way that they need to. And so getting to that, there is no universal way to do it, I guess is the thing. So I think it comes down to leadership and culture to create that space where people have the opportunity to express themselves and to do the things that can make them happy, while also doing the things that they were hired to do. I used to work in video games, so you wanna talk about a happy developer is a developer that enjoys using their own tool, right? And so if you like playing your own video game, that's a good sign. And so that's how I think about it, is if it's painful or boring or stupid and you don't wanna use it, then no other developer will want to do so. So I think developer's happiness is crucial in determining whether or not what you're putting out is good. Yeah, totally agree. Two examples that just came in my mind there in recent experience was around the drive to promote open source and build a community and fidelity. Not one developer came back and we had about more than 200 contributions in the last year. Not one developer came back and said, that sucked, that was a waste of time. Everyone got a sense of gratification out of contributing to something wider than the company, which is, again, finding those opportunities to make people happy, you listen to what they wanna do and provide the space to do it. I think one other one then is around we have an initiative in fidelity or learning days, giving 20% of time back to developers to focus on their own exploration. Not right at the backlog, but go away in something else you wanna explore in your own time and then see if there's anything that relates that can come back into the backlog work. So you're giving people space to think outside the box on something different. And then maybe they're gonna work on an open source contribution on that learning day or maybe they're gonna jump on a different project with somebody else, but it's giving them time away from that constant nine to five backlog work. Yes, it comes down to leadership culture that this is an investment, right? Developer time is valuable and these investments are worth it. And so being able to communicate as a leadership team, why you're doing these things, why you're enabling these things and being able to communicate as a development team, why you want those things, right? Is crucial and that you're both speaking the same language. Again, very much comes down to we need to reach across this perceived gap between business leadership and developers. I might add with that is as a leader, you also need to model that. So if we have model that taking the same time for happiness, taking the same 20% time, if you're wanting your team to do it, you need to model it as well. So any leaders out there, do it yourself. In the US, in messed up all the healthcare and like PTO and all that stuff that's just a little backwards. It is very common that people don't take their time off. And when quizzed about it, there's been a number of studies recently that have said like they don't do it, especially in this like free unlimited PTO, which okay, great. But if they don't see their leadership taking it, then the implication is well, if I take it and they're not, then I'm taking too much and so they won't take it. And so because they're not seeing leadership model it. And so all of these things we're talking about like leadership has to model it in order for a good developer experience, for double, all of that stuff, it has to start. I keep harping on that, but I think it fits so well into this thing about what makes you happy. Super, super Andrew comments. I think two comments. One, I think people for long-term happiness to a business contribution to be working towards an overarching goal that they're happy with. And it can be a very, very long-term goal. It can be abstract, but I think that's what will make people do extraordinary things in their own life and in business. But it's really hard to find those things. And the other thing is I think to try and get the emphasis on being that teams deliver things not individuals because teams deliver 10 times more than individuals. Even though we can be one individual might seem to be the biggest contributor, but for long-term sustainability it has to be the teams. Absolutely agree, absolutely agree.