How often do you survey your developers for their opinion on their experience building products for your business? Do your developers actively recommend your company to other developers? Part of T-Mobile’s journey in becoming a software unicorn is to build a diversified developer community and learning culture which retains developers as well as attracts them. Join Chris Hill, Director and Jennifer Stockton, Recruiting Manager as they walk you through how T-Mobile helped to create a sustainable developer workforce to position T-Mobile's future growth.
Senior Manager, Developer Platforms, T-Mobile
Recruiting Manager, T-Mobile Product & Technology, T-Mobile
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 dev ops conference, I got really excited, but as we've been preparing this presentation for you, all I said to him, you know, you're bringing or recruiter to a development conference and that recruiters are some of their least favorite people. So, Chris, are you sure about this?
I am sure about this, Jen. Uh, this is what been my second or third year within T-Mobile and I really think that recruitment plays an important role on 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, uh, 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,
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, the 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 transformed 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 index 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 that is when a project and 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 then to invest in our own company's technical feature 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 bootcamp. 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 into to 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 and 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 what also speaks to what T-Mobile had to offer somebody's career. This discovery mission meant we needed to know what development looks like at T-Mobile and what it meant to be proud of what they were working on, but where are we proud? We discovered it actually 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, um, 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 T-Mobile dev ops state, 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 can add all of those things to the development component and adding T-Mobile's winning culture to that as well, seriously, this, 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 and hallways. Well, at least when we were in hallways, um, 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. So 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. And, uh, after we bought this house one year into, uh, our home ownership journey, we had about four feet of water in our basement and we had to gut the whole thing. Um, it was one of the first major projects we did here. And so 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. Um, I won't tell you, you could do that. Who did that? Um, but what, what really, I want to point out here is this pool. Um, you'll notice that it's bricked in. And it was just, uh, prior to this was just a black metal pole and we had a bunch of bricks laying around in the backyard and we liked to repurpose things.
So we decided to brick in the pool and at the bottom of the pool, you'll notice that the grout lines are clean and, um, neat and organized at the top of the pole. It is a little bit more messy, a little bit more chaotic, few more mistakes, but it really worked. And 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. Um, but this poll 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, 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. And so one of the key re key tools that our recruiter uses this week done, right? And so 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 came before us.
And in some cases were us this type of message. Doesn't really speak to people and 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, what they would consider exciting. Once we, 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 until I needed them to be interested enough, to go through the interview process and to meet our development team.
So 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 our co to the culture of our teams. You see, we've heard 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 rich recruitment team have built a strong foundation and a partnership that has proven that we can bring people into the door. We also have this great technical bootcamp 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.
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, a 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 the 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, uh, more gaming hours, more team builders, but ultimately experiences more than just those things. There's, uh, fulfillment, there's overall happiness to ensuring your sense of purpose. You know, happiness and fulfillment kind of reminds me of an argument that I have between, uh, me and my wife. And we argue over specific chores to do around the house. Specifically, these chores are things like pressure washing the driveway, painting, uh, 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 wasn't till 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 need, 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. Okay, Chris. So what makes up the developer experience? 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 cashiers and a cashier interacts with a point of sales system every day of work and has to check customers out.
It 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? Then there's two classifications of systems. One is let's take this 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, life cycle management tools, source control, repositories artifact, storage, IDs, CICB systems, Docker, registries, Maven registry, NPM registry. If you look up how many companies are manufacturing software for these particular areas, the permutations are endless ZB labs used to publish a periodic table of dev ops 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 store after developer commits or before deployment or after a deployment, ultimately that periodic periodic table in the last two or three years has exploded to 10 X. 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 a 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 tools, 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. And 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 set, sabotage and eat the lunches of their neighbors, but let's just focus on just 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 I'm personally do for my brain is personally do 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. Nowhere do I see it tracked on an ongoing basis? I'm not, uh, or I specifically didn't include the other cognitive load vampires that are there that are a burden as well to a day-to-day workflow. I'm talking about time sheets 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 really, and, and realize that somebody did some, 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 Schafer at velocity, New York city. Uh, this is like back thing. I think back in 2013, um, it's become one of my favorite talks, but he mentions in riffs, uh, 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.
They 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, right? So last year, everybody hit COVID and our teams were more dependent upon coming into offices on a regular basis.
And so we all the sudden got thrust into this virtual engagement and our teams kind of had to work to learn, to work together. And 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 so, so very much depended on. Um, and so as we brought in multiple hires for the same team, they were able to create some synergy. And so we also learned that as we were hiring, bringing in teams together, allowed them to acclimate to this new workplace, to find some, um, support from each other, as they all learned and grew through this new system. And ultimately it started to be a system that was really built on trust between the managers, between the teams and between our development staff.
We started to treat cognitive load like, uh, like a budget and anytime where you're adding something to a responsibility, um, 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. Can 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.
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, 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. And what I mean by that is as we work, uh, 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 the same journey. And I'd love to hear from you.
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 in, into the, this volatile memory space, uh, I think things are dropping off the end that we may not really fully understand.
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
Thank you so much. Have a good rest of your conference.
Unlimited users from organization
Gene Kim's How Organizations Started Playlist
Patterns for Enterprise Success: The DevOps Journey at Nationwide
Carmen DeArdo, Nationwide Insurance; Hayden Lindsey, IBM
How DevOps Can Fix Federal Government IT
Mark Schwartz, US Citizenship and Immigration Services (USCIS)
Breaking Traditional IT Paradigms to...
Ralph Loura, HP Enterprise Group; Olivier Jacques, HP Enterprise Group; Rafael Garcia, HP Enterprise Group