 Good afternoon, everyone. Thanks for coming along today. And no one between you and the weekend. So I appreciate you sticking it out. My name is Nick Penston. I lead cloud engineering in enterprise cloud computing with inside fidelity investments. And over the next 30 minutes or so or 35 minutes, so I'm going to take in a little bit of a journey we've been on for a while now on how we've embedded open source contribution into how we do continuous learning and how we apply it to our engineering excellence in our space. And over that time, I'd love you to walk away with learnings across two key spaces. The first is, where do you start trying something like this? What are the things you need to consider? What are the type of challenges you might meet? And also, when it comes to scaling that out across your enterprise, what are the type of things that maybe you might need to measure for success? And how do you overcome some of the challenges when you start to scale out those things? All right, let's get into it. So first up, quick disclaimer. So what I'd like to start off with is a little bit of context on where we started our journey and then talk about why we did it in the first place. So we had an open source program office started a couple of months before we started this initiative. We built big platforms as part of our group. And we'd been contributing a little bit to open source, but not in a concise and concentrated way. And also, I work for Fidelity Investments. We work in a highly regulated industry. When it comes to contributing to open source, developers often think there's a lot of friction in the way in doing that. And it may not be even possible to do that. So we're really keen on addressing those issues. And that brings us into why we started this in the first place. I'd like to think about that and the outcomes we want to achieve. So the first was we wanted to use open source as a way of learning for our engineers. So giving them an extra channel to apply their skills out in the open. So it comes to contributing to projects we wanted them to learn new skills in that way, but also bring the outside back in to our engineering team so we can lift that engineering maturity bar. The second is when we think about the platforms we build and the open source frameworks and technologies we build, how can we contribute to them to accelerate the velocity of value in our space, but also contribute that back into the community as well. And finally, demystify open source for our engineers and make it easy for them to contribute and clear that path for them when it comes to engaging with the projects that they're really, really passionate about. So how do we start? So we started this journey really thinking about how we were going to apply some of those outcomes. And I'm a really big believer to scale something is not the scale at all at the very beginning. And that's actually where we started. We started by doing something really small. And that was we started a pilot. The pilot ran for about three months. We time boxed it. And when it came to the projects we wanted to contribute to, they were very small projects. But we didn't lock down what we wanted to contribute to. We selected a small group of developers who were really passionate about this space. So really wanting to lean in to change how we were doing things in the open source community and working very closely with our open source program office to understand that friction. And finally, the ultimate outcome was to actually learn. Learn about engaging with the open source community, understanding how it worked, how could we play a big part in that as we went forward. So we met a couple of challenges as we did this. And a couple of key ones I'll call out here the first was we were focused on very small changes. So not like big feature style changes or even complicated bugs. It was really around small changes that we could turn around quite rapidly. The challenge with that was was finding those. We hadn't got a huge amount of experience at that time working with the community and sourcing those small bugs was very, very time consuming. And we were really concerned then about how do we scale this outside this small set of engineers. Not always when it comes to communicating the value of doing this in the first place in your organization, why should your organization contribute to open source and why should your developers be leaning in on that? Again, we probably hadn't taught about that really clearly articulating it. We knew ourselves what we wanted to do, but how do you articulate that to your stakeholders to show the value of this journey? And that kind of brought us on to the next stage outside the pilot itself. So we knew we wanted to scale and we knew we wanted to do that based on the pilot, but we wanted to start off slowly. And going back to the last point there, we wanted to communicate to our stakeholders what we wanted to do. So we had the why and the outcomes, we now wanted to what we were going to do. And what we did there was we created a strategy that we could communicate. It was really simple. We were able to communicate to our leadership team but also the developers themselves. I'm gonna step through this strategy now. It's a three tier strategy and we'll deep dive then later into some of how we did it on the back of it. All right, so the first part of our strategy is what we call nano contributions. And nano contributions mirrors the pilot phase really. It's small changes. It's about engaging our developer and community to get them on to their first contributions in this open source community. Again, understanding the friction now at a little larger scale than our pilot working with our open source program office but ultimately a channel of learning for our engineers. Again, it's about enablement this phase. The second is we call it project clusters. And this is about building expertise in certain frameworks and technologies which we are aligned to from the platforms in which we build. And this allows us to go deeper in the type of changes that we want to contribute to but also when it comes to gaining expertise in these projects so we can ultimately further down the line be able to engage in larger features. And the final phase. The final phase. The final phase is capitalizing on those previous two and being able to really build deep expertise and impact in the community itself. So think about those large features that are gonna accelerate the velocity of value of our platforms but be really meaningful to the community and grow our reputation in those projects and particularly align them to the strategy that we have around our platforms. So strategies are great. They're great on paper, diagrams are great but how do you implement them in the first place? And that was a key area we wanted to make sure that we really took that diagram and communicated out but now start talking about how we were actually gonna do it. So we have the why, the what and the how. I'm gonna step through the first two because I think that fundamentally was how we kinda drove the culture in a bit more detail. So first, one of the big things we did, we used the concept of a steering group in the open source community which often is used to drive projects. We use this concept to drive a lot of our engineering change like best practices and standards. And we took that same concept and used it for driving this initiative. So we created a small group that were really passionate about open source. They were empowered to drive this strategy. So it wasn't coming from a small set of people, it was coming from engineers themselves to help accelerate it. We were just shining the torch in the direction that we wanted to go. The great thing about these steering groups also is we form communities around the steering groups themselves. So they help to share the learning of the experience of the engineers. All that has the knowledge that is that developers bring in when they engage with community who wanted to drive sharing and communities we wanted to drive. And they set a community up around this initiative to help share the experience across the developers. Again, helping us to promote it in the first place. So one of the big things around the nanos also is we wanted to keep those changes really, really small. And we wanted to do them within one to two hours of change. So why one to two hours? So we're very fortunate in Flally to have a learning day every single week. So every Tuesday is a learning day and we use it for learning. And we wanted to use half of that day as a contribution to open source if the engineer chose and the rest of it in to get it out into the community. And that really helped us push this forward really quickly. But we wanted to really keep those changes really, really small and then help demystify that whole open source contribution piece. So how do you measure success when it comes to those nano contributions? Again, I like to keep it simple. We had two metrics around the objectives that we wanted to do here. And it was around contributors and contributions. So how many contributions had we had not measured the impact of those or the complexity, it was all about how many and how many contributors that we wanted to do. So again, it's about enablement. It's about getting people engaged in contributing not about the impact or the complexity of those changes. So what type of challenges did we face as we went through this journey? A lot of them at the beginning mirrored what we had in the pilot. We hadn't necessarily solved them at the pilot stage. So when it came to identifying those small changes, we got a bit better at understanding, engaging with the community around them. So for example, some projects have ways to identify first time committers and things like that. We were using those tags to help us get on those projects really quickly. But it's still very time consuming. And one of the key things too was we had to want the tree hour piece, but we were seeing a lot of engineers necessarily weren't pulling through in that single day, maybe because they were new to the language that we're working on and so on. So we often started to drop off those contributions that didn't fully pull through. So what we did there was to solve both of these problems was we created what we call the mini-jam. So the jam idea was bringing a load of engineers together and getting them to do the contribution together with someone on that call who has experienced, contributing to the open source community. So again, having the help right there in front of them, they're able to talk about their experience. They're able to again, forge those connections which are ever more important now in remote and hybrid environments. And then we saw a massive increase in one, the amount of contributions and contributors because these groups were between 10, maybe 12 in size. And also the pull through rate, bringing it back inside that one to three hours in total. Okay, so onto the second tier. So this is the project clusters. So again, the project clusters are about building expertise in the projects. So the project clusters, they have a limited set of scope when it comes to the projects that are aligned to the platforms we build, the type of software we use, the open source technologies and frameworks that we use. So that actually aligns the engineers through a context of work. So if you're working in Kubernetes platforms, you're gonna be more aligned to Kubernetes style open source projects. So if you're working in OBS availability, style space and the instrumentation, you might be working more with open telemetry or things like that. We saw the gravity of engineers coming around these projects, building expertise on projects which they work on and use day to day. Again, it was all about learning, but building expertise. It's part of their learning paths. It's an opportunity for developers to contribute as part of that learning experience that we had. So how do we measure success from a project clusters perspective? We had, we still measured contributions and contributors, but we had really one metric that mattered here and it was around active contributors. So how do we move from passive contributions? We're doing lots of these across many projects, but being recognized by the community as somebody who's actively contributing more and more to those projects. So what about the challenges into space? One of the key ones was around scale itself. So again, we were, developers were working on their change, they were pulling through, we had some drop off rates. The steering group was trying to coordinate all of this activity now. So we have nano contributions going on, we've lots of them going on. We've project clusters going on, lots of them going on and it became overwhelming for that steering group to coordinate all of these. The steering group was about six to seven people at that time. What we did was we started to federate out the steering group itself and align micro steering groups to each of the project clusters. So it's only maybe about three or four developers now coming together, but they were empowered to drive the mini-jams in their area. They were allowed to drive the communities around that area. And again, they were chaired by someone in the steering group to help coordinate and make sure that we're getting what they needed to keep the ball at moving. This was a great way for us to start to scale outward as we added more projects onto our backlog. All right, so you've got your nano contributions, you've got your project clusters, everything's up and running. What are the type of things that you need to consider as you embark on that journey? And there's about five that really stuck out for us as part of this. The first, and it's probably pretty obvious, is about support. You need support at all parts of the organization when you're wanna embark on this. And depending where you are on your journey will depend on where you lean in here, but support is critical. For us, we were really lucky to have learning days as part of our incubation, we could use it. If you don't have learning days, what sort of support can you get to carve out time for your engineers to be able to do these contributions in the first place? That's really, really important. And articulating that value is also hugely important. What we found was the strategy, being able to communicate that, that one slide, it was really easy to communicate outwards, but again, being able to kind of talk about the value, the outcomes that we're gonna get if we embark on this journey, really, really critical. Another thing is around rewards and recognition when it comes to your developers who are leaning in at the beginning. It's really important to recognize them and reward them for doing so in the first place. Put them out there, show why this is important to your organization, and again, being able to incubate that really good and empower them to drive that forward, your advocates are gonna be key to that. Okay, so we had got our nanos up, we'd got our project clusters. Our next stage was to start embedding this into how we were working. And there was a couple of key areas that we started to drive and look at. I'll talk through a couple of these now that really started to help us move the needle when it came to moving on from outside our learning days and outside your core work to start to kind of drive it in, really integrate it into how we work as engineers. So the first one, I mentioned this a couple of slides back, is around your advocates. You have advocates in different ways, not just your developers. We started off with a small set of advocates who were really, really passionate about open source and changing how we did engineering. We started with them. When we started scaling out our steering groups, again, leaning on people who really want to be involved in this, but also from a leadership perspective, bringing them into who we are advocates, who can support you move the needle and helping you scale that out. It's huge important to identify them, but also bring them together and have that conversation about your challenges with a lot of open and candid dialogue around the challenges we had in the early days and as we still do this today, but connecting them and creating that group to be able to learn from each other as they really help drive and empower it. The second one is about integrating into your learning experience. So we wanted, and one of the key outcomes was to ensure that what we were doing in the open source community was a channel for our engineers to contribute code and learn code. You want to learn Go, you can use open source projects to learn Go. You want to learn, react the same, right? You want to learn more about observability or Kubernetes. Open source is an alternative to be able to apply that knowledge and learn, but also bring the outside in. So when we think about lifting the needle for engineering excellence in your squads, everything from how we did pull requests to code quality, how we were testing, a lot of great stuff came from the open source community and the learnings interacting with those projects. And again, empowering the developer to use it as a tool of learning was key. The third one is, I see these as kind of increasing as complexity, right? As we go through these, is working on the outside. So what I mean there is, often what happens with open source projects is your organization might clone the project, work on it locally, and ultimately, then you're making changes. And then at some stage later, you decide, hey, this might be a good contribution to the open source community. But often what happens there is, by the time you get out there, there might be some proprietary code knitted into it. Maybe you haven't designed it with open source in mind or maybe that feature is already being taken. Think about how do you work on the outside? And when you think of your backlogs, and I'll talk about this in a second, is how do you work outside first rather than inside first? So contribute out and then pull back in. So when you're building your platforms or your software, that you're building, contributing out first versus that. This was a key driver to how we started to really shift the needle. It is a mindset change, particularly when you have to think about the complexity around that. And again, I opened that dialogue, your advocates were key for us to be able to drive this. And finally, a big step for us was to start to move it into our backlogs. So how do you make things that you wanna do in the open source to be in your backlogs? The stories within your team, in your sprints or how you work in your organization. So how we started here was much like how we started this whole thing was starting off small. Small changes, high value. And I'll give you an example of one that was high impact, but we used it as a way to communicate. We had this process and it used this piece of software which had a Helm chart for Kubernetes. And we had a lot of manual toil around it to be able to change it as part of our agreement. So we were releasing this thing multiple times a week. So it was a big overhead for us. So we contributed the change back. We put it on the backlog to change the open source project. We contributed the change back and then pulled it in and it eliminated all the manual toil. And it meant we didn't have to touch it as we built. So that was instant value for us. It was a simple change. Like it was only several lines for us to change, but it showed the impact for us and the value that contribution can bring, but also it was part of that sprint, for example. And we were able to use that as we communicated out that these simple changes can have high value impact. It doesn't have to be those big, big rich features that have that impact inside your organization. And again, celebrating those was, again, a key, key thing. So what about the challenges when you kind of think of your third stage moving from nano contribution to project clusters to embedding it in your work? The biggest one really is when it comes to working upstream and the complexity of it. So what we started to see was, how do you divide your work if you're pushing code to the outside and pushing code in the inside? Having that dialogue understanding the impact on that, you don't want it to slow down your process. You want it to speed it up. But having those open dialogues to be able to understand it first rather than running into it, and then it's going to derail your strategy overall. Again, also, there's a bit of a mind shift change here, too, from an engineering perspective to be able to focus on the outside and being able to push to the outside and pull in. And again, that was another key area that we had to focus on. All right, that's it for me. Hopefully, that gave you some idea about how we took on our journey, the type of things that we taught about as part of enabling open source within our community, within our engineering teams. Happy to take any questions now. Gentleman at the back. So the question is, for learning days, what type of platforms and tools were useful in those on days? So really, from an engineering perspective, we're very fortunate to have a rich set of learning tools online in demand. But what we really used here was no different from an engineering perspective. The tools really were the communities coming together themselves, right? People connecting developers to have conversation. That was how we really accelerated that knowledge across our teams rather than having it in documentations. We do what we call micro-learning videos, where we record maybe one or one-and-a-half minute videos about how to get started really quickly. Any developer will tell you that they don't like reading documentation, so we really try to keep that as a minimum, but drive a true community, particularly because we were learning all the time. This was new to us at the beginning. Great question. So the question is around rewards and recognitions, what worked, what didn't work. So it all depends on the tools you have. Like some tools that we have might be very specific to fidelity, but in general terms, I think one is from an engineering, from the group itself, calling those people out. So we have big events, like most organizations, and calling those people out for what they're doing. But also from a leadership perspective, to show that's important, that what they're doing is important. So again, it doesn't always have to be monetary in relation to that. I think as people go through their careers and different companies reward people differently, that has to be considered for sure. But it's not always about the monetary end. Being recognized by their peers, being recognized by their leaders, they were really, really key things to kick us off. I think things that didn't work per se, sometimes you can overestimate your peers. We all want to be told by your peers that we're doing great. But again, you need more than that, right? And sometimes you might lean in one direction than the other, but I think we learned how to communicate effectively. But leadership was a key thing, right? Getting not just my team and the developers themselves or peers, but the wider community to recognize what they're doing for the firm, ultimately. Any other questions? All right, thank you very much and have a great weekend, everybody. Thank you.