00:00:08

Good <inaudible>. Good morning everybody. I think some people are trickling in, but I'm gonna get started. Uh, anyways, I think we're on a tight schedule. Hey. Hi everybody. Welcome for, thank you for coming. My name is Leo Koran, uh, and I'm gonna talk to you about developer experience, uh, seven pillars to invest in, to be more exact. So, I wanna talk a little bit about the benefits of developer experience, and then I'll lead into the kind of the different pillars to, to consider when you're investing in it. I'll illustrate this afterwards with the use case of booking.com, where I work. Uh, but for that, first I will provide some context on booking. I trust you're in Europe, so I trust that you're familiar with booking.com. You kind of know what it is. It's a large leading online travel platform, and we invest heavily in technology to kind of take the friction out of travel.

00:00:57

Uh, it's quite an old company, already found that, uh, about 26 years ago, uh, in the Netherlands, bookings data, a screenshot of, uh, what the website used to look like at the time. Uh, it was purchased, uh, about 10 years later by an American, uh, illicit company price line. Uh, and it's evolved quite a lot since then. Uh, we started off with just accommodations, hotels, apartments, but today you can also, uh, book flights, attractions, insurance, car rentals, taxis through our platform. Uh, just a bit of sense of scale. We have about 11,000 people working at booking, uh, globally. Uh, a big part of them in Amsterdam and our headquarters. And we have about a bit over 2,500 engineers of different flavors. Uh, in terms of kind of our, our, our business. I think last year we had near 900 million room nights booked by our traveling customers.

00:01:52

Kind of our technology environment also evolved quite a bit over these 26 years. And the first 20 years we're kind of chugging along, really investing heavily in our accommodations business unit. Uh, it was all focused on just go forward, innovate, experiment, don't look back too much. Uh, so we just had this one travel vertical. It was all developed in Pearl monolith code base, very tightly coupled code and, and business functions. We did a lot of testing and production, like just a bit of testing, uh, before you push it out, wrap your chains in an experiment, push it to production, flip it on, see if it works, and if it reaches, uh, your hypothesis bit about 500 developers. So it was all manageable, manageable environment. Then around 2017, uh, leadership decided to also start exploring and investing in other travel verticals. Like attractions was one of the first ones that that really kicked in.

00:02:48

Uh, and this required us to kind of rethink kind of how we build, how we develop kind of that monolith, tightly coupled code base didn't really work anymore when you want to have other verticals next to it. So we start extracting chunks of code out. This monolith started building services, and that's why we started developing a Kubernetes and also started adopting more modern languages. This area, kind of. We then started also doing our first developer experience investments. At the time, I was responsible for our internal Kubernetes environment, uh, getting that off the ground. Uh, and we don't realize like, okay, we're gonna develop in Java now also, and maybe also build a node. So these developers that built these services, they need a framework, they need some libraries, they need charts, uh, they need a new deployment tool. Uh, so we started creating like different initiatives that would serve these, uh, these new needs.

00:03:41

Uh, so these were really the first devex investments A couple of years ago, around 21, 22, uh, our business started moving into what we call our connected to trip strategy. Really focused on kind of delivering the ultimate tra ultimate travel experience where we kind of combine all our business verticals, all our travel products in kind of one roof, one experience for both booking and experiencing your travel. We need to take more fiction out of your travel experience with this. We adopted, uh, a cloud first approach, really hone in on AWS uh, and then we really realized, okay, now kind of how we've been developing kind of our, our testing strategy, our, our environments, uh, how we bootstrap and, and create services. It's not fit for purpose anymore in this, in this new world now. So we realized we need a whole new code, workflow and environment set up to go along with this, uh, with this modernization effort. And that led to a much bigger investment in developer experience. Uh, I'm currently leading, leading these teams, and we have a bit over 60 people now in our developer experience space, uh, and continuing to grow. Uh, and this also needed because we have over 2,500 engineers developing still on bare metal, better virtual machines doing there still on, on-prem Kubernetes, and moving to public cloud. So this really requires, uh, a great experience to make sure that this works well.

