 So yes, we can go ahead and get this started. My name is Andrew Duckett. I lead developer experience at Discover Financial. When we started this journey to start to uncover what the developer really wanted and how we can really think about moving from customer focus into developer focused for developer experience, we knew that we needed to start with a community model. We need to start with the people, not the process or, quite frankly, the code of the technology. And we knew that in order to scale that, I couldn't have one team or one group of people that led that. I needed to be able to distribute that out into a model that scales. And so I want to talk through some of the characteristics that we use in open source and how we brought that into inner source to kind of scale this. And I'm going to use one use case to drive this. And what we're going to talk about is what we call golden pass. I'll uncover what that means to us and how we use a model of inner source based on open source to achieve that. Before I jump into that, I want to take a minute and just think about what goes on in a developer's mind. And so I give them one requirement, one use case, one user story, one feature, however you like to think about the delivery of work that they're going to do. And at face value, that seems fairly benign and easy. That's fairly simple to implement, whatever that one bit of groundbreaking use case is. But behind the scenes, these are all the things that they need to think about. And these are the things we want them to think about, because this is what enables us to deliver great customer experiences for people. We need to think about resiliency, elasticity, delivery performance. We need to think about how to do automation, how to make this a wonderful and delightful customer experience. But we don't write all this stuff down. So we expect them to be able to pick this up intuitively or naturally. And quite frankly, that just doesn't seem fair to me. I feel like there's a whole lot of things here that need to be laid out. And what that ends up with is we've got an ecosystem where some teams do it one way, and some teams do it another way. Some teams are novel and figure out great ways to do things, but they don't share. And so we end up with this really fragmented ecosystem of hybrid cloud, cloud native, some legacy, some new, some modern, some not. And so the ecosystem is really hard to make choices in. How do I know what the next best thing, action, requirement story is that I should implement? And so we use something called golden paths to help tell this story. And so what is a golden path? Well, to us, the golden path is the step by step by step tutorial that walks somebody through the recommended and supported way to build something. So to us, that's software. We build software for our customers. So this is the guide. You can think of it as like the higher order workflow or the higher order pipeline of steps that need to happen to get something from an idea into production. At the end of the day, the target is production because that's where we see customer value. That's where we get benefit. And so when I think about this, how do I get that next package? How do I set up monitoring? How do I do all of these kind of non-functional things? Teams write that down themselves because they're lazy and they wanna document it for themselves, but we don't see a lot of broad sharing across the organization. And so our view is that these golden paths can help organize and curate the recommended and supported way to do that. And so the reason we wanna do that is because we wanna be able to simplify just getting started. And so when we started down this journey, we decided the user was gonna be that developer on day one. And day one is interesting because the faster that I can get them going, the more productive they can be, the more effective they can be, the more value they can deliver. It also lead, and we'll talk about this in a little bit, it leads to kind of the broadest of the personas that we wanna tackle. So day one, you know nothing about that organization, Discover for example. And so there's a lot of things to start to uncover. There's a lot of learning and training that you need to go through. And so we wanna make that really easy. We wanna do that so that we can remove cognitive load from the engineering experience. And so what I want them to focus on is the feature, not all the non-functional nonsense that we have to do. And the second thing we wanna do is we have this little saying where we want to take rumor, which is me asking the lead who asks the architect, who asks the person how to do something or what the recommended way is. We wanna turn that rumor into a recommended documented approach. And so we like to call this rumor driven development instead of other types of development. And really the only way to find out the best way to do something in the organization is to find the expert and ask them. Again, it creates a lot of cognitive load on both sides. The expert has to be always available and always has to give the same answer and has to be discoverable or findable. And so it creates this environment of grief and turmoil that we don't like. The last thing I'm gonna do, and I mentioned this earlier, is we wanna try to decrease fragmentation. And so again, through the last, and I don't know if your organizations are like ours, but for the last like 10 years or so, we've done a lot of work to what we call modernize. And that could mean anything from cloud native, cloud hybrid, off of mainframe into microservice stacks. But what we found is that all of these engineering teams were figuring out new ways to do that themselves and we didn't write anything down. So we didn't document, well, what's the best way to do that or what's the simplest way to do that? And so what we ended up with was a whole bunch of answers. And to be fair with you, they're probably all good answers, but they're just not consistent. And so if everyone's doing their own little thing, their own little way, though they may be solving the problem, there's really a lack of consistency that means that as I wanna move from team A to team B, I have to start all over every time. And that's just really as a terrible customer experience or developer experience. And so those are the goals that we're trying to kind of organize around. So then we knew this is what we wanted to do. We wanted to create these golden paths. We said, let's make some design goals. So like what would have to be true in order for this to work? And so the first rule of the first design goal is that they define step by step, by step, by step. And so I know that sounds tedious, but when I say step by step, it literally describes every form, every dependency, everything, every team, every person that you need to organize around in order to do something. And so I know you're thinking yourself, well, maybe we could automate that, we could remove steps, 100% could. First order of business though, let's just write it down. So now we have this natural forming set of requirements to start to talk about, okay, well, even though the steps are miserable, at least they're all documented and they're real. And so we knew that we wanted that to be true. We wanted to tell the truth, not try to sidestep or circumvent the processes as they were today. The second thing we knew is that they needed to be extensible. And so this can mean a lot of different things, but what we really mean is like, I don't, what I don't want to do is take one group of people, lock them in a room and have them bestow with every organizational standard across every service team, across every product area that we have. And so what we knew we wanted to do was let the domain experts, right? Let security write the steps to security, let infrastructure write the steps to infrastructure and so on and so forth. And so we need to create a model where they could still be the domain experts and contribute their steps or their processes well. But we needed to tell that end-to-end story. And so there's like this shared responsibility where we have a core team that is going to organize the end-to-end flow. And then we let each subject matter expert, domain expert, what have you like to think about them? We let them tell their own story in their way. And so by creating these like style guides and language guides and templates, we can give them a way to be extensible really easily. And so the third thing that we wanted to do, and this is a little bit controversial I think, but we wanted to make the steps optional. And so when we think about this as recommended, that's great, it's a really quick and easy path to get started, but we also don't want to stifle innovation, right? We want teams to venture off the path or take a step off the path, try something new. And then we know that we need an on-ramp for them to come back, right? And so we do this so that we can encourage innovation, new ideas, new thoughts, maybe even new steps or paths. So we wanna give teams or provide teams room to experiment and grow outside of that path. And so thereby no means required. Now, a lot of people would say if they're required, you know they're doing it and you could use that as kind of like a stick instead of a carrot. In our minds we need to be the carrot, we need to lead them to the path and if they can produce or create something that's better than the current steps, then those should absolutely be rotated in and evolve and curated. We think that this is the best way to find value across teams. What this also means is that they can say they follow steps one through five and then they venture off for a bit, they can come back later if they need to based on timing, capacity, whatever. So I think you're probably asking to yourself, this is all great, doesn't really have a lot to do with open source. And so what does this have to do with open source? Well, when we decided what we wanted to do and how we wanted to do it, the first thing we asked ourselves was like should we invent this? Like should we create this model of community and collaboration ourselves or not? And so we said, well why don't we look at how open source projects work? I think of massive open source ecosystems that are effectively able to do this. Maybe we can learn from them. We can learn how to manage, sustain, we can learn how to write things down, we can learn kind of their processes to create really healthy communities. And so when I talk a lot about this to people, I think when I say the word open source, everybody thinks code, everybody thinks, oh great, you got some software that makes this real or you've got some technology that makes this real. What we mean by that is we've got some processes and some interesting collaboration across communities that can make this real. And so I'm less interested in tech, I'm more interested in the people. The community model that we've created is an inviting open space for teams to come and collaborate. And so this is what I wanna talk about really. I wanna talk about these four characteristics that we see in open source communities. So the first one is transparency. We wanna give them access to the information that they need to get started on that path right away. And so instead of having to hunt from repo to repo, wiki to wiki, site to site, doc to doc, maybe form to form, we've created a holistic journey that's got all the steps laid out, all the resources laid out. And we think that that creates a really inviting and open space. And so I don't think this matters whether you're building software or solving a business problem. Teams need access to the information that they need to be able to be successful. And so this is really the first step that we knew we wanted. And so we've created a repository that outlines all the steps, organizes all the references and links. And then we started spending time in this repository to have centered conversations and provide meaningful context and documentation. The second bit is really about collaboration. And so I don't know how many of you work with engineering teams that all have what they believe in their mind to be the best way to solve a problem, but that happens a lot. We see this as an opportunity, not a problem. And so what we do is we, we A, open the door so everyone's free to participate. We find opportunities that we didn't necessarily think we would find. And so we like to bring together really all lives of developers. So you could be day one, you could be 10 years in, you could be young, you could be old. We like to get all perspectives involved. And so this type of collaboration means that we find things that we wouldn't have otherwise understood. And the way that we do this is we center whether we find docs or code or patterns that are similar. We center the conversation on those specific things. So I put all those people together in a conversation and we effectively say, let's decide. Let's talk about merit. Let's talk about cost and value of each one of your solutions. And then we just write it down. And so at the end of the day, what we find is that they oftentimes will like center around some type of answer, which is in our minds, the golden path. And we use that as the golden path. So nobody is dictating to them what the answer must be. They're arriving at that answer together collectively. So it's kind of a neat pattern that we see. The third is that we want to be inclusive. We understand that good ideas in our organization come from everywhere. And so it doesn't matter if you're a developer, if you're an analyst, if you write business processes or whatever, you're welcome to come to the table and have that conversation. What we like to do is let the people that are the domain experts of the thing draft the best decision. They know more than one individual could ever know. And so we try to collectively get them together to make decisions. And these informed decisions form this kind of meritocracy where the more decisions you make in that domain, the more things you write down in that domain produces more value in that domain. And so we let them understand and create that. And then the last thing that we have really centered on is this community. And so we host a lot of community events where we get people together to collaborate and try to unite on one specific goal. And so if you think about like, maybe there's like an operations issue that happened last week, we unite everybody together and we say, okay, well, how do we make that not happen again? Or what would you all have done or what do you do to make that not happen again? And so these like shared community sessions really help us drive to whatever that value is. And we think aligning to a single value for each one of these steps is really important to understand. And again, writing it down, documenting it, it helps us be successful when we do that. So at the end of the day, what we believe is that the more time that these engineers spend doing things like onboarding, bootstrapping, configuring, validating all like the day-to-day nonsense, the less time they spend writing code. And when they're not writing code, they're not really delivering as much value as they could. And so they're forced to do this thing where they have to like guess how long it's gonna take them to write code but then borrow time to do all of this other stuff. And so that's cool. We've written all this down. They know the steps and they can follow the steps but they still have to kind of do the steps. The steps are necessary. And so it doesn't really address like this manual work that I have to do on the side. And so this is just the start of our journey. We think that the next place that we can go is really starting to talk about, okay, well the steps are really just requirements that you have to go do. And so perhaps we can start to bundle this into types of scaffolding and automation to make this job really, really easy. And by that I mean, perhaps we can create sort of one click experiences where I click a button and it creates a scaffold of new software for me. The interesting part about that is that, A, it's simple and it's easy to get started. Second, we can start to bake in these, what I would call best practice or these organizational standards that we have because we've written them down. We know the requirements. And our end goal is really to simplify and reduce the like time to hello world to create a new thing. So in our world again, that's software that lands in production. Yeah, that's what I have. Any questions, comments? I will be up here for a few minutes. I'll also be out in the hallway. So if you wanna talk about Golden Pass and or communities and inner source open source, hit me up. Yeah. We do not define the differences. We define their characteristics and that's really just location. But from a people and a process perspective, they're largely the same. We treat the ecosystems as healthy and the same. Yeah. You mean like ingestion of component, like sure. Yeah, yeah. Yeah, it's largely, largely the same, right? It goes through the same types of rigors, though internally we understand things like licensing, right? Is trivial and things like that, but like effectively it's the same. Yeah. Yeah, that's a good question. The question was really do we believe that by creating things like scaffolds, we, developers learn less about how to actually create the whatever that foundation is. 100% they do. I think though that like creating that scaffold still requires engineering, right? And so I don't think that it's magic. I think that there are just domain experts that are the knowledgeable parties about that scaffold. I think it's a trade-off, right? Like I would say, for example, like I don't know that a large percent of the engineers in our organization are experts in spring, but we do have a community that we can lean against, right, to help us. And so I think there's just a trade-off you have to walk of. How many experts do you need on that scaffold to be successful, healthy, right, in the community? If it dies and everybody walks away, it's not working, right? Yeah, anybody else? Cool. I will be here most of the day if you decide you wanna talk about Golden Pass again or inner source and open source in your org. Let me know. Thanks.