Transformational Leadership—An Implementation Story

My name is Dr. Steve Mayner. I'm a fellow at Scaled Agile, the company that brings you the Scaled Agile Framework, or SAFe. I'm delighted to be here with you this morning and also to have a co-presenter that I'm super excited to introduce to you in just a moment. So for the last four years, this is my fourth year coming to this conference and presenting on the topic of transformational leadership. How many of you have seen this model or been to one of the past sessions that we've done on the topic? Fantastic.

So good news, you're not going to have to sit through the same information again, right? That is always exciting. I'll just give you a brief background. The model was pioneered by James Burns. He built this theory around leadership called transformational leadership. Turned out to be the most researched, most studied theory on leadership by far. In fact, more than any other leadership model combined. And when I was going through my research on understanding organizational change, specifically around DevOps, agile adoption, I came across this connection between leadership and the success of change, and began researching, writing about it, speaking on it at conferences. So feel free to take pictures, go check on some of the past sessions that I've done on the topic. What's really interesting is the research shows that when leaders lead with specific kinds of behaviors, those that are following, they're also in the organization, are more likely to lean into organizational change and help that change be successful. Now, one of the interesting things is, in 2017, working with Gene and Nicole, they added some research into the State of DevOps survey and found that not only was there a correlation between these leaders' behaviors and successful change, but you could actually find that these behaviors were predictors.

Predictors of not only successful change, but of developing high performing teams. So following that 2017 session, a few months later, I get a phone call because one of the things that Gene always asks us is say, "What help are you looking for? What are you trying to learn next?" And in the sessions that I did, I'd always say, "Hey, we would love to work with real organizations to test this out, to go through a process to help leaders adapt these behaviors and see, hey, does this really work?"

And so I got a phone call, and this came from a gentleman that I'll introduce you here to in just a second, who said, "Hey, I watched the video of the session. Sounds like exactly what we're looking for in our organization. Would you like to come out and help us through this process?" And we did, and had a great time. Great group of people. And today what we're going to do is talk about the story behind why they felt that was something of interest, what they did, and what the results have been.

So without any further ado, I would like... Oh, can we go back one? I think I jumped the gun there. Nope, there it is. All right. Sorry. Boy, try that one more time. Let's back up to Joe's slide, please. Thank you. I would like to introduce Joe Hunt. He's the group vice president of software engineering and architecture at Charter Communications. Welcome, Joe.

Thanks, Steve. All right. My name's Joe. I'm from Denver. Been married for 24 years, have four kids. Basically a normal kind of a person. Not that different from you guys. Stand up, everyone. Please stand up. Everyone take a slight step to your right, which I think is that way, and take a slight step back to your left. Now, you can spend the rest of the conference, sit down, telling people how you were moved by the transformational- ... leadership presentation.

So I work for what you would probably call a cable company. Charter Communications is the fastest growing TV, internet, and voice company in the US. We're the second largest cable operator in the US. We have 28 million customers. One of the things that you may not know about the cable industry is Charter is actually made up of over 4,000 other companies that have merged and consolidated over a long period of time. And so as a result, we deal with lots of legacy systems, hardware, software, as well as the latest cloud technologies. And so just a massive amalgamation of everything that you could imagine.

And with millions of customers and hundreds of millions of devices on our networks, there's plenty of work to do on a daily basis. And so I run a team that is called SLATE, which is about 300 people, and we're responsible for the video software that backs, or the software that backs all the video experiences. And so this is the set top boxes when you go and open up the guide or you do video on demand, as well as all the IP experiences if you're on iOS, Android, Xbox, Roku, smart TVs.

And our customers have an expectation, which I think is pretty reasonable, that when they turn on their TV, it works, and they can actually watch their programs. They can find what they're interested in. And so we try and support that. About three and a half years ago, Charter, Time Warner Cable, and Bright House Networks merged. You may have heard something about this in the news. And at the time, I was a contractor.

I had been working at Charter for a couple of years doing some architecture work, and just after the merger, I joined as an employee. I was head of the architecture for all of our customer facing products. And I was having a great time making architectures, dreaming dreams, all these great things that could occur, but noticed that very little was actually happening. During that time, we had acquired the complexity of three cable companies, and we had three different engineering cultures.

And so we had a lot more things than we actually wanted to have to be optimal. And unfortunately, the dev teams had not been coming together. And so after about a year being in architecture, we had a pretty significant change where about a third of the people in the video software group left the company over just a couple of months. And that's when I took over video software development. And so as you can imagine, it's a daunting task. We did everything that we could to capture the knowledge that we could.