00:05:11

And it's the mission of, uh, of our develop experience team at Booking. Really focus on providing that fast, safe, easy to use bathroom code to production, uh, really taking out kind of the friction so that our developers can do what they love to do and why they join Booking. And that's to develop and deliver awesome travel experiences. If you look at like different definition of developer experience around online, it all kind of comes into this same area. You find things related to, uh, develop developer effectiveness, developer happiness, still delivering quality product. And this is also kind of in the, in the devex realm. There's, there's definitely close connections to this. Uh, but yeah, we really care, of course, about the developers going fast, but doing this safe. And ultimately, we believe that if developers can really focus on what, what they join joined for and don't have to tinker away with tools, do a lot of manual work to get their code released, that should make, that will make them happier.

00:06:06

Uh, they, they enjoy kind of developing travel products, not to manually progress through a canary pipeline or checking logs manually. Just to give an example, to build on this more kind wide developer experience or booking, uh, there's big opportunity for developer experience. Think about, let's say you have 500 services, uh, with a weekly release cycle. If you were to shave off about 30 minutes of productivity manual overhead, then you already gain kind of around 1600 developer hours, uh, or five, six full-time, full-time employees. So there's a big opportunity, uh, to invest in this, as I said, fast time to market, very important for booking. We want to innovate, we wanna move forward. Uh, so developer experience is really needed for us to support the modernization of our platform. Like, if we cannot provide a great developer experience for our developers to work on, on AWS or to develop Kubernetes services, then this is not gonna be lead to happiness.

00:07:08

This is not gonna lead to that faster time to market. We need to be able to respond fast to the markets, to the needs of our business needs of our customers, which also requires this, uh, quick iteration I mentioned. Yeah, of course, we want our developers to be very happy. We wanna make booking a great place to work. And because we have this 20 years of working only in pearl and bare metal, kind of the, the market still kind of thinks often of us, of this, this big pearl shop. So we kind of want to change also kind of the, the, how people see booking, how developers see booking as a great place to work, where you can work with modern tools and have a, have a great experience. So that's also why we think developer experience critical. And of course, quality is always important. Uh, reliable, safe catch issues early. I'll go into that a little bit more.

00:07:59

Then thinking about kind of these, the reasons why you would want to do, uh, invest in a great developer experience. There's some areas then to consider, and these seven pillars I want to talk to you about. Uh, but not completely unique to booking, like they apply to our environment, but I'm convinced that this applies to many different types of businesses, and they will really help you when you start thinking about developer experience, when you start thinking about investment, like how to approach this now, the first pillar, kind of the video, the, the, the, the foundation of your developer experience, a customer focused culture. Think thinking about your customer, and of course, customers in the sense of developer experience. Those are the developers, the, the engineers in your organization. Uh, it's a bit of an open door. You need to talk to them. You need to know what they want, what they need, uh, but for developer experience, as you are very likely gonna change, maybe the way they work, the tools that they use, maybe even some parts, the freedom that they have to do certain things, because you're gonna be impacting that.

00:08:57

It's very important. It's critical to, of course, have your customers, your developers involved in the entire process. Make them part of your, uh, assessment of your design, of your implementation. Create this ongoing feedback loop. Uh, they'll be much more willing to adopt what you're gonna be, uh, changing. Or of course, you have a better product too, because it's catered to their needs. So yeah, give them an active role in your process. Uh, something that's not always obvious is that you need to treat developer experience as a product. Uh, often I've heard also that kind of devex related initiatives that kind of naturally evolve from engineers, spotting challenges, things related to DevOps culture that are being done, like automation is introduced, which is all great, but at some point you need to elevate this and look at your entire developer experience and really treat as a product with a life cycle, with a roadmap, of course, with customer feedback loops, with customer engagement, uh, with a lot of, a lot of active communication about it and evolution.

