Sometimes it is possible to teach a telecom giant a few new tricks.
Last June, Jeremy Legg shifted roles within the AT&T family to become CTO of AT&T Communications after 14 years with WarnerMedia, which included serving as its CTO. The move to AT&T Communications put him on path to lead the modernization of the telecom company’s IT infrastructure. This included reorganizing data architecture, software, and security at the company. He also led the consolidation of data resources and migration of apps to the cloud at an enterprise that measures its data in petabytes.
It is no secret that parent company AT&T is now in the midst of spinning off WarnerMedia. Legg spoke with InformationWeek about his current duties with AT&T Communications, lessons learned over the past year, and what his team hopes to accomplish next.
Were there guiding principles or marching orders you had coming into your role? How has your strategy evolved?
When I came over, they asked me to essentially manage five or six different functions: The chief data office, the chief security office, the chief information office, and then essentially the public cloud and all the middleware in the company. The API gateway layer -- the cream in the Oreo sandwich essentially. Those functions roll into me. Then our units, consumer and enterprise business, own certain applications that sit on top of the technology stacks that my team manages.
What they asked me to do was look at all this stuff that AT&T either built itself or inherited through all the different acquisitions the company has done over the years that was never fused together, and come up with a plan to move to the cloud, which is certainly a big piece of it. More importantly, what are the modern target technical architectures that we need across these different disciplines -- whether we’re in prem or in the cloud?
AT&T is just big. That’s both a blessing and a curse as it relates to technology. What I ended up doing when I came in was taking the technology organization that had different fits and starts in terms of funding and technical strategies over the years and created a north star about where we’re trying to go and broke it into chunks that people could understand. How do we get to the cloud? How do we retire legacy infrastructure? Things like that. Things that are obvious but require an operational path to get from point A to point B.
There were other things around workforce and culture, and a lot of EQ [emotional intelligence] versus IQ things that are how you motivate people. When you walk in to tell a group of people, “You’ve been working hard but all this stuff you’re working on is old and we want to get rid of it all,” it’s not exactly an inspiring message. You really have to figure out how to get them aligned on the new path that you want them to go on. That’s a combination of very nontechnical things.
Were there any challenges in matching your plans with the scale and scope of what you were working with?
AT&T has history of building everything itself. That’s a great history. We’re also in a day and age now where we can’t build everything ourselves. Even as big as we are, it doesn’t make sense. There’s lots of applications, whether you’re talking about ticketing systems, backend databases, or certain kinds of enterprise applications where there are commercial applications that are as good or better and will be upgraded over time because those companies will devote more resources to them than we will.
There’s definitely one transition that’s getting certain groups of people that were used to building everything, used to implementing and running software from third parties. Then you have a cultural issue of refocusing teams on what moves the needle. Not favorite applications or favorite projects. What moves the needle? What I mean by that is putting a business context over the technology.
There are four or five metrics at AT&T that matter: How many wireless subscribers did we get? How many fiber subscribers did we get? How many HBO Max subscribers did we get? Did topline revenue grow? Did EBITDA grow? Every other metric in the company is subservient to those metrics. The goal is to take people that are working on technology, whether it is something we’ve decided we must be great at and we have to build ourselves or it’s something we’re renting from a third-party, and relate it back to those metrics.
The goal of a ticketing consolidation as an example, we have technical milestones and target architectures, but at the end of the day, the project is a failure if we didn’t enable our customers to call us less or be on the phone less time and resolve their issues. That’s the metric technology people have to associate themselves with because that’s the metric that drives acquisition of subscribers and retention of subscribers. We have to instill that business context into the projects. One of the things I do is, I tie our teams to traditional technical milestones, but I also tie them to the business metrics.
Were there thematic or strategic differences you had to adopt moving from your WarnerMedia role to AT&T Communications?
Several things were different; scale was certainly one of them. The canvas of software that exists in this place is vast. We have basically one of just about everything that’s ever been invented somewhere sprinkled around the company. As you think about target architectures and chasing the latest piece of software that’s in the industry or software projects that we’re going to build custom, you can’t forget how many different systems are tied in to each other before you want to go to this new target architecture and what the impacts are to the business as you’re trying to do it.
We get millions of tickets a year. It’s easy to launch a ticketing system consolidation, in the sense of picking something and launching a project. As you actually try to make sure you don’t degrade the consumer experience as you’re implementing this stuff, that’s a real trick.
On the scale side, lots of companies are migrating to the cloud. There’s nothing particularly unique about that. We have individual operational data stores that are well north of 100 petabytes. As you look at the amount of traffic that goes across our entire network in a day, you’re talking more than 462 petabytes on an average business day. When you say, “Hey pick up this database and move it to the cloud,” it’s not so easy. It’s not like you can stick this stuff on a thumb drive. The way you have to think about that is very different.
The other pieces that are so different on the AT&T side is, it is literally part of the infrastructure of how the country works. How consumers access the internet -- the physical internet travels through AT&T, let alone the central offices and last miles associated with how consumers access that every day. As you think about the interrelationship between software and hardware, software-defined networks, applications, and all these things, the implementation isn’t just for AT&T.
In many cases, it’s for how consumers and businesses access the internet itself. That’s a very different thing than at WarnerMedia, for example, where I was a customer of that internet. You have to humbly approach what you’re working on and not think you know it all. No one knows. It’s just too big. You have to rely on people with institutional knowledge and people you brought in from the outside who have a totally different way of looking at the world.
Are there popular technology resources or stratagems that you looked at but were not the right fit to be implemented at AT&T Communications?
Companies of our size -- you can’t do everything agile. You can’t run massive data centers in an agile environment as it’s prescribed through traditional software. There are some kinds of projects that really have to be waterfall-based. With that said, as you have to think about application development in the cloud, or consumer, or business products, you better be agile or you’re not going to be able to compete and have release cycles for software that impress your customers.
The one moniker on DevOps that I’m a little skeptical of is, if I could find in a more than 230,000-person company all the unicorns that knew DevOps and were full-stack developers who wanted to write code and maintain that code and implement all the fixes, I’d love to have all those people. But there aren’t as many people out there who have those qualifications as you might think.
You have to think about where you can implement and sustain models like DevOps and where you can’t. The knowledge a DevOps person would need to have of the kind of infrastructure footprint that AT&T has, I’m not sure you can fit all that in one brain. You have to figure out where you can deploy those kinds of things. I fully embrace the concept, but I also have to layer in the reality of what it’s like to work at AT&T.