But when someone who's been building and working on a system for 10, 15 years leaves the company, they didn't tell you everything that you needed to know. You know that. So this is where we were. And about the same time, maybe a little bit before, it became clear that our customers had very different needs and that those were changing. You've probably heard of cord cutting, right? People were changing their behaviors.

Even our customers that were staying were choosing to use IP platforms, were choosing to view their content in very different ways. And so that was the problem that we faced. We needed greater agility than we had. And so as a technologist, as an architect, I wanted to just solve the technical problem. But the more I thought about it, I realized that the technical problem was there and is real, but what the resources I really needed to invest in were the people.

This was a very challenging time. I had read lots of books about DevOps and Lean and whatever, but I'd never really done it. And so I had an intellectual understanding of things, but I didn't really know what to do. And so this was over the holiday break, trying to find some information, and I came across the YouTube video of Steve Mayner talking about transformational leadership. And I immediately knew that is what my people need.

They need the skills that will help them get through this mess. This thing that we needed to sort out. And so what we did is Steve came, and we piloted it first with my staff and then with 40 other leaders in my organization. And we did every Friday for six weeks, transformational leadership. And that was interesting. Not only did we build a great foundation of information, knowledge, shared vocabulary that we could talk about the problems, we learned a bunch of skills that we didn't previously have, five whys, lean coffee, these kinds of things.

But it was a signal to my team, you can't just keep being the same. And they received it. With it being one day a week, it spread it out just a little bit. It was enough that they could process it and come back the next week and be ready to go. And so one of the first things that we needed to do was pull together as a team with a shared identity. And so we did a kind of a contest where we'd kind of crowdsource through the team, what are we going to call ourselves?

And we ended up with Software Leadership and Technical Excellence, or SLATE. We had spent a lot of time talking about what should our vision be, our mission. We actually drafted many of these, and they kind of came and went, and nobody really stuck to them. But one thing that we had got early on was this tagline. It was kind of geeky, pseudocode, "While not perfect, improve." And that's what's really stuck with us, the idea of constantly improving ourselves.

We also put together this list of priorities, and if you look at this list, you will probably say, "Well, those seem kind of stupid and silly." It's interesting because we were so buried in urgent work that we were very rarely addressing the actually important work that would move the needle. And it wasn't until we wrote these down and started talking with everyone about these are our priorities, that we could actually prioritize the work.

This gave my teams the ability to say, "No, my management said it's more important to do the customer-impacting issue than the feature," for example. So up in the right-hand corner, you can't quite see it, but you'll see it says vision. These are, in each slide, callbacks to that chart that Steve showed you at the beginning, and you'll see them in all the slides. So we created a set of values. We thought it was important that we kind of explain to people what's behind how we want to behave.

And so integrity, mastery, which for us is a learning culture and a lifelong learning, helpfulness, and bias for action. In any kind of graphic like this, there needs to be Latin, so this is, "While not perfect, improve" in Latin. But what we found was when you're doing a pull request or you're trying to do an emergency break fix in production, these aren't super easy to apply. And so we needed a way to connect the daily behaviors back to the values that we were trying to promote. And so we created in an offsite with my staff, these guiding principles, and they are essentially the behaviors that we would expect people to have when they are demonstrating those values. This was a helpful tool by being explicit about the kinds of behaviors that we wanted people to have. Now when they're completely overwhelmed and overtaxed and their cognitive load is so high that they just can't think, their default is this.

And so we just promoted this, and this was also a very helpful tool in talking with other parts of the organization, telling them, "This is how we're trying to behave. Hold us accountable for it." And it created a lot of questions and a lot of interest in how they could also change, because we weren't the only organization that was feeling some pain. So when people most need to change, they often have very little ability to actually change because they're just overwhelmed and overloaded.

And so when we started this, we said to everyone, "You should read the 'DevOps Handbook.'" We want everyone to have a similar vocabulary and understanding. And nobody read it. My staff read it because I kept asking them. That even took six months. And so we said, "Okay, that didn't work. So let's give presentations. We'll talk about the three ways of DevOps. We'll talk about all of these things, and we'll talk about DevOps in action. We'll give all these presentations." And yeah, nobody really did DevOps after that.

So undaunted, we actually created... And this actually is what finally moved the needle for us. We made a spreadsheet, and we listed out the different behaviors that we observed in the "DevOps Handbook," and we said to each team, "Can you just put zero if you're not doing it, one if you kind of do it, two if you've completely figured this out." And we just gave it to everybody. And we said, "Everybody fill it out." And then suddenly, in their quarterly KRs, their key results, people started to report, "Hey, we're working on our test environments."

And it seemed that breaking it down like this was enough that people could actually say, "I can work on that one thing, instead of trying to absorb, I'm going to completely transform it." It gave them a better foundation to do an agile approach to this change. And then they started to read the book as well. So this is the wall near my office by our communal bookshelf. And so one day, Brent Corin, one of our senior Scrum Masters, made this.

