Jennifer Stockton

I'm Jennifer Stockton from T-Mobile, and Chris and I are here today to speak to you about retaining software talent with empowering systems.

I've been with T-Mobile for about four years now, and I have a lot of passion around recruiting and helping people connect to work that they consider meaningful. I helped to recruit Chris a few years back to T-Mobile, and it's been really cool to build this partnership with him.

I have to tell you that when Chris asked me to speak at my first DevOps conference, I got really excited. But as we've been preparing for this presentation for you all, I said to him, "You know you're bringing a recruiter to a development conference, and that recruiters are some of their least favorite people. So Chris, are you sure about this?"

Chris Hill

I am sure about this, Jen. This has been my second or third year within T-Mobile, and I really think that recruitment plays an important role in the things that I've been working on. Those are things like platform engineering, developer experience, and ultimately, we're going to retain talent better if we have recruitment on our side.

This content is really exciting to me. It's an area that I'm really passionate about, and I really think it fits in with this conference, and maybe we should see more recruiters. So take it away, Jen.

Jennifer Stockton

Last year, Chris came to speak with you about T-Mobile's pursuit of becoming a unicorn. And for those of you that don't know, a unicorn is a company that has mastered delivering software at scale. And to attain that unicorn status, T-Mobile knew it needed to change.

We put a workforce transformation committee together to drive the changes that we really needed. We had to change because our teams felt a lack of empowerment and engagement. We had increased turnover of our development staff. Our team members were being asked to perform work with limited context and little control over priorities. Our organization stepped back to solve how we can move from this tell-and-control command culture we found ourselves in and transform to a better culture with improved productivity and a place where people really wanted to stay.

We landed on a few solutions for this. We knew we needed to bring development in-house. Our team was over-indexed on consultant-level and project-management talent, and our development was being done by a contract workforce. As a matter of fact, about 80% of that work was being done outside of T-Mobile. And one big downside to that is when a project ends, the team walks out the door, and the knowledge walks with them. And then a new project gets spun up, and it becomes this sort of vicious cycle. So what better way to empower our teams than to invest in our own company's technical future and culture by employing these developers ourselves?

So if we were going to make this shift, we knew we had to hire a ton of people. So how do you go about doing that? You just do this, right? You just post a bunch of ads. Kind of, if you build it, they will come. Well, it's not really that simple. To hire all these people, we would need to do a few additional things.

Our recruiting teams had to scale to meet these hiring demands. We needed to ensure we had the right decisioning process for hiring that talent, and so we knew we needed to transform our interviews. And we also had to work on our onboarding practices. And to that end, we implemented a technical boot camp.

T-Mobile invested heavily. Our T-Mobile leadership, our HR team, key development staff, got into a room and started to create a system that would speak to developers and also show the value of coming to T-Mobile to be part of this transformation journey. But how do you know you're creating a process that does that?

We knew we had to put our best developers into a room so that they could build a product for recruitment. No one speaks to a developer like another developer does. So the team put a lot of energy and focus in looking at other companies that had done or taken this same type of journey. And they built a product that not only could vet our engineers but would also speak to what T-Mobile had to offer somebody's career.

This discovery mission meant we needed to know what development looked like at T-Mobile and what it meant to be proud of what they were working on. But were we proud? We discovered an overwhelming sense of pride. We had this existing development community already where we did our own development, and the teams had this ability to showcase what they had built.

We had recently embarked on things like a learning day, which gave back time to every team member once a month so that they could kind of choose their own adventure on their learning and their own growth. And then we did things like implement a T-Mobile DevOps Day, which were two-hour segments to transform things like security and deployment. We also had a great inner-source and open-source organization.

So if we could add all of those things to the development component and add in T-Mobile's winning culture to that as well. Seriously, this organization is like working for a sports team without the sports, right? It's not uncommon to see people giving each other high fives in hallways. Well, at least when we were in hallways. Our teams are proud of our organization, and we have great diversity, equity, and inclusion groups that helped connect outside of their teams.

So we could put forward a great development community and culture, but we had to bring people to the table, and that meant we needed to transform recruiting.