00:10:01

Uh, when you treat it as a product, that also means that you need to invest in another product. So we, it's a job for people. So invest in, uh, product managers. Uh, if you have large projects that require a role out across your organization, invest in program management and project managers like this needs to be somebody's job. Uh, and engineers, of course, they can, they can help out with this a lot, but it's a, it's, it's a skill by itself. Uh, and developer experience team has said, we have about 60, uh, 60 colleagues driving that now and growing. Uh, we have a, we have a product leader in developer experience, a booking that really looks at our entire developer experience as a product. And there's product managers in individual teams that focus on our Java ecosystem or on our CI and CD tooling, our coding environment.

00:10:48

Uh, they all have a product manager responsible for that space, responsible for their engagement and feedback loop with our customers. Another critical part of kind of the foundation, A second pillar is a shared developer workflow, uh, shared developer workflow. You can see there's a framework of processes, tools, best, best practices that really covers your entire, uh, software development life cycle from design all the way up to release operations, deprecation, uh, and this is your, your code workflow. So the different stages that are part of your, uh, developer life cycle gates that you have in those stages. A quality strategy that indicates what practices you must or should, should follow. Uh, and this is different. This really differs per company, like a banking company or an e-commerce company, a gaming company, they will have a different code workflow, a different kind of quality strategy based on the, the characteristics of their, their software lifecycle and regulatory restrictions and the freedom.

00:11:48

The company culture also plays a role in your, your developer workflow, the amount of freedom that you provide to your developers that will dictate also the, the kind of gates that you have and the, and the responsibilities and roles. Uh, the, the DevOps Summit organization asked for all the speakers to reflect on, like, okay, in your transformation, like where do you start? Uh, these two things, this foundation is where I would've started, if I know today what I knew 10 years ago, uh, well, eight years ago, I've been a booking for about eight years. Uh, we definitely started first also with, as I said, when we launched our Kubernetes platform, we, it focused on the first steps with developer experience, different initiatives, a Java framework, a deployment tool. Uh, we didn't start right at first with investing in this customer culture, investing in this developer workflow. And these are things are critical to build other things on top of, you need this developer workflow, clear 'cause it's critical input for the other pillars, things related to tooling, related to freedom related to automation metrics.

00:12:55

And now I'm gonna take a sip. So the next pillars, uh, kind of the, the, the middle layer of your developer experience, uh, unified set of tools. It's kind of an open door. Uh, I'm sure you all realize the importance of tools and why you need them. Um, starting all the way from like language frameworks all the way to kind of your, your deployment and your operational tool set, uh, for develop experience. And what I've seen is you can go nuts with the breadth of tools and different open source solutions. Uh, let developers pick whatever they want, what works for their, uh, for their personal productivity. There's not always ideal, uh, important developer experience is their, your developers have a frictionless experience that they can go fast. That means tools need to be well supported. You need to have the right training materials for them.

00:13:42

You need to be able to support them well. Uh, so this might result in you needing to, having to center around a smaller set of tools so that you can guarantee this, this quality of, of service to your engineers, uh, and make sure that you can really leverage all the automation that they provide. And here, you, you get into situations of, Hey, what do I build? Also in your developer experience organization, your engineers are costly. Uh, yeah, they're costly. So you need to be very mindful, uh, in terms of buying versus building yourself now, and bless you in terms of kind of the tools, uh, yeah, your engineers, engineers, your organization, uh, they're, you're, you hire smart, costly engineers. So ideally you want to just get out of their way and let them, let them do what they do best. Uh, but still you need to consider where you give engineers freedom and where you are opinionated about this.

00:14:38