And so it's the SLATE Book Log, and it's a Kanban style chart where people can take a book they're reading, put it in the reading column, put a sticky with their name, and when they're done, they move it to done. And at the end of the month, we put all of them back at the beginning. And we had lost so much expertise when that group of people had left, that we needed to get really good at learning. And so it was very important for us to build this kind of a learning culture, and this is an example of how we kind of remind ourselves that we're about learning.

And so one of the books we read early on in our transformation was "Accelerate" by Nicole Forsgren, Jez Humble, and Gene Kim. And we borrowed liberally from that book to create a quarterly survey. And that quarterly survey, the intent of which was to determine where are we in a DevOps transformation. And this is five quarters of the data of that transformation. And you'll notice on the left-hand side, these are topics like vision and goals.

We actually had pretty good improvement. But some of the areas, collaboration, communication, employee engagement, we were actually pretty good when we started. But in the technical areas, we kind of sucked. Architecture, particularly bad. And what you can see, though, is over the five quarters of this 50-ish question survey that we send out, constant improvement in those technical areas. And it feels like we're making that progress.

And so this has been a helpful tool to us. One of the other things we put in that survey that we sent out to everybody was open-ended questions. And the feedback you get from open-ended questions is not for the faint of heart. Raw emotion comes out in those things. One of the things we put in there was an optional field where you could put your name. And that created a lot of consternation. People were very concerned about putting their name in their response.

And so we talked a lot about it, and it just highlighted there was a lack of trust. And so now, we actually have now completed the sixth quarter of it. We get 76% of people are actually putting their name with their response, which I think is actually improvement, and I don't know if we'll ever get higher than that because people are still grumpy. We had the Amazon folks come in and talk to us about how they work and what they do, and one of the ideas that really stuck with my team was the idea of weasel words.

Now, weasel words are the words you say when you don't actually have any of the real data. This is where you... It's usually going to be like this. It's often like this. And we were finding that huge amounts of communication were not very effective and required a lot of follow-up because we weren't being very precise. And so as a result, we outlawed weasel words, and we require people to be more specific, and instead of talking about that entitlements issue, talk about the specific ticket in Jira.

And by that, we're hoping to significantly reduce the amount of communication that's wasted. Our communication is also a reflection of our overall view on leadership. And so instead of a typical leader-follower pattern, we've been trying to build a leader-leader model, as David Marquet talks about in "Turn the Ship Around." So the first thing we did is we tried to train and push down the decisions to where the information was.

And one of the problems that we ran into with this is we quickly started to find that there were teams that they didn't feel very safe. And so as a result, they had a problem for a long period of time that I could've fixed immediately, but they never told me. Because they thought, oh, it's their problem now. And so we actually tried to more enforce the I intend to pattern that David Marquet talks about, so that the leaders at the lower level could communicate, these are the things that are going on, without losing the responsibility to make the decision, but letting me know what's actually going on. And also trying to improve that trust and the relationship.

And so this has been helpful for us. Another problem that we faced is when you talk about change, sometimes it just becomes another program, another thing on the list. And it's really easy if you're already overloaded and overworked to make things even worse. And we didn't want that to happen. And so to try and avoid that situation, we would constantly talk about how do we change the way that we work, not just adding new things that we're doing on top of the things that we've been working on.

For example, you start with an automated build process, and that makes a little space for you to do automated tests, which makes a little space for you to do something else. And you try very hard to avoid any big bang kinds of transformations, because that just drives up your WIP and your risk, and everything falls apart. Try and find those really small, incremental pieces that you can do to actually drive change. And leading change is an adaptive challenge.

Like this baby, when you start out as a leader to lead change, you do not have the capability to actually get to where you need to go. You have to change. If you're trying to drive a group of people to change and you are not authentically leading, meaning that you are not having those authentic behaviors, that you yourself are not changing, guess what? Nobody changes. This is one of the more interesting things that I've learned.

As you change as a leader, people will observe that. They will know it. And if you come in and you have all the answers, then they probably won't actually change. You need to be along for the ride. You need to be working with them. Even if there are a lot of things you know from prior experience, if you're not on the frontline working with the people, trying to understand, learning, and changing your behavior, they won't change.

And so only after you have developed that new set of muscles are you actually going to be able to lift the weight in front of you. And so... It's not changing. There we go. Where are we now? So automation is way up. Releases are up. Lead times are down, errors are down, but there's a lot more that we want to do. SLATE is a small part of a very large machine. And even within SLATE, we're not perfect. And we're seeing in our leadership chain a lot of interest, and we communicate.