I mentioned earlier, I'm passionate about people, but I'm also passionate about home improvement projects. And we've owned our home now for about 13 years. This is actually a picture of my basement. After we bought this house, one year into our homeownership journey, we had about four feet of water in our basement, and we had to gut the whole thing. It was one of the first major projects we did here.

At first glance, when you look at this picture, you might think, well, the pole is in the middle of the bar, and that is clearly a very annoying design flaw. I won't tell you who did that. But what I really want to point out here is this pole. You'll notice that it's bricked in, and prior to this was just a black metal pole. We had a bunch of bricks laying around in the backyard, and we like to repurpose things, so we decided to brick in the pole.

At the bottom of the pole, you'll notice that the grout lines are clean and neat and organized. At the top of the pole, it is a little bit more messy, a little bit more chaotic, a few more mistakes, but it really worked. It's the one thing that my husband and I laugh about now because this pole also speaks to our partnership. He's a little bit more organized. I'm a little more chaotic. I embrace that.

But this pole also, when I think about recruiting, represents the partnership that we have around development and recruiting. You see, recruiting people takes a little bit of work and is a bit messy. And so when the team came to me and told me that we had to transform our approach to recruiting, my face looked a little like this.

The developers have built a great product for us. They had really worked hard to make sure that we could talk about the value that T-Mobile had to offer and all of the great work that they had to do with regard to the development. So we now just had to run with it. We had to make sure that we could get people in the door.

One of the key tools that a recruiter uses is LinkedIn, right? I know many of you guys have received this type of LinkedIn message. I know that you've deleted it and ignored it, and just flat out probably had no interest in most of the messages that you receive. So if LinkedIn was one of our key tools, how are we going to figure this out?

We needed to be confident that if we reached out to this development community, that we didn't make all the mistakes of the recruiters that had come before us, and in some cases were us. This type of message doesn't really speak to people, not unless you're actively looking and willing to look right past it.

So we went back to that same development community that built this great interview product for us, and we started to learn from them. We chatted with them not only about what it meant to work for T-Mobile and do development, but we also chatted with them about what a good developer looks like and how to speak to a good developer about what they would consider exciting.

Once we started to do that outreach, I knew that our team would be really good at speaking to the value of what T-Mobile could offer somebody's career. I just knew that we had to find that direction for our organization. And so I needed them to be interested enough to go through the interview process and to meet our development team.

We launched this process back in March of 2020. In a year's time, we've done over 750 interviews, and we've hired over 267 developers, and that's about 67% more than we did in 2019 and about 85% more than we did in 2018. But maybe more importantly than the numbers is what we've brought to the culture of our teams. We've hired all of these great developers who have come from different development organizations, and they've been able to contribute to our diversity by bringing in different practices and different ways of looking at things. And so with this new team and our existing team, they've begun to really learn from each other and connect.

I know that our development team and my recruitment team have built a strong foundation and a partnership that has proven that we can bring people in the door. We also have this great technical boot camp that allows them to learn for the first five weeks of their journey here. But this is really where Chris and his team comes in and can tell you a little bit more about the development experience.

Chris Hill

So let's shift our focus to once they come in the door. This is a happy recruit. We know that happiness is a direct correlation with performance. And what we also know is that to be a developer at T-Mobile was really not a good experience. If you've got someone that's at their all-time happiness when they first start with a company, how do we continue that experience and give them what they need?

Well, you might just say, let's just improve the experience: larger bean bags, more pinball machines, more gaming hours, more team builders. But ultimately, experience is more than just those things. There's fulfillment, there's overall happiness, to ensuring your sense of purpose.

Happiness and fulfillment kind of reminds me of an argument that I have between me and my wife. We argue over specific chores to do around the house. Specifically, these chores are things like pressure washing the driveway, painting, carpet shampooing, vacuuming, and I could never really figure out why it was contentious for us to always argue to do those tools ourselves. That was until I finally discovered it's because fulfillment was missing from our day jobs. And the fact that these small tasks, sometimes large tasks, can give you immediate and satisfying results was able to at least give us the fulfillment we needed because we were depleted of that throughout our entire day. Well, okay, we might think a little bit differently now. We need to increase the experience, but we also need to increase the capability to obtain fulfillment. If we don't do that, then we're really the reason why hundreds of driveways throughout the U.S. are pristinely clean.

