Is Robert. I'm a solutions architect at AWS, and today, together with my friend Christian, who is a customer solutions manager at AWS, we want to urge you to forget about platform engineering and instead think about developer productivity. And what we mean by that is to find a more customer centric approach to developer platforms. Now, what's the gist of this talk? Well, we are asking you to not lose yourself in the traditional way of platform engineering, which means a lot of engineering, a lot of running, a lot of operating, of services, a lot of software, doing this in a very centralized way, and instead compose and integrate readymade cloud and SaaS and only build things if you really must. And this should help you to unlock a lot of capacity, which you actually need to do something very different, which is spending most of your resources on thinking about developer productivity first and foremost, and then working backwards from there from your customers, which are your developers. Now let's go back to the beginning of all of this and understand where we are coming from. There's this guy, Lena Fogels, who is the CTO of Amazon, and in 2006 he said, well, what's a good way for product teams who build digital products? What's a good way for them to work and operate? Well, a good way to do it is you build it, you run it. So the idea is that developers really should be in contact with the day to day operations of their software. And he sees that as a critical feedback loop for improving the quality of a service. Now that sounds fine, right? But there's a little issue here, and it's this thing, and I'm just taking the CNCF landscape here as an example. I do not really want to throw the CNCF ecosystem under the bus, but essentially what you can see here is there's a lot of stuff to think about when you develop a new service. It's not just about the code, but it's about all the things you need to actually run the code, to observe your code, to operate it. And that creates a lot of cognitive load on a developer. One of the things that platform engineering tries to do here is to actually make it easier for the developer to do this, to remove that cognitive load, that extraneous cognitive load, and basically help him be more self sufficient in a sense, a different way to express that is how Fortworx coined it, by saying, well, platforms are a means of centralizing expertise while decentralizing innovation to the customer user. Now that's great, right? We can build a platform that helps developers make their lives easier to have some code, run it, get their infrastructure they need for that and so on. And the way this could look like is shown here on the slide. So again, drawing some inspiration from the CNCF, but there are like many versions of that picture from different communities, they almost look all the same. Which means hey, there's a bunch of platform capabilities you need for developers to run things like okay, you need compute, you need network, you need a database, messaging, queuing, IAM, all these kinds of things. And of course you need some interfaces like documentation templates to put these services together. So that's really great. But there's one challenge here and that is essentially there's a lot of work you can put into this, right? And you can kind of lose yourself in building the perfect platform. And what we often see is that thats can have this very technical view like we have on thats slide, but this has the risk of you going down the wrong path or not the perfect path, and how it looks like if you go into the wrong direction, that's what we see on this slide. It's what I would call the downward spiral of platform engineering, which essentially is running too much things and running the wrong things especially. So the way it all starts is you're somehow prioritizing the wrong work streams and features and from there you start reinventing the wheel by building undifferentiated services. Now those two things often happen because you're not close enough to your user, to your customer, which is the developer. So you're not gathering enough signals, enough data to know what is the biggest friction point that your developers are facing. What problems do they really have and what is the best way to solve them in a scrappy way. Thats way you can quickly help them without boiling the ocean. Essentially the next problem arises. So you build those undifferentiated services like you're again running a lot of infrastructure thats the platform team probably shouldn't run. And now you're spending a lot of resources on operating the services, right? Maybe you're running your own Kubernetes clusters, your own kafka clusters, and there might be reasons to do it if you're doing something very specific, very industry specific, very specialized on those services, but for a lot of customers, actually you could call more of a commodity service and there's not too much value in going very deep with it. And instead it rather helps to use a cloud service for that, or SAS. Now these teams now operate those services and the risk here is that they now attach their own identity to these services, right? We are the Kafka team. We are the Kubernetes team. And that makes it really hard to drive change when these services should be deprecated, should be replaced, should be replaced with something better. So this is really where it helps a lot to not have teams be so attached to the actual services, to the actual infrastructure, and have more of a mindset of this. Hey, what's really our identity? Well, our identity is to improve developer productivity first and foremost. That's our job. It's not our job to run a Kubernetes cluster per se. Now one additional challenge here, or fallacy is here that people believe they are good at building abstractions, because that's something, right? That platform engineering has kind of its job, right? You're saying, well, we want to build abstractions to make it easier for the developer to do their jobs, right? We want to abstract away the infrastructure, the services and so on. And that can be dangerous because building abstractions is really hard. And oftentimes people think about abstracting things away, but they are not thinking so much about the failure state of these abstractions. So essentially, if you think about programming, right, we have abstractions like classes thats try to abstract away certain details of the implementation. But when all fails, right, you still get the full stack trace and then you're like, oh wow, what is happening? What's all happening behind the hood, under the hood? And this is where really thinking hard about what abstractions do. I actually want to build. What abstractions can I build? And which abstractions should I just outright. But because it's easier. Like for example, serverless. And these kinds of things are also abstractions. And the interesting thing about these kinds of abstractions is that they are not just happening at the configuration time, they're also happening at the runtime, right? Because also when the service runs, for example, the serverless, you do not see the containers, you do not see the virtual machines and so on. So that is very helpful to have an abstraction there and finally to round it all off. We made some mistakes in the first few steps, but now without really knowing, without really having the intention, we're kind of building our own echo chamber. And we do this by only measuring what we have, the existing services. So we might do surveys with our customers, with the developers, but we're mostly asking them about, hey, this is what I got. How do you like that? Is that cool? Yes. Okay, great. Then I move on. And we're not leaving enough room to actually ask. Hey, besides leave the services we have aside for a minute, what is actually impeding you during your workday? What is really a point of friction that you would like to have removed and then basically work from that input to figure out, okay, what's the next thing we should build in our platform? And another way, which I really like on how to summarize that is how charity may thats put it. So she's the co founder and CTO at Honeycomb. She recently had a great talk that is linked know perils, pitfalls and faults of platform engineering. And it's an amazing talk. So if you're not taking anything away from this talk, please take away that. You should also listen to that talk because it's really great. And she basically said, well, you have a platforms engineering and the main goal, the main work of that platform engineering organization should be to wrap and package infrastructure needs by running as little infra as possible, right? Don't get stuck on running infrastructure and basically losing the sight of your goal, which is really driving developer productivity. So to sum it up here, we said we want to spend our resources on doing the right things. And to do that, we want to think about developer productivity first and work backwards from that, and especially work backwards from our customers, which are the developers. Now you might be saying, well, developer productivity, that's a really nice buzzword, but how can we actually do this in practice? And fortunately, there is a way to do this and it's called developer experience. So thats is developer experience. Well, developer experience is a framework for a developer or customer centric approach to improving developer productivity. And it's actually brought to you by the team that invented other very well known frameworks that you probably know already, like Dora and space. So in Devex, the developer experience is basically modeled in three core dimensions, which are what you see on the screen here, feedback loops, cognitive load and flow state. And these things really help to the developer model the developer as a, let's say, complex being that has all these needs to be really productive. So fast feedback loops are about doing work quickly, getting feedback very fast, as the name implies. To improve that, you should find areas where actually you need development tools that help you accelerate those feedback loops. And then of course there's cognitive load, right? So everything that distracts the developer from delivering value to their customers by building great products. And these can be many things, right? That's an important point. It's not just the right services, but it's also the right documentation, finding things, making things easy to use and so on. And finally, at the top, there's flow state, which I think developers really know, right? You want to be in flow, you want to be in the zone, which means you are fully immersed in the task of building coding and you don't want to be disrupted so much because that always sets you back quite a bit on getting back into that flow state where you're super productive. So that's the summarize of these three things. So feedback loops, cognitive load and flow state. And what I really like about this framework is that essentially it's very user centric, right? It's very customer centric. It's really putting the developer in the center of all of this and trying to come up with a more complex description, more comprehensive, more holistic description of what a developer is and what they need. And I like this a lot because working backwards from your customer, putting the customer at the center, that's really something we love to do at Amazon. So Jeff Bezos, our founder, famously said, well, being customer centric is an amazing approach because one of the biggest benefits is that customers are always beautifully, wonderfully dissatisfied, even when they report that they are happy and the business is great. So for us, the idea of the devex framework really hits home, right? Because it helps us to really put that customer, which in this case is the developer, in the center, and work backwards from their needs and the friction they experience in their day to day work. So what does working backwards mean? So at Amazon, this is a whole process we use for almost anything. And it starts with asking five customer questions. Who's the customer? What insights do we have about them? What's the prevailing customer problem? What's the solution and the benefit for the customer? How do we describe that solution and that experience to the customer, and how do we test it and measure success? And the outcome of that is that we write a press release. We write visuals. We draw visuals. You can see some of them as an example on the bottom here, like really scrappy visuals. And we write an FAQ to further explain what it is all about, what it is, and also what it is not. And the press release essentially is a way to announce this thing that we're building as a product as it would happen in the future. So how we envision that product being announced when it is released in the end. And this helps us to really put ourselves in the mind of the customer and think about how they would describe the new product. So there's even like quotes in there, like fictional quotes from customers saying what they like about the product and how it helped them. Now this is, let's say very generic process. So how can we use that generic process and use it for platform engineering? Well, we can refine it by the devex framework we just introduced. So in this case, the customers we want to ask to figure out what's the problem, where are they? These are the developers. And we now have a framework to put ourselves into the shoes of a developer to really ask the right questions. And you see on the right, again from the paper how this could look like. So essentially it's made of like three layers. And really the first layer, the perception layer, you see at the top of the table, like the top row, that's really where it all starts. And that row really helps you in that working backwards process I just described. So this is at the very beginning when you ask your developers, okay, what are your problems? Where do you feel frictions? This is where you can come in with these perceptional questions. And this can be done as a developer experience survey. But any survey can also be used to be an interview. So this could be a way to interview users to figure out, okay, what are their problems right now. Now here are some examples. And this is not a comprehensive list of things you should ask. You should come up with your own list of things to ask, but they should basically touch those three pillars we talked about before. So for feedback loops you might ask, hey, are you satisfied with the time it takes to validate a local change? When you start starting your branch, starting your feature about your cognitive load, how easy is it for you to debug a production system? What kind of friction are you experiencing there? And finally, are you able to go into flow state? Maybe you ask how long someone can go into flow state and what is actually keeping you from going into flow state. So this is all how it starts and how you can kick off this working backwards process to come to a better platform for your developers. But then there's also two additional layers that are very important here that you can see on the table, which is the workflows and the KPIs. And the workflows are basically a way to, let's say ground the perceptions that you got from developers in the first place. So these workflows, workflow metrics, they try to be objective measures on how developers are doing. And you could say that they are helping you to figure out what good looks like. Are in general developers on the right track? Are they working on the right things? So for example, code review, turnaround time, is it low? What's the overall time it takes to get a change to production and so on. So are you already working towards improving the overall workflows or are developers essentially, let's say, have they settled in their misery a little bit and feel that things are fine, when really there's still a lot of room to improve and streamline the development workflows. So it basically just gives you a way to better relate to the perceptions you got in the first place from the developers. And then finally there are KPIs. And those KPIs really try to capture the envelope of all of this. So you want to make sure that you also keep the bigger picture in mind. And to do this, you have some higher level KPIs and you want to measure those as well as your North Star metrics, right? So things like the overall perceived ease of delivering software, this can encompass all the things we talked about before. And you want to continuously measure this as well to see that, okay, the various changes at various points that I'm making are still all contributing to a better way, to a more frictionless way of delivering software. It's not like some changes actually reduce that score and I'm running in the wrong direction. To sum it all up here, you can see how the overall process of working backwards from your developers with the Devx framework could look like. So there are multiple phases you are walking through to in the end come to a minimum lovable product. So in the initial phase you align internally, you learn about developer productivity and experience. You're basically agreeing that this is the core goal of what you're trying to achieve and improve. And you set your general innovation priorities and plans for the future. And from there you're starting to listen. So you're asking, who are actually my developers and what insights do we have about them? And this is where you start to use the devex framework to ask the right questions about your developers because, you know, we should ask them about the feedback loops, about flow state and we should ask them about cognitive load. And once you did that, and there are various ways to do it, right, surveys, interviews, picking a bunch of teams, working with the senior developers of those teams, have them as a representative voice of your customers. Once you did that, you figure, but what is the prevailing developer productivity impediment like? What is a common theme thats you find in all these conversations you have with your customers, with your developers and that you set out to improve? So then you go into the invent phase and you actually think about okay, what is the solution to that problem and what is the most important benefit when we implemented that? And then you refine it and you wonder, okay, now I have an idea. How can I describe thats solution to the developers and discuss with them if that's the right experience? Right? So again, you can circle back to your customers and say, hey, thats is my idea of how it could work. What do you think about that? And then you started to test and iterate this solution with your developers. So you try to do this small minimum lovable product that you just scoped and you prototype it and you try it out with some of your developers and iterate a little bit more and then you're ready to launch that MLP at a larger scale. And this process basically helps you to think less about infrastructure, less, starting with, oh, we have this technology that we want to bring to developers, but start actually with a developer instead and then figure out, okay, what kind of technology, what kind of services, what kind of products do we need to mitigate their problems, to solve their problems? So to sum it all up, we are asking you to spend your resources on the right things. We want you to think about developer productivity first and then work backwards from your customers, which are the developers. And to do that, we talked about one very cool tool that can help you, which is the Devex framework, which really helps you to understand your developers and the factors that impede their productivity. What it also does is help platform teams adopt the improvement of Devex AWS, their core identity. So instead of being the Kubernetes team, most of the people are more thinking about, okay, my job is to improve developer experience. Developer productivity with whatever tool is the right tool and tools might change. And that really helps you to stay flexible for the future and also keep your stack, keep your portfolio of services lean, because at some point you will need to basically shut down some of them so that your portfolio isn't ever growing. And finally, when you're working backwards, when you're doing a kind of this process that I described for working backwards and you're doing it with Devex, it actually opens up many different solutions to remove impediments. And it could be as simple as, oh, there's not enough documentation, a simple Wikipage would actually help developers get started or a we don't need to run so many services, we are using the cloud and we have most of the services we need in cloud, but we need a bunch of infrastructure as code templates to make it easy to get going. And we need to document them well so developers know what's going on in those templates. And then finally you might also have the bandwidth to actually think about things like geni companions, which also help developers to simplify their jobs. Thinking in these terms of developer experience, sometimes the right thing to do for developers can be really cheap, really scrappy, and that is really a good thing. And at the same time you also unlock the capacity to evaluate and integrate new ways to reduce cognitive load for developers, like for example those geni companions. And sticking with geni companions here for a second, that's where I will hand over to Christian, and Christian will give us a glimpse into the future of those geni companions for developers and what you will be able to do with them. So let's talk about that. Thank you Robert. Let's talk about productivity and generative AI. Let's jump right into it. So thats study of McKinsey shows that 75% of the global annual estimated gen AI impact stems from just four functions. And this is marketing and sales, product and R and D, customer operations and software engineering. And that really stands out for me because if you add those up, you will be adding them up to 900 billion. That's a lot. So how is thats tied to developer productivity? To answer that question, let's first briefly discuss how to measure developer productivity. So the most popular framework is Dora. They are focusing on deployment, frequency change, lead time change, failure rate and time to restore a service. A more recent one is framework is called space. And they take into account that development actually is a very socio technological process. And they double down on the social aspect, adding satisfaction and wellbeing, communication, collaboration, efficiencies and flow as additional metrics. And the last one is developer experience. So they aim to increase the flow state, reduce the cognitive load and shorten feedback loops. Genai in general will change a lot on what we measure and how we measure developer productivity and activity. And output based metrics will get even less useful than they are today. But what will hold true is the mental model between or behind space and defects. And that is there is no single dimension capturing productivity. You will have to combine quantitative data from your telemetry with qualitative data like surveys. So actually talking to your developers, and the last point coming from Devex basically is developer experience may just be the best proxy metric to actually measure and improve developer productivity. So there's one more study I want to show from Harvard Business Review, and this is not development specific, this is holding true for every employee. Study found that employees are more engaged and more likely to stay beyond three years if they have the right technology supporting their work. While there are a lot of possibilities for having the right technology. This talk is focusing on Genai because it's truly transformational, especially for developer experience. And another McKinsey study shows that it basically states that developers using Genai are on average significantly more happy, more focusing on meaningful work, leading to more satisfaction doing the work, and they are also more often and longer in a flow state. So enough of all that studies. Now let's dive into it. The first use case everybody knows coding companions. They translate natural language to multiple code suggestions and they're matching your development style, your patterns. They maybe know your internal code repos right, and reuse your internal interfaces, methods and tools. They can also provide security scanning or even open source reference tracking, telling you when their code suggestions are coming from open source code so that you can attribute the licensing correctly. But my observation is that in german enterprises, the adoption rate is very, very low. I couldn't find any study. If I would need to guesstimate, I would say the adoption rate is less than 20% for various reasons. And that means there's a lot of opportunity. If you use a coding companion, you're more likely to complete the task successfully and you do so on an average of 57% faster. But if you think about Devex and space, there must be more, right? And yes, there is more. Developers using a coding companion are on average feeling more productive, spend less time searching, are more in the flow, and therefore have overall higher job satisfaction. So coding companions are a great first gen AI tool to improve developer experience and therefore developer productivity. The typical developer only spends 4 hours and 21 minutes coding, and that's per week. That's 52 minutes per day. While that's the median. Even if you check the data set in more detail, you will find that 90% of all developers are coding less than 2 hours and ten minutes per day. And while that may sound strange at first, if you think about it, it absolutely makes sense. Development is much more than coding. And Gartner basically found developers spend 73% on running and maintaining apps and only 27% on innovation and transformation. And let's go briefly through an example for that. You use your coding companion. So it's running on a Kubernetes cluster from your platform team and everything is nice. But then you encounter an issue. So the application is not working anymore as you expected. So you need to dive into it, right? You need to digest logs and metrics and maybe you find, okay, there are issues related to Kubernetes, then you need to interface with your platform team or even learn some Kubernetes skills yourself. So you need to do a lot of understanding and learning. Then you need to design and decide for a solution. You need to develop the solution, review it. Maybe you need to improve your monitoring and testing to increase overall observability and prevent an issue from occurring in the future. The last step is you then need to maintain the app. See, maybe even that happens far too often. And then you decide, no, I want to move out that shared Kubernetes cluster and want to go full serverless to reduce maintenance and running an application. And I have seen a lot of cases where this was a great idea through the cycle again. Right? You will first to understand, have to understand and learn. Maybe the serverless technology decide and design, develop, revue and monitor and test. So the question is, what can we do to flip that equation, to actually give the developers more time on creativity, innovation and transformation, and less time on running and maintaining applications. And the answer is coding companion is great, but what you actually need is a development companion. You need a development companion who is supporting you across the whole software development development lifecycle from understanding and learning, designing, designing, developing, review, monitoring and testing and maintaining. But let's go through it bit by bit. We start with understanding and learning. So the first step you're likely going to do when you need to implement something new, especially if you're new in a team, you will dive in the requirements, but also the confluence pages where like internal documentation about existing environments, nonfunctional requirements to get a feeling for what you will have to do. And there's a lot of understanding and learning to do. The next step is you will design and decide for an architecture. And there's actually a very cool concept in the realm of developer experience to capture the amount of learning you will have to do. And this is called knowledge discovery efficiency. In short, KD Ki is calculated for each developer individually and signifies the knowledge that the developer is lacking or not lacking to complete a task. And the score can be between zero and 100. And if the keydy approach is zero, there's a lot information missing, basically everything, right? There's a lot of learning to do, maybe new languages, new tools, new frameworks, new concepts like serverless. When the key D approaches 100, that signifies a solution where there is no information gap. Everything is known. And this likely only holds true if you are like the almighty all knowing Q from Star Trek, right? And the question now is, can Genai help us in this part of the development cycle? And the answer is yes. So think about you're new in the team, you want to understand an existing app, what does it do? Requirements, what use cases are there? And you ask your development companion to give you an overview about the app. And it does. So what's the information source? And the information source is actually your internal documentation. Also, for the business drivers, it's nice to know external documentation, but this also knows all your internal documentation, your internal knowledge bases, non functional requirements, use cases, whatever you want to understand. And now you understood the app. And the next step is you want to start developing. And the first step is to write a user story. You first would need to dive into, okay, what is the technical part of the user story? But a coding companion knows your environment, it can do so, and it can even create a Jira task for you. So, right, knowing your internal documentation, knowing all the technical environments, even the code of your to do app, the coding companion can successfully. The development companion can successfully create for you Jira task with a user story. So it helps you to understand the requirements and even wrote a user story. The next step would be to design and design for an architecture. And I have an idea, but I'm not sure if the services I want to use are actually allow listed in my company. So I'm not shooting an email to my cloud center of excellence, but I'm simply asking my development companion if the services are allow listed. And let's give him a second. And there we go. Two are allowed and one is not. Next step might be I want to know how can I enable that service, right. It's using my internal database to understand my service control policies. So I want to request that service because I want to use it. And there I go. This is the guidance I need to follow to do exactly that. What we've seen so far, the development companies is reducing our cognitive load because we have a one stop shop to ask questions and get comprehensive answers. This is improving our flow and also shortening feedback loops, right. Because we need less interfacing with central teams. The next steps in development process would be to develop into review. And in this steps, you will likely need to understand the code base and develop new features and have them reviewed. So what the development companies can do for you is can help you understand the code base. In this case, I'm asking it to give me a description, what the app actually does. And there I go. This is all the description telling me step by step what it does, how it does. So aws the development companies knows my environment. I can even ask more specific questions, ask it for improvements, or even ask which compute instance is the best to run that app or how I can run that app in a serverless fashion very easily. Maybe I want to add test cases, my development companion can help me, but I could also want to just get a full feature developed by my companion. And in this case, I'm just asking my development companion to implement an additional piece of functionality, add product functionality. The development companion again knows my environment, so he knows the code base and he now will analyze what he needs to do. And there you go. Right. I get a detailed plan on what it is going to change and where it's going to change it. Thats looks all quite good. And it's even adding tests. Okay, that's great. So I get a step by step approach and the next step is, okay, I click on the smart action button. It takes a while, a little bit longer than what you've seen just here. And there I go, I get the results in the files and the next step is of course to compare them and to check do I like the changes or do I need to ask for another round of improvement. And you can do that in a conversational chat with your development companion. Yes, I also like those changes. It's easily visible which changes have been done and there are even test cases added. Yes, there are the test cases. Okay, great. The next step is monitoring and testing. There are a lot of memes out there telling thats troubleshooting is actually 90% of what developers do. I couldn't find any data proving that, but I absolutely believe that it sometimes feels like that. So a very important thing a development companion could do is actually help you troubleshoot stuff to go faster back to developing instead of fixing bugs. And this video basically shows, okay, I have an app, I test something and as usual, first test always fails. But there's a button, hey, help me fix it. There's a lengthy text telling what is wrong. And there is an answer, short comprehensive answer telling me, okay, something with the permissions that helps me from this lengthy, complex task to a lot smaller one, easier, understandable one. And I now ask, okay, how can I resolve that issue? Takes a short time. And what I will get is a step by step approach on how I could solve that. And again, there's a smart button telling me, okay, generate a CLI command for me to do that. Maybe I don't want to navigate the console. So let's fix it by just using CLI command. Again, it takes a few seconds. And there's the CLI command, I can copy it and I'm good. This is shortening feedback loop significantly and it's also reducing my cognitive load. I don't have to fix everything myself, I don't have to use stack overflow all the time to sort out stuff. But my development companion is actually helping me here. Shorter feedback loops reduced cognitive load and improved the flow time. The last part of the software development lifecycle is maintaining apps, and this is, I guess, the part which is not liked the most by most developers. Right? Let's think. You move into a new project and it's good old Java seven code and you need to upgrade and maintain it. So luckily the development companies can help you with that. So what it does, it first copies all your code into a managed and secure build environment, and then it uses static rules to create a detailed transformation plan on how to upgrade your code and it will use very advanced large language models. Fix every issue occurring during that process, and fix the gaps which are not addressed by static rules to actually upgrade your code. The last step is then you can check the code changes once the job is done right. And this is helping you a lot. Frugal with your time and focus again on not translating old code to new code, but actually building new features. To sum everything up, developer experience is likely the best proxy for developer productivity. We've heard in Robert's talk, and also in my talk, that tools can help you to improve devex, but you have to work backwards from your customers. The actual developers. Think about feedback loops, cognitive load and flow time. Platforms may provide a great abstraction, but those abstractions can be illusions. When they break, then you will notice. And a solution approach to that is to not have a coding companion, but a development companion who can help you throughout the whole software development lifecycle for an understanding internal documentation and large code bases developing code or even whole features testing, especially troubleshooting, updating from old versions and old languages to new ones, and by having an always available mentor whom you can ask everything and who knows stuff. So the idea is actually spend less time building the perfect abstraction. Instead have a development companies explaining it to you. Thank you for listening in.