 Let's get rolling. So thanks for joining us this afternoon. Name is Justin Rakliff. I work at Fidelity Investments. I used to run their OSPO and recently switched my role based around a lot of the stuff that, one, is informing this presentation. But two, lessons I learned from the OSPO itself of kind of doing it, putting policy in place, kind of assisting developers and realizing there was being a mature company. There were other problems that we had that really weren't policy-centric. It wasn't process. You couldn't automate it away. So I decided, OK, I'm going to try to focus it. And so now it's more like a developer advocacy type of responsibility, really looking at how people do their job and some really basic stuff. So I do collaborate with the to-do group and a couple of folks in this room. I live in Raleigh Durham, so the Research Triangle in North Carolina. This is my first conference thing in almost two years. So I feel a little rusty. So as you kind of saw in the title, you can kind of guess what this is about. You can read the quote if you want. But most of us, if you're familiar with the story of Don Quixote, you can remember him going and fighting a windmill. And he didn't think it was a windmill, though. He saw giants. He saw a problem that needed to be solved. Now, Sancho, his best friend, riding along, clearly saw windmills. And the reality was they were windmills. But it kind of raised this thing. And a lot of times when I was running the Ospo, there were times I kind of felt like I was seeing giants. And no one else did. They were just seeing windmills. They didn't really see the same things that I saw, rightly, wrongly. And until I could start resolving some of those problems, I wasn't going to win any kind of debates. I wasn't going to really be able to make traction because it was just more fundamental misunderstandings that, again, we just needed to fix. So I'm just going to give you, because we only have a brief amount of time, kind of three points. That's it. About ways that you can approach this that, again, should be done kind of in concert with looking at a program office, and standardizing, and kind of scaling any sort of open source strategy to make sure that when you build it, they actually will come, that they won't get confused, that they won't be kind of like, well, that's neat. Put a lot of work into that. Maybe talk to some lawyers. That's fantastic. But I don't get it. Why would I do it? I can just go to GitHub and download stuff, or I can grab an NPM. Doesn't really matter. So collaborate, demonstrate, and value. So collaborate. This is one that's really close to my heart. Fidelity is, again, a mature company. We have our silos. We have individual business units with different motivations, different demographics. Some may be managing 50-year-old mainframe apps, and some are responsible for competing against Robinhood. They just have different problems. And as time has evolved, they've kind of broken down their ability to talk to each other. They think that your problems are not my problems, so we need to have our own answers. And we need to kind of, well, you're different. You're a retirement business. You're a retail business. You're a brokerage. You're a market data. All of these things, all these kind of different business models, became essentially barriers to just basic talking to each other. And when we think about open source, if you don't talk to people, it's not open source. It's just not it. If there isn't some place to open an issue or to have a discussion or to throw an email to a mailing list, there's no real collaboration. There's nothing there. There's source code, and that's good, but there's not really an invitation to do anything cool with each other. So again, like any good regulated firm, we have our kind of like for your eyes only kind of stuff. We have lockdowns and firewalls, and these things may not be physical firewalls. They just may be logical, and they may be mental. Just things that get in the way of talking to each other, to sharing ideas, to asking for help, because those things can be perceived as threats. And I just kind of positioned discourse as kind of an alternative to that. Essentially saying, no, you're going to invite people to have a longer dialogue around a problem or something you're interested in. And they may not be from your business. They may not be concerned with retail or retirement. They just make care as novel as that sounds. So a lot of you will just say, well, I just need to deploy discourse, or I just need to deploy Stack Overflow. I need to solve this with a tool. And there's always a place for tools. But just make sure you do research. Just talk to your developers. Make sure that, because a lot of times tools will get added to the portfolio, and no one really knows why they're there. And then they just kind of atrophy. They kind of roll off into the horizon. So look at the way that teams communicate today. Hopefully there's some successful communication. And then just see, OK, what can you do to build off it? Is it something that there is a business culture? All right. I mean, it may not be perfect, but work with it. Go off the things that are natural and organic within your organizations. Don't just necessarily throw a new tool out there and expect that, magically, people are going to start talking. Many companies have Facebook for work, or Yammer, even stuff like Slack or Teams to do some level of broadcast communication. Are those effective? Are they only used for management? Just study it a little bit. Make sure that what you put in place is likely going to have a level of success, because it's going to make sense for people. Look at how comfortable your associates are broadcasting their needs. Do they feel comfortable opening an issue on GitHub? A lot of people don't. I know occasionally I've looked at it and gone, oh man, I'm going to make a mistake here. That can be very pervasive inside the culture. So again, if you throw a tool out there that allows everybody to see what's going on, I'm going to start up an intersource program. And I'm going to invite contributions. Well, that could go in a different direction than you're expecting, because people just may be concerned. They may be risk averse. They may be concerned about what responsibilities that they're going to absorb or be perceived to absorb. And you have to be able to deal with those things, ideally before you put the tool in place, because you can set up your success. You can look at your community goals. You can set up some metrics that are reasonable, something that you can kind of go, yeah, I feel like I'm going in the right direction, or you can flag a time out and say, no, I'm not going in the right direction. There's either something I expected that isn't reality, or just generally a disconnect between your expectations and what the reality is your org does. And a lot of times I know as we've approached intersource, we'll get these just kind of almost odd expectations. They're like, who's going to support that? And I go, okay, you're a node developer. Who supports the 4,000 node modules that you've downloaded? And they're like, well, the GitHub's, the community does. Okay, well, why is your expectation for an open source work any different than your intersource works? It doesn't mean that you can't support an intersource project, but that does take some time. You actually have to build a community and it takes some time to get there. So you have to be able to wrestle with some of these problems so that if and when you deploy some solution out there, people will kind of rationally get it and you can feel success. One that is always fun is, how do your leaders invite collaboration? I don't mean surveys, surveys are great, but again, it's a broadcast medium. It's not designed for an interactive type of thing. They're going to cast a bunch of questions out. They're going to get a whole bunch of data back. Those things are useful, but it's just data. You need to be able to look at if you're going to make a decision as a leader in your organization, do people feel comfortable asking you about it? Why did you choose that? Would this be better? And then what are those mechanisms that enable it? Because again, if it becomes hierarchy, if it just rolls down from the top, you're going to struggle with things like open source. Because yeah, there is the benevolent dictator for life model, but generally, there's expected to be a conversation. If you don't create a mechanism and that people feel like there's a value to having a dialogue, not a monologue, you're going to basically struggle. And you can look at doing it and get, I just did that for fun, but what does your contributing markdown look like for your organization? Can people go to one place and feel comfortable going, okay, this is how to engage. This is the right level of engagement. And this is how to propose my thoughts. Hopefully it's not a black hole email box. Like you want to basically be able to track these things and that that person who's putting themselves out there, they're putting a level of risk out there that you are going to be able to respond to it. So kind of that first time to issue resolution or issue contact. They want to essentially feel heard. So create a mechanism for people to feel heard. We kind of know what this looks like with source code. Just apply those same principles to how you approach your organization. It's incredibly important to, again, foster a level of collaboration, especially from the leadership down. If it's just between peers, again, that's not bad, but it can feel that, again, you're not really solving the hierarchy problem that top down command and control, in this case, Moses bringing down the tablets, may still be the dominant culture. And that just creates friction. It's gonna create problems over time. It's gonna basically stem or limit the ability for your Ospo or your potential Ospo to really get people to understand why working with a competitor makes sense because they're expecting some sort of hard and fast. And then, again, do teams really have autonomy? Sometimes we get put into an organizational construct. It can be scaled, agile, scrum, something or other, like whatever the brand name is. But do they feel like they can make their own decisions? That they can kind of go back to their, I'm gonna call it product owner, and say, hey, no, I don't think this makes a whole lot of sense. Or are they just gonna basically take the order to take the hill? There's a place for that. But it does make this concept of collaboration much harder because people are just not expected and they don't think they are empowered to actually ask questions on how people got to a certain decision. They're not being critical. Retrospective Prime Directive would be like, well, they made the best decision with the knowledge they had at that moment. And that's fantastic. It doesn't mean that it's the right decision for now, though. Only because I don't like using other people's property. You can almost imagine the kind of skinner meme in your head. It's not me, it's the children that are wrong. So I didn't wanna do the references to Fox News. But you can kind of like, if leadership has that mindset where there's gonna push this stuff down and then if somebody comes back and says, yeah, I don't quite buy it, they go, no, everybody else is wrong, I'm right. Like, you need to get in front of that. Cause it's just, again, from an open source perspective, it's gonna create friction. It's gonna create kind of a cognitive dissonance that'll be hard to resolve. But if you name it, you might be able to measure for it. And you might be able to kind of report on it. And hopefully kind of nudge things in a better direction. What's in it for me? So again, this has been talked about a number of times already. There has to be a value proposition. Ultruism is great, but there's gotta be a motivation. For Sancho, it was basically, Don Quixote saying, hey, I'm gonna make you a governor. So I'm gonna take you out of poverty. I'm gonna give you a level up, a significant level up to your standard of life, your family, for your future. That's always in people's motivations. You just need to accept it. So when management is coming in there, we need to be able to demonstrate to them there is value in doing some of this work. So don't just kind of cast things out there. Be really intentional about your metrics. Make sure they're realistic, but be intentional about them. Set up some community goals, set some KPIs. You may miss them. And for me, that's okay. Because you'll be able to say, okay, well that was where I, that was my goal. I didn't meet it, why? And all of a sudden you can start backing in to some of the motivations and things they got in the way. That's incredibly valuable, as you're trying to tackle what could be decades and decades of institutional thinking. So drawing clear and bright lines helps to, one, help you know if you're successful, but then be able to demonstrate that back to your management team, to the associates who may wanna engage in this program and this effort, and say, hey, here's an experiment. Here's what we thought was gonna happen. Here's what actually happened. Good, bad, somewhere in the middle. And just keep iterating on that same topic. Because we still all have a level of self-interest. And we should have a level of self-interest. It's important for our viability. It's important for our careers. We wanna keep moving forward in what we do. We're not just there to punch a card. So the more that you can make sure that you're representing their interests and helping them see that this contribution that they're making actually does have value. Value to their peers, value to the external community, value to management. It's all, it really helps make essentially things logically make sense in people's heads. They start to get it. So kind of the summary. So review how people communicate today. Don't just try something new. Take a step back and see what's working or not working. And then use that to basically inform any next steps. Because if people feel uncomfortable talking publicly or in a large room, they may struggle with things like open source into some level inner source. So your resolution of that is just not to avoid it. It's basically being very intentional about education and to look at ways that you can help your culture. Give people legs up, mentorship, inviting others in who may not have those same hangups to demonstrate how this can actually work at scale. But your organizations are rich with experience. That exists. They have history. They have bias. They have a whole lot of stuff that will help you make better decisions in the future. So pay attention to it before you start. Don't just throw something new out there or start a tool or download an open source project and put it out there because that leap for that associate just may be too great. Invite collaboration into your own leadership decisions. I know often sometimes it can feel like, well, I'm gonna set the standard for everybody else. So everybody else needs to collaborate. Just not me. No, it doesn't work in your household and it won't work in an open source. Lead from the front. Give your, make a decision, throw in whatever mechanism makes sense for your organization. It could be a Wiki. It could be Git. It could be a webpage, SharePoint. Doesn't matter. Put something out there and then invite discussion and make sure that you prioritize responding to that because people need to feel hurt. If others, if it starts generating better outcomes, because that's really what we're all focused on. We all want better outcomes. If that generates better outcomes, better morale, better NPS scores if you use them, other people will follow. And organically this thing will start happening. And then again, set goals. Sometimes this stuff feels really hard. It feels messy. It feels fuzzy. It feels gray. You don't wanna kinda, I wanna see us contribute upstream to 10 projects. Or is it 15? Or is it 30? Just arbitrarily guess something. See what works. See what doesn't work. And you can adjust those goals. Failing a metric is not inherently bad. We need to get kind of unlearn that for ourselves because sometimes if we set a goal, we say if we don't make that goal, well, we failed. No, it may have been too optimistic. It may have been too pessimistic. It's just a measure. We're gonna put something in there and see what the results are. And then keep on iterating. And then to close. So this one's not quite from Don Quixote. It's from Manila Mancha. So you still need to expect more. Sometimes we kind of like, oh man, I'm seeing giants. I should really just see windmills. I should be more rational. I should set the bar lower. No, that's not gonna inspire anybody. You're not gonna win those hearts and minds, especially when it's a big organic change in your organization. By kind of saying, okay, what's the list I can do? Because I'm afraid of a big failure. Or I'm afraid of something kind of bouncing back. I will always say, you gotta be willing to put your badge on the table. You gotta be willing to take some risks. And it's gonna seem a little crazy at times. You're gonna feel a little crazy at times. There's a healthy balance there between a level of insanity and just being optimistic. Knowing that there is more out there in your development communities, there's more passion, there's more excitement, there's more knowledge, there's more value that's hanging out there that just needs to be a little bit unlocked. And it's just like innovation. People don't need to be told how to innovate. They don't need to go to classes now to innovate. You wanna see innovation show up at like 6 p.m. when they're trying to get dinner on the table and kids homework's done and off the soccer practice and that people are incredibly creative when they need to be. They don't need to be told how to be it. They just need to be enabled to do it. So you're gonna need to be a little crazy because that's the thing. Like the crazy people doing crazy things is a little bit fun and it pulls people to you. So, and if you're looking for a job, the career team made me put this up there. Yes, the QR code works. But I think, I have two minutes. So any quick questions before they pull out the hook. Cool, thank you very much. Enjoy the rest of the conference. Thanks for coming out, taking a risk with all of us. I think we're all a little uncomfortable but we're all trying to figure out what's this new thing gonna look like. And it's gonna take some time. Thanks again.