Jennifer Stockton

Okay, Chris, so what makes up the developer experience?

Chris Hill

What I'm specifically referring to are something that's very common throughout most technology positions today. And these are the systems that are our companions for delivering value to our company.

Let me give you an example. Take a cashier. A cashier interacts with a point-of-sale system every day of work and has to check customers out, has to take payments, has to scan, and their reliance upon that system is a long interaction or multiple long interactions throughout the day. A developer relies on their tool chain or their path-to-production systems to deliver value to their customers.

Now, what systems am I actually talking about? There's two classifications of systems. One is, let's take the brief-interaction systems like email servers, VPN, Active Directory, et cetera. But let's think about instead the long-interaction systems. I'm referring to the tools that you interact with on an ongoing basis to schlep your work into production: lifecycle management tools, source-control repositories, artifact storage, IDEs, CI/CD systems, Docker registries, Maven registry, NPM registries.

If you look up how many companies are manufacturing software for these particular areas, the permutations are endless. XebiaLabs used to publish a periodic table of DevOps tools, and I use this quite frequently to understand where a tool fits in my overall landscape. Do I put that before a developer commits or after a developer commits, or before a deployment or after a deployment? Ultimately, that periodic table in the last two or three years has exploded to 10X. There are so many companies that are creating products that are companion systems to our developer workflow on an ongoing basis.

So you may ask yourself, do I just need to change the systems? Should we just swap out the bad systems and get the good-experience systems? And I've heard this phrase: "Well, we want only the best for our developers. They get what they deserve. Better lunches, better tools. Let's get them the best-of-breed tool in each of these categories." Well, if you're selecting a best-of-breed tool in each of these categories, you're really selecting a different company or a different author of each of these tools.

Let's say we do this. It reminds me specifically of Conway's Law. Now, what did Conway's Law tell us? That said software architecture and the way that you've architected it is going to equate to your organization and communication structures over time. This is really a truism now. But what also is true is your architecture of your process and your selection of your companion systems and tools also could dangerously end up as your communication structures as well. And I guess the point that I'm trying to make here is that best-of-breed tools doesn't actually equate to best-of-breed flow.

Now, what I mean by flow is the overall throughput that it takes for you to make an interaction with these tools to bring them into production or to bring your code into production. Should you pick a different company for every companion system that a developer uses, you've obligated them to memorize the how and the why of the narratives of each of those tools and systems. I'm going to repeat that one more time. Should you pick a different company for every companion system a developer uses, you've obligated them to memorize the how and the why of the narrative of each of those tools.

Now, this is really expensive, and it's not just expensive monetarily. Let's just set aside the fact that the authors of these systems, the companies, these firms, they're actively trying to sabotage and eat the lunches of their neighbors. But let's just focus on the user impact. I'm talking about cognitive load.

I don't think most enterprises are actively trying to decrease cognitive load placed on their employees. I think it's the opposite. I think companies are actively increasing that, but not always aware that they're doing it. How many companion systems do you have to interact with to do your job on a regular basis?

In my humble opinion, it's a zero-sum game. If I come in and I say, "I want each developer to now interact with seven systems instead of six systems," I can't just have the expectation that the cognitive load capacity just increases naturally. What I think happens is something falls off the end. That could be tool number one, or that could be my creativity cycles, or less creativity cycles, or less innovation cycles, or just simply this is how I stay focused, and now I no longer can stay focused.

I think there's a budget to how much memory your brain can keep volatile. I don't know about anyone else, but my brain is personally due for a RAM upgrade here pretty soon, and I'm really looking forward to the swap out.

I don't see cognitive load going down enough, nor do I see it tracked on an ongoing basis. I'm not, or I specifically didn't include, the other cognitive-load vampires that are a burden as well to a day-to-day workflow. I'm talking about timesheet systems, HR systems, portfolio systems, spreadsheet systems, macro systems put into spreadsheet systems. I can't tell you how many times I've gone into a spreadsheet and realized that somebody did some really phenomenal macro-level work here. But for me to understand the context of why this macro was developed and how it works is a huge context switch.