Uh, and these where you want to be opinionated that is personal to your organization. And that should be very clear in kind of the developer framework, the code workflow that I've, uh, talked about. And some companies, security is maybe the most important thing. Things like compliance, quality restrictions, uh, maybe restrictions that'll allow you to operate a platform with greater ease or architectural guidance that you want to embed in the, in how developers work. Uh, and things relate to efficiency of you want to reach that high productivity. So you will very likely need to put in restrictions for your engineers. Of course, a great way to do this is by just templatizing a lot of, a lot of regular tasks or templatize, how you bootstrap a project, how you configure, how you set up your CICD pipelines, different operational tasks. Uh, there's a lot that you can read online about how Netflix and Spotify have done this through what they call, for instance, golden paths or blast paths.

00:15:35

Uh, but this is really a way to simplify bootstrapping, provisioning, configuring, and operating your systems. Uh, booking, for instance, we've templatized it's quite common, like the deployment pipelines where we are opinionated, you have to use harness as a tool for Kubernetes and A DOS deployments. You have to use this set of templates. But then within the templates, we have a small layer that is mandatory settings that we require from all of them so that we can safeguard security and compliance. But a big part of the template is completely open then for engineers to, to configure themselves things related to triggering certain tests that they might wanna do. Uh, things related to rele, to, to their release orchestration steps in their canary process, how big they want those steps. Those are the things we then allow them to, uh, to configure themselves. So we kind of provide this freedom with the guardrails that we care about as a company to set nella metrics.

00:16:34

I think every talk so far has mentioned Dora metrics, so I'm gonna do it too. Dora metrics, very obvious place to start. Uh, but there's a lot of other metrics that are also critical. It's both, I care about these metrics for Maya developer experience team, so that we understand where are potential bottlenecks, uh, in our environment, uh, whether there's potentially quality, quality issues, adoption issues, so that we can prioritize those areas and then continue and have a feedback loop of assessing, did our changes reach the right, uh, right effect. But it's also, I also want to make these metrics available to the engineers, my customers, and their leaders. 'cause when you have freedom with guardrails, if there's freedom still, then you need to give, uh, engineers the data so that they can decide how they want to use that freedom so that they can have, uh, make their own choices related to their testing and release strategy.

00:17:27

And there's, besides Dora metrics a very focused area, but in developer experience, I also care a lot about metrics related to adoption. It's a bit of a fan metric in the beginning, like, Hey, our developers using the tools that we've developed to them. But it's also good to know with adoption, like how is it staying up to date? Like, have they adopted, uh, the latest versions of libraries that we prescribe? Uh, but also the throughput are really important metrics. Uh, how many builds are being created? How many times is the deployment, uh, triggered? How many merch requests are being submitted? Kind of the quality of that. Like, do things fail and pass? How many vulnerabilities are found? And of course, speed. Wanna understand how long are, do developers stay in certain stages, ages.

00:18:10

Uh, kind of segueing off the, the, the previous stock related to security compliance. Uh, of course, most business have some sort of regulatory compliance, but of course, we all want to have a safe, uh, secure product and, and our data also. Uh, and this is really something that should be embedded ideally from the ground up in the developer workflow. Shoehorning in security and compliance controls afterwards in tools is painful and usually doesn't lead to the best. And the smoothest, uh, developer experience, all these things are commonly referred to as kind shifting left, where you kind of put security and compliance checks at the right place early in the developer process and provide that feed feedback at that point. Um, and then the last pillar, kind of the roof over our developer experience house. Like at the bottom, we have, uh, the customer focused culture, but we also need to have a leadership culture that supports developer experience.

00:19:05

Uh, you cannot create a developer, a great developer experience in an organization only bottom up. You need support to drive forward to change. As I mentioned before, too, certain parts of developer experience take effort. It should be somebody's job. So they're over. Then require funding, which you'll need leadership support for. Um, also mentioned like sometimes developer experience result into changes for engineers, changes to how they work, expansions or limitations in freedom or tool choices. You need leadership to reinforce the, the message about this so that it gets adopted and accepted. Uh, and lastly, yeah, developer experience is also a culture. And we want this leadership also to enforce a culture of an importance of developer experience, both from a productivity but also a developer happiness. Now I wanna talk about a, a case that we had, uh, booking, uh, in, in our developer experience space related to our, our how we build, uh, how, how we build software.

