 Some introduction for me, I'm just a software engineer. I've been a software engineer for ten years. I learned computing by getting Linux distro books in the library and kind of working from that. I have two arguably durable children, three and ten, and I have done pretty much everything there is to do in this field, front end, back end, ops, everything except figure out how to get paid to do Haskell, but that's a secondary story. All right, intersourcing 101 for people that don't know. It's replicating as much of the open source development model within the confines of a company as is possible. Employees can see each other's code. They can raise issues on each other's code, and they can fork and create merge requests against each other's code. This is sort of the core definition. Also, let's talk about oysters, oyster shucking. If you don't know what this is, this is prying open oysters in order to get at the edible meat inside. It's something that pros can do very quickly in under three seconds. Oysters are stubborn, well-armored, and they don't want to open up or change what they're doing, kind of like big corporations. Pop quiz. Have you worked in a medium-large corporation for any length of time? Are you alive? You've been frustrated by the inability of the organization to change, I bet, okay? Just going to put that out there as a guess. Like all organizations, even the big sexy ones, T-Mobile has resistance to change. Some common objections you'll hear, and you've probably heard some of these wherever you work. This is a fundamental change that scares me, and this is something that our group doesn't own that scares us. We've tried this before, it didn't work. Senior leadership, X doesn't understand why it matters, blah, blah, blah. This won't work because of the corner case, all these things. Here's the kicker, though. You can't fight this resistance, you can't fix it, neither can your management, and crucially, as a software engineer, you understand this, neither can you by getting into management, okay? So what, do we give up? We say we can't change the way corporations work at all. It's unfixable, it's too hard, it's too big of a problem. Should we give up? No, we shouldn't give up. Giving up is no fun. Giving up limits the good you can do, and we should get smarter. So you say, okay, but define smarter, at least within the context of an organization and working to change it, okay, fine. Are you ready? Smarter equals oysters. Let me explain. Step one, maximum one. You gotta wanna eat the oyster. Devs are often expected to be passionate about things that they aren't. So make sure that you pick something that you are actually passionate about, whether it's open source or whatever else. Open source is important to me personally, it's how I got into computing. It's what I consider to be, it's the way I think is the ideal way to develop software both in terms of the ethic and the behind it as well as the process. T-Mobile had a nascent open source program that was started by some brave and forward thinking people that kind of operate on the periphery of the company, but it was still immature and largely operated in its own bubble. And some of us engineers and some supportive management within the company heard this concept of inner source. We were like, ah, let's align with our goals of opening up the development culture with NT-Mobile. Let's see if we can bring some of this stuff in. This is important to us because it maps to what we know works, which is the open source model. Maxim two, right season, right tide. This is where GitLab comes into the picture. While our internal community of engineers was grappling with the problem of how to get T-Mobile to kind of adopt inner source, we were also agitating for better tooling starting with the Git platform. We wanted something modern, unified, and we wanted SaaS because we've had bad experiences with the on-prem versions and balkanization there. And the existing on-prem solutions we had were, you know, brought up a lot of corporate dysfunctions. They were segregated by group, balkanized, had defaults that encouraged the wrong behavior, lacked integrations with modern tooling. They were politics over who controlled what. It was just kind of gross. So we were like, hey, let's do SaaS. Let's just sweep all that under the rug. And luckily as this was going on, actually the tools team came under new management and reached out to these engineers that were agitating for change. And we had like some allies who were like, hey, we lucked out. We got allies. The tools team said, hey, we want to change this too. These engineers are likely to need better stuff. We all got and talked. It was very happy and fun. We got buy off on GitLab. It all worked out pretty well. Devs were loving it. Management was on board with it. It was great. I want to make a small point about political capital, though. This term, this core engineer, group core engineers that were trying to push for change. Not everybody has political capital to spend. It's fine if you don't. If you do, though, and you know who you are, if you do, make sure you spend it on your company and your teammates and improving the process for the guy that's coming up next to you because it's way more beneficial than just spending it on yourself, which people tend to do by default. Maxim three. All you need is a pocket knife applied at the right spot. So here's what we brought in inner sourcing. The old three GitLab source control had been scoped by team and locked down by team. You couldn't see what team B was working on if you were on team A unless you went through a process to get permissions, to get added, to see what they were working on, all very segregated. You couldn't see the code of a guy that's sitting next to you at all unless you went through jump through hoops. Everyone agreed that things like collaboration and transparency and cross-team culture of excellence was important. But our tooling defaults did not operate in that framework. And we knew that if we tried to launch an inner source initiative on top of those defaults, it would fail because you could say, I want to do this thing. But if your tooling doesn't support that or doesn't assume that, it's just not going to work. So we had a thought, as we were adopting GitLab, we made the default role that everybody in the company gets as they're dropped into our GitLab instance B reporter. If you're not familiar, reporter has read-only access to all Rebos. They can fork. They can submit a merge request. They can open issues, but they can't do anything else. So we said, hey, let's actually literally, with that one small little change, just make sure that everybody gets dropped into the team mobile instance as that read-only role. Very tiny change, technically. A one-line change was required to flip that switch. But that change is the whole thing, because that flips the default from default-closed opt-in open to default-open opt-in close. And that could be a huge cultural shift if we could get it to stick. All right. Next and four, apply a minor force and pop that sucker open. But don't hurt anybody with a knife. Be careful while you're doing it. We knew that a lot of devs would understand what we were doing and why it was important, but we also knew that there were groups that we would have to convince and talk to, most notably our legal and digital security groups, and kind of pitch this idea to them. So we started there, because we knew those would be the biggest hurdles to get over. We knew there would have to be an opt-out pathway, whether via NDAs or marketing stuff mode. There's always going to be some projects that don't want that default inner-source opt-in open, so we needed an escape valve. And we knew we need to be very clear about the criteria you would need to opt-out of this default open environment, right? It's very important that it was very specific, so people just say, well, I'm going to opt-out, and then don't worry about it. And then we realized, as we dug deeper into this, there was no existing standard around what would allow you to opt-out, what would require your projects to be closed. Like, before the team came along, T-Mobile, there's like some projects were under restricted project mode, some weren't. And the process for actually slicing that up and saying, these are restricted, these aren't, was very ill understood already at T-Mobile. So we realized this was a weak point we could press on. We could actually go to people and say, hey, we need more clarity on what exactly qualifies a project to be closed. And I want to actually point out here, this is important. We did not go to digital security and legal saying, we want permission to open up all the repos. We said, hey, we want more criteria on what justifies closing off a project. Very important phrasing, because it's flipping the assumptions of what you're talking about. You're not asking for permission. You're saying, we were going to do, as a development group, we have chosen to do this. We understand as a need to opt-out, can you please help us with this criteria for opting out? And of course, there wasn't actually one. And we knew that if we did that, we would either get to write the criteria, or it would scare somebody out of the woodwork to be like, well, actually you can't do this because of XYZ, and we could have a conversation there. So we did that, and we went to them for that conversation, and we had some leadership backing, and as I said before, we had allies, and that largely worked. That largely helped us actually shift the script a little bit and pitch it that way. Maxim five, turn it into a party, it's way more fun. Here's the things that we found that tend to work when you're trying to build popular support in a large org. When I say popular support, I mean management, and devs, and everybody else. Make your decisions out in the open. All of them, using an intersource repo as your documentation, vision, source of truth, whatever, is ideal. Make sure you force decisions and discussions out in the open and merge requests rather than email or Slack or meetings. This is a real hard thing for T-Mobile to get their head around in most large companies, but it's something you have to actively, consciously force. Say, let's move this to a merge request or let's at least put a merge request at the end of all these processes so that all that is forced to happen out in the open. Never forget that a complaint is a disguised attempt to get involved and own a contribution. In my experience, that is always true. Recruit people that seem to be opponents whenever possible, okay? Someone that asks a question or it says, I don't understand this or you can't do this because of X, talk to them, work with them and ask them to contribute to the FAQ or ask them to help you work through that and then build some guidance out in the open using merge requests, that actually works. Like, if somebody says this needs to be done, ask them to do it. It's not particularly difficult to roll people in and usually people are willing to do that. Build a stealth community or blue oyster cult, if you will, of like-minded engineers that want these changes and want to improve the culture and are interested in pushing things forward and cultivate that. Cultivate it across remote offices. If you're a company that is not fully distributed and you still have offices in different parts of the country, like as you're trying to build this community of engineers, reach out to the ones in the remote offices because a lot of those guys tend to be, guys and girls tend to feel as if they are isolated already and rolling them up into this community, this informal community is usually much easier because they're very willing and very able to help and become part of that. All right, so reiterate. Here's what we did. We reframed the workflow by changing a single default. We leveraged that to reframe the organizational ask into a request for clarification instead of a request for permission. And we did it collaboratively, out in the open, and we rolled people in as volunteers wherever we could possibly do it. So we did it very visibly, very obviously, we made all our decisions out in the open, and this built popular support within the company for it. All right, I want to leave you with one quote here from Charity Majors. If the senior ICs don't assert their leadership, managers are unlikely to give it to them. If managers try, but senior ICs do not inhabit their power, eventually the managers just shrug and go back to making all the decisions. This is ultimately why this is a change that must be driven and owned at a minimum co-owned by the senior individual contributors. That is 100% true wherever you work. Anywhere, whether it's a big company or whatever, you have to have that or it's not gonna work. You cannot stop and say, well, managers are gonna call this thing to happen, no. Your senior ICs with political capital need to be able to push it.