GitLab Digital Transformation & IT Modernization for Gov't & Reg Industries, 20 Jan 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Commit San Francisco 2020: Shucking Corporate Oysters-Kickstarting an Innersource Culture @ T-Mobile

Description

T-Mobile is in the process of migrating to GitLab.This is the story of how a few rebel engineers with some executive backing are leveraging the migration to sneak radical openness into the corporate development process.

What you’ll learn from T-Mobile Principal Software Engineer Benjamin Leggett:
- What works, what doesn't, where you should start, who you should involve, and what organizational and technical hurdles you should aim to demolish first.

Slide deck: https://drive.google.com/file/d/1irYSkI-v7asMz4m9tqd0oW_pEvLapa49/view?usp=sharing

Read more about our product vision: http://bit.ly/2IyXDOX

Learn about FOSS & GitLab: http://bit.ly/2KegFjx

Get in touch with Sales: http://bit.ly/2IygR7z

A

Some introduction, for me, I, am just a software engineer. I've been a software near for ten years, I learned computing by getting Linux distro books in the library and kind of working from that I have to arguably adorable children. Three and ten and I have done pretty much everything. Here's to do in this field. Front-End, back-end, ops, everything except to figure out I, get paid to do Haskell, but that's the secondary story, all right in resourcing 101 people that don't know it's replicating as much of the open-source develop model within the confines of a company.

A

As is possible, my employees can see chose code, they can raise issues on each of those code and they can fork and create and merge requests against each other's code. This is sort of the core definition also, let's all my voice, ters 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 30 seconds.

A

Yeah boy stirs 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 the medium wash corporation for any length of time? Are you alive you've been frustrated by the inability of that organization to change. I bet. Okay, just gonna put that out there as a guess.

A

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. It scares me, and this is something that our group doesn't own. It 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 the quarter 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, isn't it suffer engineer.

A

You understand this. Neither can you by getting into management. Ok. So what do we give up? We said 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?

A

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: ok, but define smarter, at least within the context of my organization and working to change it. Ok, fine! Are you ready, smarter equals oysters?

A

Let's, let me explain: step 1, Maksim 1 you gotta want to eat the oyster.

A

Devs are often expected to be passion 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 considered to be a it's. The way I think is the ideal way to develop software, both in terms of the ethic and the the behind it, as well as the process.

A

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 inter support. You were like, ah let's, let's, let's you know, this aligns with our goals of opening up the developing cultural identity.

A

Mobile, let's see if we can bring so the stuff in this is important to us, because it maps to what we know works, which is the open source model Maxim to write season right tide.

A

This is where gitlab comes into the picture, while our internal community of engineers was grappling to the problem of how to get t-mobile to kind of adopt inter source, we were also agitated tooling, starting with a git platform. We went in something modern unified and we wanted sass, because we've had bad experiences with an old print versions and balkanization there and the existing oats on Prem solutions we had were you know, prods up a lot of corporate dysfunctions. They were segregated by group. Balkanized had defaults that encouraged the wrong behavior liked integrations modern, tooling.

A

They were politics over who controlled what it was just kind of gross. So we were like hey. Let's do SAS, let's just sleep all that under the rug- and luckily this was going on. Actually the tools team came under new management and reached out to these engineers that were actually in for change, and we had like some allies were like hey. We lucked out, we got allies, the tools team said: hey, we want to change this to these engineers would likely need better stuff. We all gotten talked.

A

It was very happy and fun we got by off on get lab. 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 we're trying to push for change. Not everybody cool capital spend it's fine. If you don't.

A

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.

A

Maximum 3. All you need is a pocketknife applied at the right spot.

A

So here's where we brought in inter sourcing the old pre get lab source control had been scoped by team and locked down by team. You couldn't see what team B was working on if you're on Team a unless you went through a process to get permissions to get added to see what they were working on. All very you know, segregated you couldn't see the code of a guy that sat next to you at all. Unless you like, went through jump through hoops.

A

Everyone agreed that things like collaboration and transparency and cross team culture of excellence, was important but, like 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 something, but if your tooling doesn't support that or doesn't assume that it's just not gonna work.

A

So we had a thought what, if, 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 repos, they can fork, they can submit a merge request. They can open issues where they can't do anything else. So we said hey, let's actually literally with that one small little change just make sure that airbag is dropped into t-mobile's instance.

A

Has that read-only role, very tiny change technically, like a one-line change, was required to make that 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 closed, and that could be like a huge cultural shift. If we could get it to stick all right max before apply minor force and pop that sucker open, but don't hurt anybody with a knife, be careful while you're doing it.

A

We knew that a lot of devs would understand. We were doing, and why was important, but we also knew that they were groups that would have to convince and talk to most, notably our legal and digit 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 it be a via NDA's or marketing stuff mode.

A

There's always gonna be some projects that don't want that default inter source often opens 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 that very, it's very important. That was very specific, so people just say well, I'm gonna opt out, and then you know you know, don't worry about it, and then we realized, as we dug deeper into this. There was no existing standard around. Why this around around?

A

What would allow you to ought to what would require your products to be closed like before, Athena came along t-mobile. There's, like some projects were under, you know, restrict the project mode, some weren't and the process for actually you know 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.

A

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 your talk came out right you're, not asking for permission, you're saying we were going to do as a development route. We have chosen to do this.

A

We understand, there's 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 you know it would scare somebody out the woodwork to be like well. Actually you can't do this because of XYZ yeah.

A

We could have a conversation there, so we did that and we went to them with that that conversation and we had some leadership backing and, as I said before, we had allies and that largely worked so that that largely helped us actually shift the script a little bit and pitch it. That way,.

A

Maxon five turn it into a party: it's way more fun, here's something! Here's the things that we found that tend to work when you're trying to build popular support in a large organized, a popular support, I mean management and devs, and everybody else make your decisions out in the open, all of them using an inner source. Repos 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 slacker meetings.

A

This is a real, hard thing for t-mobile to get our head around in most large companies, but it's something you have to actively consciously for say: let's move this to a merge requester, 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 to own a contribution, and my experience that is always true, recruit people that seem to be opponents whenever possible.

A

Okay, someone that asks question, or it says, I, don't understand this or you can't do this because of X like talk to them, work with them and ask them to contribute to the FAQ or ask them to like help. You work through that and then build some guidance out in the Oakland using merge requests that actually works like if somebody says this needs to be done. Ask them to do it.

A

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 are want these changes and want to improve the culture and are interested in pushing things forward and in cultivate that cold vated across remote offices, if you're a company, that's is not fully distributing.

A

You still have offices in different parts of the country like as you're trying to build this community of engineers reach out forms in the road offices, because a lot of those guys tend to be guys. Girls tend to be 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.

A

Alright, so reiterate: here's we did. We reframe the workflow by changing a single default. We leverage that to reframe the organizational ask into a request for clarification. Instead of a request for permission.

A

We did it collaborative 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 on 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 icees don't assert their leadership, managers are unlikely to give it to them. If managers try but senior ICS do not inhabit their power.

A

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 we're, whether it's a big company or whatever you have to have that or it's not going where you cannot stop and say. Well, man who's going to cause this thing to happen. No, your senior ICS with political capital need to be able to push it.

A