 Good morning, good afternoon, and good evening, depending where you are in the world. I am Francesco from Italy, and I am a product manager for Spotify, working as part of the platform developer experience tribe called PDX, whose mission is to speed up Spotify by providing teams with a simple, consistent, and delightful experience. In this event, in this conversation, we will talk more about developer experience and how to define and classify the developer experience, the main challenges, and risks connected also to the business. We will discuss about targeting the developers and the techies. We will see the difference between the two concepts. And we will also touch the topic and the role of the role played by open source in all of this. As part of my daily work, I am product manager for a specific tooling that is called Backstage, that is used by thousands of Spotify developers to create the app that you all know, and not only that. And it is also used by most probably hundreds of thousands of developers as part of small, medium, large organizations across all the industries, continents, and their technologies. In one of my previous positions at Alfresco, I have been also the product manager for the so-called Alfresco application development platform used by developers to create applications on top of the services through an open source framework using Angular. That is one of the most up-to-date technologies to create end-user applications. And I have always been an open source enthusiast, being a former software engineer and a consultant, a developer advocate, and an author of books for developers and video courses teaching about development. And if you think that I have done a lot of things, it tells you a lot about my age honestly. This is to say that developers are important to me. I continue to proudly define myself as a developer because I truly believe that development is a great art and a very creative job, when done properly, of course. But developers are not important only to me. They are very much important for a lot of the existing companies because they are helping the business. And this is pretty obvious. In this conversation, we will treat this concept that developers are important for the business as an assumptions, as a believer, because it will deserve a dedicated conversation that is slightly out of topic for this content. It is more a purely business speech and conversation. Instead, I would like to keep the conversation on the developer experience topic. It's very much closer on what I like and where I'm working with, of course. Because developer are important, the business wants the developer to be faster, more effective, and innovator. All of this to be with one purpose in mind, to be ahead of the competition. This is not a new statement. This has been valid for some decades, probably since when the job of coders exists when the developers starts to become professional and IT professionals. But developers and development are pretty broad and generic terms that evolved in the past years. And in today's day, they look slightly different from what it was in the early 2000 or simply 10 years ago. Developers are different in these days. And development is very much different. First of all, we have very different types of developers. We have front-end developers, back-end developers, full-stuck developers, meaning about developers concentrated on the end-user experience, on the back-end of the service creation and development, or both of the two. We have mobile developers. That is, again, a slightly different expertise and development expertise. We have quality assurance testers to test the quality of what is given in the hands of the users. We have data scientists. They are not purely developers, but they are hacking code and they are developing algorithm and portion of codes exactly in the same way that the pure developers are doing. This is very much an interesting conversation, because we cannot classify data scientists as pure developers, and I hope no one will be offended by this. And this is the reason why I often discuss that, I mean, talking about the developer experience, we prefer to discuss that we target the techies. There is a broader term for the developer. One disclaimer is that from here ahead, I will continue to use the word developer, but in reality, I'm talking about techies, and I apologize if someone recognize herself or himself in this definition. Develop is not necessarily a type of developer, so a specific type of IT professional. It's more a methodology, but in some cases, this is used also to indicate what is in the past where this is of mean, and again, it's good also to highlight this. Also security experts is very much important. In terms of type of development, of course there is a match with the front end development for NGUIs, backend for services and APIs, and of course the methodology of the DevOps. But let me also highlight that something that I find very interesting in the market is that when we target developers, often we target the developer internal to an organization as part of the core business, but it's very much important also the external developer, third party developers. Developers, they are our customers developers, our partner developers, someone that is acting outside of the core business of the company, but he's working with our services, our technology, our tooling. All of them, all the developers are dealing in some extent with several different, many different tools. Again, if you are not an expert, the probabilities are complex names, in some cases known, in some other cases not known, but the main concept here is that tooling is very much important and every developer needs to deal with many, many, many different tools. The emerging architectures are simply making this challenge bigger, because if you think about the microservice world, something that is about the world, so in the modern architecture, instead of having one single monolith, one single application, one service is split in many, sometimes those and sometimes hundreds of microservice and every service needs to be developed and probably maintained. Platformization is also the push of the market looking at every service as a sort of platform, so exposing API, exposing services. This is also something that is making all of this even more complex. Let me summarize this. I think it's pretty tangible that developing in today's world is more powerful than ever, but very, very complex. So if you are experienced enough in development, you know that developing years ago was amazing, like it is today, but it was less deep in content, in tooling. Today is extremely powerful. You can do a lot of amazing things, but it's also very, very complex and the complexity is exactly something that I would like to focus the conversation at this point. And if you are an experienced developer, okay, this is hard, this is challenging, but I mean, you can count on your experience and your knowledge, but if you are a junior developer, this in some cases can be really, really, really complex. Complexity apart another historical behavior related to the developers. And the development is about the obvious confidence that the developer has with coding and every and very technical tooling. By nature, our developer is intrigued by tools like the so-called terminal. This is the picture showing exactly what a terminal looks like. And if you want to make a developer really excited, provided him or her with the so-called CLI, this is an example of CLI, where you can raise complex or simple comments exactly in a similar way closer to the source code. Developers are happy to be considered very close and to work and act very close to the code because this is exactly where they feel at home. This is exactly where they feel they succeed in their mission. This is about controlling the machine. Okay, I'm going a little bit psychological and philosophical. I won't go more than this, but the concept in that is that developers are comfortable in working as extension of the code and they feel comfortable in going deeper in the technical parts. Of course, this is not so, let me say human. And so it is something that is attractive for them but needs to be properly. It introduced some complexity, of course. If you mix this complexity with a relevant number of tooling and methodology that we discussed before and you can see here summarized in one picture. By the way, this picture is showing the different numbers of technologies that are used only under the radar of the CNCF foundation. So this is a subset of the existing tooling supporting the developer experience. And so if you, I mean, something that of course it's easy to see here is that if you mix the need of a developer to work in detail and deeper in the tooling and if you see the higher, incredibly high number of tooling, you can imagine the level of the challenge and also another challenge that is part of the developer experience in today's world that is about the fragmentation, of course. That is something that is really affecting the experience of the developers in today's day. Now that we have seen that we started from the problem and we have seen two of the bigger challenges from a developer perspective. We will elaborate a little bit more later on. Let's discuss a little bit about an initial definition of the developer experience. At this point, it should be clear that the developer experience is the collection of tasks, feelings, behavior, reactions and actions in general, done by developers in techies to do their work and reach their goals. Just to be clear, this is not an official definition of developer experience because an official definition of developer experience doesn't exist yet. I'm quoting here, I'm submitting to your attention here a couple of different definitions. As you can see, they're not extremely different. Microsoft One is more closer to the tooling, but not only about tooling. The other definition is closer to the experience. So it's something that is literally going beyond the tooling. But I mean, the important thing to recognize here is that there isn't a unique definition. It is about, there are, I mean, different points of view that we can discuss about the developer experience. And in some examples, the developer experience definition is more on the, again, experience and other cases is more on the tooling. This is what you will see as part of the different articles, literate books and solution as well. Just to share an example of this, probably a little bit on the edge, let me share what I have discussed with one contact in my network that is heading the developer experience for a company, pretty structured with more than 800 of developers. And he's saying that developer experience is also about the chair and the desk that a developer is using. It's about the environment, the culture where the developer act and work. I tend to agree, I think it's right. Developer experience is not about tooling only, it's about also, I mean, how to engage the developer to reduce the frustration of something that is not happening the way that it is expected, how to foster the innovation. But of course, we need to keep the fit on the ground, of course, and being practical. But again, it's a good point, developer experience is a broad concept and a unique and agreed definition doesn't exist yet. Like for example, it exists for the user experience. Before I'm going ahead with the conversation, let me discuss about some obvious statements and questions that can easily come into your mind. Probably you're already questioning about yourself. But okay, but despite the fact that maybe we don't have, or you don't have as part of your organization, a developer experience in clear, are we already doing developer experience? So the fact that we have developers means that we are doing something with and for the developers. Are we doing the right thing for them? Is it now more of a buzzword or of a need in the market because of the complexity? So why this is now is more important. All of those are good questions. Yes, developer experience is not a new concept and we have always done the developer experience approach and help the developers in doing better their job. Since the very first computer where working in a room, for example, in something like that, the conversation about to improve the developer experience was a thing. But in today's world, there is something that is more important probably because the challenges of the developer experience is challenging also the business, is affecting the business. And so this is why developer experience is assuming relevant importance in these days. Just to give you an idea how important is for the business, the developer experience, let me share some examples that I'm hearing from several companies, including Spotify, but not only Spotify. Because, so first of all, let me share an example. This is a Spotify example, for example. In 2015, Spotify was becoming a company with thousands of developers, starting from hundreds of developers and because of the relevant number of hires and because of the microservice ecosystem that it was pretty complex at that time and in general, the number of onboarding days that we were measuring through the metric that is telling about how many days was needed to raise the first 10 PRs. The number literally explodes to 60 days. And this honestly was challenging the business because it was slowing down the business a lot. Talking with many companies, they are going from a monolith architecture to a microservice architecture with many services. One of the most recurring question is who is owning some kind of service? If we have an incident, like for example, long for Jay, if we have a problem or a vulnerability is discovered as part of one's service, who is owning that? If we have to decide where to change all the lock for Jay versions as part of the core business of my company, where I can find this kind of information, something that is challenging every developer is about writing documentation, how we can improve the developer experience in writing technical documentation because this is affecting the business because we don't have documented software. We have a not well-maintained software. We have a low-quality software. And this is affecting the business, of course. This is another topic because if you have to create a new service from scratch or something from scratch, you cannot wait for weeks. It is most of the time in today's day. All of this is getting bigger and bigger and bigger at scale. So if you have to onboard hundreds of developers per year or if you have to manage those as of thousands of services and you need to understand the ownership, this is absolutely affecting the business more than, of course, the lower numbers. Something that is challenging also the company in facing the developer experience is also something vital for the final goal of the business, innovation. And innovation is closer also to the digital transformation and things like that. We don't need to explain the importance of innovation from a competitive advantage. I'm talking about the business. And in development and technology, innovation comes also from the autonomy of the developers to experiment, try, learn, and maybe learn because they failed. And, of course, improve in the next iteration. Developers wants to try new things, be free to try new things. And this is in clear contradictions on constraints and maybe long process that some kind of companies are forced to take. If you think about areas like public sector, pharmaceutical, banks, insurance, the innovation is vital, but it's equally important also having an understanding of the policies, of the rules, of the compliance, and things like that. So, autonomy is very much a need from a business perspective, but at the same time is also a challenge because autonomy is frequently connected also to the concept of chaos, of course. Let's summarize a little bit where what we discuss until now that it's a pretty big chunk of space dedicated to the challenges. And the challenge of the developer experience, first of all, we define the developer experience, but we discuss also the challenge of the complexity. So tools are very powerful, but complex in these days. They are also very fragmented because we have many of them. And there is also the need of the autonomy from a business perspective. All of this making bigger as a challenge at scale. Let's move a little bit ahead discussing about the solution and most in particular, what I would like to discuss with you is what possible solution look like, what is happening in the market and what we are seeing and I am seeing as part of the evolution of the market exactly in this space. First of all, the immediate reaction where almost everyone seems to agree about the complexity. So the fact that developers like to go deep, at the heart of the technical solution, something that we want absolutely to preserve and to provide to the developers. But at the same time, something that we want to provide in the hands of the developer as an option is also something more closer to a human experience. So in this example, you can see on the left, the terminal in the way that developers love. And on the right stuff, on the right side, you see a portal, in this case, a backstage, one of the product where I'm working with, where you can do reach exactly the same goal, but instead of having a CLI, having an interface. Having an interface with fields and buttons that are more suitable for humans. So the principle behind this, of course, is not to replace the CLI with an interface, because developers love the interface, but to provide an alternative. So instead of forcing them to act with the CLI only, also providing alternatives to make simpler and more closer to the human experience, something that is closer to the source code and to the developer experience. Fragmentation is allowed concern as we discussed in the past and in the past slides and companies, but it would be better to say developers are challenged by the need to jump from one tool to another because the tools are not talking one each other. As an example, you need to go to the terminal to manage all the Git stuff. Then you need to go to Terraforma because you want to see the pipeline. Then you need to go to AWS because you have to see the deployment and the cloud environment. Then you need to go to the test, to Confluence to see the technical documentation. So in this four tasks, you have touched four different tooling and all of them with different user experience instead of going in one single pane of glass in one single place where you can find all the information that you may want. Companies would like to, instead of providing exactly to go beyond the fragmentation experience, companies would like to provide a unified experience often connected to the concept of sole services provisioning of resources and solution rather than being forced to go here and there in the organization to receive what they need. The sole services need is very much connected to the following topic. And in this space, rules and constraints are definitely enemies, but at the same time not having the control of what teams are doing is a relevant concern, especially in high-regulated industries like banks, insurance, pharmaceutical, et cetera. This is why providing developers with service tooling where they can have a small medium or big level of autonomy in deciding what to do and how to do it, it seems to be allowed repressed for many companies and good offering in the market. As part of this, there is a concept of guiding the development instead of ruling them. Related to the challenge of the autonomy, there is also the implication of the standardization. So every company needs wants also to provide guidance to developers to do things properly accordingly with the policies of the company, with the best practices of the companies, instead of constraining them to say, yes, you're allowed to do this or not, you're not allowed to do that. Again, in terms of solution, the push and the trend of the market is again, is to react with the ease of use to the complexity, but guaranteeing the flexibility because we want to leave the autonomy to the developers to do the things in the way they want, also going deep to a terminal level to do the stuff. The providing unification views or single pane of glass to do the various things instead of forcing them to the fragmentation and to guarantee the autonomy to provide a guidance instead of a blockers or long processes to again, to unblock the creativity and innovation as part of the businesses of the company. So now that we discuss a little bit about where the possible solution are and what the product are, what the products are introducing as part of the developer experience, what the companies are doing. So first of all, a common reaction of many companies that I'm talking to, first of all, they are seriously thinking to build dedicated teams dedicated to the developer experience. Developer experience teams are often small between two and five-ish in some cases they are bigger than this if they want to cover and they need to cover also some operational tasks like for example, maintaining a pipeline and things like that. Often they are originated by the software architect teams or DevOps teams. And they often start from operational problems. For example, I want to provide the best pipeline and agreed pipeline to a complex organization. But soon they land to a broader developer experience because developer experience is broader than that in exactly the way that we discuss in the initial part of this composition. After the developer experience team is created, one of the initial challenges is about the tooling. Honestly, real tooling to address all of this concern or at least unique tooling are not defined. And one of the bigger concern that I'm hearing from the companies exactly in adopting this tooling is that they want to avoid a trap because honestly, one interesting thought is that we are talking about complexity. We are talking about fragmentation and then what we are discussing as part of an improved developer experience to add the yet another tool or some tooling. And so it seems that the risk here is also that we are increasing the fragmentation adding more tooling, adding more complexity. And this is exactly what we want to avoid. So what the market is telling us. So what's the market segmentation about the developer experience and the tooling related to developer experience because what I'm focusing now, it's more about the tooling because of course, there's not a magic bullet or something that we can discuss about culture and things like that. But again, in terms of tooling, a defined market segment doesn't really exist yet, even if things are evolving pretty fast. And some analysts are starting to see some loud request in terms of developer experience because simply it is affecting the business in the way that we were discussing. If you didn't have the chance to look at this Gardner research, I would highly recommend to go through it. This is really interesting. It is focused about the internal developer portals. We will see in a couple of slides what the internal developer portals are. But it's a pretty interesting example of attention that what analysts are recording from the market. And it is a very pretty good insights about the tooling existing outside and in the market to address the developer experience in this case for internal purpose. In terms of offering, what we see is that there is a clear market segment that is emerging, it's about the internal developer platform, the so-called IDP that of course are targeting the developer personas of an organization. So they are more for internal purpose built to build, of course, as a simplification of the usage of few or some services. So they are often defined by a portal plus a service with one goal in mind, obstructing the complexity of the usage of the services. Most of the times this type of offering in the market, they exist some, honestly, the majority are there. I don't want to quote them because I don't want to tell you, but you will easily find them if you search for internal developer platform. Most of the time they are addressing the develop experience because develop as methodology is pretty complex and it is a key pain point to be abstracted and simplified. But as part of the current offering, there are also developer portals. So portals, they are horizontal to the various services. They are literally single pane of glass that again are obstructing and making simpler. What today is pretty complex and they leave on top of the services. Honestly, backstage is an example of this, of developer portal. And we have many other example of developer product. Many different example of developer platform. This is to give you an idea of what is existing outside. Conscious of time, let me also discuss with you the role of open source. I mean, this is one of my, one of the slides that I enjoy most and this is something that I also discuss in several conversation about the value of open source. I won't go in detail of every item here because it's too complex, but let me say this. The role of open source in the developer experience is the same as other and the other market. So it is an alternative. It is a potential solution to make the developer excited and help them in doing better their job. Of course I am an open source enthusiast, so it's clear also what I support and enjoy most. But again, in terms of business opportunity, the open source offering is the same as in other area. So the open source offering is central, but it is complementary to the known open source offering because it's clear that in some case, and it's absolutely fine, that in some cases some companies may prefer to have some identified and reliable supplier and vendors and they want to trust in some vendors and they prefer to rely on them instead of rely on a not well undefined ecosystem of a community at this point in time. But again, it is clear that open source has a role in the market and also in terms of developer experience is exactly the same. It is central and it provides value equally to other segment and offering of the market itself. Okay, I'm a little bit out of time, so I would like to ramp up and summarize what we discuss. First of all, we define the developer experience and we discuss also why developer experience is important. We discuss also about some overall solution and what it is in the market and a little bit of touch of the role of the source. Finally, let me share some thoughts about the direction of travel, at least from us at Spotify and myself, for sure for myself, starting exactly from where it started, from the beginning. So the mission of PTX is about speed up Spotify and developers by providing teams with a simple, consistent, and delightful experience. I think that simple and consistent now makes more sense to you because simple is closer to the simplifying the complexity, consistent and it's more about reducing the fragmentation. And honestly, my goal and our goal is also the third part, delightful, because our real goals is now in ahead, is one and unique and only, is make the developer happy because this is what we like and this is what we love. Thank you very much.