So to answer my previous question, yes, change the system. You have to change the system. If you plan on retaining employees without changing the system, you can probably venture to guess that the outcome is going to be very close to what it always has been before. You may, however, have to change your system of systems and the way that you look at your overall flow rather than individual systems.

There was a talk by Andrew Shafer at Velocity New York City. This was, I think, back in 2013. It's become one of my favorite talks. But he mentions and riffs off of Jacobs and says, "You're either building a software business, or you're losing to somebody who is." I think in the same context, you're building a software experience for talented software individuals, or you're losing to somebody who is. If you're not able to reconcile the fact that your experience is poor, the talent will show you that.

I think we learned a couple of lessons here too as well.

Jennifer Stockton

We absolutely did. We learned that we needed to be prepared to employ these developers. There was nothing worse than us bringing these individuals in through this interview process if the team wasn't positioned to transition to take on their own development. And as we brought people in the door, there were a few mistakes or bumbles along the way where we had teams that just weren't ready to take back that work, and we had developers then sitting in a role where they weren't actually developing things. So we sort of sold them on this great opportunity and then weren't prepared to execute. So that's a really important lesson that we took away.

I think the other thing that we needed to take a look at was this position for virtual and async engagement. Last year, everybody hit COVID, and our teams were more dependent upon coming into offices on a regular basis. And so we all of a sudden got thrust into this virtual engagement, and our teams kind of had to learn to work together. As we brought developers into the organization, they weren't going to be able to meet their managers or their team members, or see our office space, or look at all of the things that T-Mobile had so very much depended on.

And so as we brought in multiple hires for the same team, they were able to create some synergy. We also learned that as we were hiring, bringing in teams together allowed them to acclimate to this new workplace, to find some support from each other as they all learned and grew through this new system. Ultimately, it started to be a system that was really built on trust between the managers, between the teams, and between our development staff.

Chris Hill

We started to treat cognitive load like a budget, and any time where you're adding something to a responsibility, the answer was: what are we going to remove from responsibility in order to make room for this? It's almost like a priority-based discussion. Somebody tells you something is extremely urgent, and you tell them, "What other urgent item do I not do to do this urgent item?"

We also learned to focus on system of systems. If we're more focused on throughput rather than best of breed, then at the end of the day, a consistent and native experience is what's going to decrease cognitive load over time. We also learned there isn't a talent shortage. There are bad experiences that could lead you to think that there's a talent shortage, where ultimately you're driving talent away rather than retaining it.

Jennifer Stockton

We still need a little help, though, right? We still are approaching the senior-level talent, and my recruitment team is continuing to learn. But as we look at other organizations that have also done this, we'd love to know about your success stories and where you've been able to really position this sort of change environment that developers want to enter into.

And then I think it is also important that we improve this disparity between technology and recruitment. What I mean by that is, as we work in recruiting with our technology teams, we need to continue to learn from each other so that we can be able to present this best view of T-Mobile and the development experience that we have. So I know that there are organizations out there that have also walked this same journey, and I'd love to hear from you.

Chris Hill

I'd love to also hear how your company improved your feedback loop with your developer relations. It's one thing to build something in an enterprise and force people to use something. It's another thing to really understand what are the day-to-day impacts of an experience of one of your internal employees or internal developers. I'd love to understand how that feedback loop works in your company.

I'd also like to understand how you're measuring cognitive load in terms of, do you quantify with mouse clicks, number of systems you use to accomplish your day job, how often you stay in the flow versus not in the flow? How long does it take you to ramp up to the flow? I think it's something in the industry that we need to focus more on, because as we're trying to cram more items into this volatile memory space, I think things are dropping off the end that we may not really fully understand.

Jennifer Stockton

I hope you enjoy the rest of your conference. I've been really excited to be here. Thank you for taking the time to listen to Chris and I.

Chris Hill

Thank you so much. Have a good rest of your conference.