Every quarter, we write up quarterly business reports, and we share them up with leadership and tell them about all of the successes and failures that we're having. And people seem legitimately interested in changing and doing things in a different way. But we're not done. And one of the areas that we're challenged with right now and that we're trying to figure out is, actually comes from the book "Team Topologies." Our teams are very much aligned today with platforms, and very few people are actually stream-aligned in the parlance of that book. And so in the next year, we're going to try and move about 50% of our workforce to be more stream-aligned, focused on features being served by more robust platforms than we currently have.

And we think that will be the next phase of our transformation. But we're trying to figure that out right now. And so the last two years have been heavily focused on working through consolidation and transformation. And so for the next six months, we expect to celebrate a lot of retiring of old components and things like that. But one thing's for sure, we're not perfect, but luckily, we know what the next thing to do is. And that's to improve.

And so that's what we're going to continue doing, and I want to bring Steve back up. And also thank Steve for helping us out and getting started in this journey.

That's awesome. That was so much better than me talking about transformational leadership again, wasn't it? To actually see it live and breathing and being implemented by an organization as they go through the process of figuring out not only how do we deal with the blocking and tackling of changing our CI/CD pipelines and doing all the things that we've learned about in these conferences, but that element of the leadership and the communication, the improving, that creates the environment that allows a lot of these things to take place.

So really, really important. So I've just got one thing. It's the thing that we always are asked to do by Gene, which is what are we learning and how are we trying to improve? This was a great experiment, and Joe knew going in that it was an experiment. We were learning our way to, is there a way that we can walk into an organization that has some of the same struggles that Joe's organization has and help provide them some tools, some interactions with their teams to help grow this competency within the organization.

And that experiment, I think, was successful in its scope of what it was intended to do and is ongoing. And now we're on a journey to improve that even further, work with even more organizations, and refine this, learn ourselves, and improve ourselves as an organization that is out there trying to help other organizations learn and grow as well. So if you have any interest in also being part of future experiments, we're still experimenting.

We're going to do a lot more next year, then please contact me, come see me afterwards, and we'll be happy to chat with you about that. So we've got a little bit of time left, and with that, if there are any questions, we'd love to be able to answer those for you now. Wow, that was overwhelming. You guys are really thinking about lunch. Either that or we just don't have the cool music they do next door. Yes, sir.

At first, I kind of interpreted SLATE as something like a leadership community of practice, but I saw it as an organization. That's right. So yeah, SLATE is actually the name of my software development team, and so we're about 300 developers responsible for video software. And so it's not a leadership thing only- Got you ... but it's a big software organization, and so the work that we did was primarily with the line leaders of that organization.

Follow up? Yeah. Good job. Is the experience you had there radiating outward where others are saying, "Hey, I want one of those?" Absolutely. And we've been very active in trying to kind of proselytize, and it is starting to take on. There's no question that there are other parts of the organization that are trying to change as well, and so we're trying to facilitate that as best we can and communicating up through the management chain.

In fact, in the six weeks that Joe mentioned, by probably the middle week in that sequence, there were other people starting to show up in the sessions that I didn't recognize as starting the journey with us because the word was already spreading that, hey, there's something really interesting going on over there. And I had a couple of conversations with those folks just describing what we were doing, and their comment was always, "Wow, that sounds exactly like what we need in our organization as well." So...

We have time for two quick questions. Okay. Okay. Any questions? Another one? I see one way in the back. Just a quick one. Great session this morning. Really loved that. At a high level, sometimes we'll talk about changing structure first can lead to the kind of culture and behavior that we're looking for in an organization. I'm just curious to hear about any organizational design implications you've had to approach as part of this journey to date.

Sure. One of the first things that we did is we reorganized. When I took over the team, we did what's called the reverse Conway maneuver, right? Where we actually took all the people in a similar functional area, though they had different pieces of software from the different three companies, and we put them all together into what we called functional pods. It's interesting that what that did is actually drove simplification of our architecture, but it also produced 17 monoliths, which isn't actually optimal, which is why we're looking at how do we continue to improve our architecture.

Because there's no question that it was a huge improvement in that it reduced the sheer number of components that could fail and that could create problems, but didn't actually drive us to an optimal architecture, and so we're looking at how do you structure the organization a little bit differently to further drive it where it needs to go. How about reporting relationships? So we did recently get reorg'd under the product organization, which is interesting.

We're yet to understand exactly what that will mean for us, but it seems to be driving us in the right direction as a broader transformation of the company. We were hoping for that and are happy to see that it's occurred. Cool. Thank you. One more? I think that's it for time, but if you guys can take questions after- Okay ... the session, we're going to break for lunch. Thanks. Thanks for coming, everybody. Appreciate it. Have a great conference.