00:20:05

Uh, we didn't have, we didn't used to have a standard way of creating builds, creating release artifacts. When we moved to Kubernetes, we kind of let developers take care of this themself, put it in artifactory for deployment. And, uh, that was the way forward. So it was not really not good support, uh, no standardization, and we lacked a lot of visibility. Uh, this was not ideal from a compliance point of view. And this sometimes required teams to after, uh, during an audit cycle, manually provide like overviews of like, Hey, these are all the deployments that they've done. Not great. Uh, but we also like visibility on tools that were being used, how long builds were taking, kind of all the performance aspects, uh, sort of flying a bit blind. Additionally, of course, we wanted to integrate some tools in this build process for security needs, like vulnerability scanning, code analysis, and that integrating that inner process that doesn't really exist.

00:21:01

Where for, where there's no unified tooling also, yeah, not a good situation to be in. So we developed something called Common Build, not a very imaginative name, but it kind of does what it says. It's a unified way of, uh, triggering builds. And we defined this together with our engineering community and leadership. We talked to them about like, Hey, what are things that you care about in your build process? And what are the things also that, that you're willing to let go, uh, where we can be, uh, more standardized? And we did the same with leadership. We talked to all the different stakeholders like security, compliance, change management to come up with this, uh, solution. Uh, and the end, it's not very complex. It's a, it's a set of GitLab pipelines that are triggered always at the same time when a merge request is finished, uh, and it ends when your artifact is in artifactory.

00:21:52

Now this unified solution mean meant that we could well support it. Well, uh, this was small graph of how we were able to reduce the build time, which is quite drastically. Over a two month period, we're able to, 'cause we had better visibility, we're able to improve this build time. And then because it was unified solution, this was a big change and a big, big win for all engineers. And we were opinionated where it matters. So we, we are required. Everybody has to use trigger builds a certain way. We're all gonna use service accounts a certain way. Uh, but where we gave developers freedom is, which, how they generate their artifact. Like a lot of Java engineers like Maven, some like Gradle, some even like Basil, uh, and a node. They like NX and yarn. And we're fine with that. Like, that's, that's their goal.

00:22:38

We provide some guidance, but they can pick this, this, this is something that they cared about. And we, not so much essentially a visibility that was a, a huge win. Like we, uh, we got so much views on how it was being adopted. There were no more need for manual audit drills. We could see the performance and then optimize it. As I shown, we know exactly the throughput, how many builds are going through their success rates, how long it takes. And we have insights and quality that we get from all these scanners. 'cause that was also, it's easily expandable since everybody triggered builds the same way. We, we, we run them the same way we can, we could integrate sonar cube easily, or integrating s NCC now for code, for a static code analysis for integrating, uh, tic for image scanning, all kind of standardized. It's very easy now for security and compliance to kind of experiment with a different tooling, different integrations, uh, while getting feedback on how that impacts the, the productivity and how long it takes to create builds.

00:23:40

So kind of what I yeah, want you to take away from this like developer experiences is quickly worth investing. It. Uh, if you just assess kind of, Hey, what does my workflow look like? Where do I see opportunities to improve this? If you extrapolate this out to the time that it saves, ultimately it easily turns into a number of fts, a number of people that you could hire to kind of fill this. And then it becomes kind of a, almost a waterfall. That team will then be able to spot other areas, opportunities for change and improvements. Uh, yeah, it'll make your costly developers and your organization more productive and and happier about this. Uh, and really, yeah, the cost outweigh the, the benefits quickly. When you invest in developer experience, try to treat it as a product. Don't make this a side job. Really invest in, in product management for this to, to, to design and operate as well. And the seven pillars that I talked about, I think they can really help you to think about how you would wanna, uh, develop, uh, and invest in it. Thank you.