00:00:02

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 seen this model of, into 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. Uh, the model was, I'll just give you a brief background. The model was pioneered by, uh, James Burns. It built this theory around leadership called transformational leadership turned out to be the most research, most study theory on leadership, uh, by far in fact, more than any other leadership model combined.

00:00:55

When I was going through my research on understanding organizational change specific around dev ops agile adoption, and came across this connection between leadership and the success of change and began researching, writing about it, speaking on it at, 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 are, 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, uh, in 2017, working with Jean 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 so not only successful change, but of developing high performing teams.

00:02:06

So following that 2017 session, a few months later, I get a phone call because one of the things that I, that Jean always asks us to say, what 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, you know, Hey, this 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'll watch the video of the session. Uh, 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. Uh, and today what we're going to do is talk about the story behind why felt that was something of interest, what they did and what the results have been. So without any further ado, I would like, oops, can we go back one? I think I jumped the gun there. Uh, Nope. There it is. All right. Sorry. Uh, boy, try that one more time. Let's back up to Joe slide, please. Thank you. I would like to introduce Joe Hunt. He's a group vice president of software engineering and architecture at charter communications. Welcome Joe. Thanks Steve.

00:03:30

Alright. Um, my name is Joe I'm from Denver. Um, been married for 24 years, have four kids, basically a normal kind of a person, not that different from you guys. Um, 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. Uh, charter communications is the fastest growing TV, internet and voice company in the U S we're the second largest cable operator in the U S um, you know, we have 28 million customers. Uh, 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 consolidate over a long period of time.

00:04:35

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, you know, 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 was about 300 people, and we're responsible for the video software that backs or the software that backs all of 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, X-Box Roku smart TVs. And you know, our customers have an expectation, which, you know, I think is pretty reasonable that when they turn on their TV, it works and they can actually watch their programs.

00:05:32

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 some about this in the news. And at the time I was a contractor, uh, 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. Um, I, 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 notice that very little was actually happening. Um, during that time, you know, 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.

00:06:31

And unfortunately the dev teams had not been coming together. And so after about a year of 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, um, it's a kind of a daunting task. You know, 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, you know that, right?

00:07:15

So this is where we were. And about the same time, you know, maybe a little bit before it became clear that our customers had very different needs and that those were changing. You probably heard a cord cutting, right? Uh, people were changing their behaviors, even our customers that were staying were choosing to use IP platforms. We're choosing to view their content in very different ways. And so that was kind of the problem that we face. We need a 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 it is real, but what the resources I really needed to invest in were the people.

00:08:04

This was a very challenging time. Um, you know, I had read lots of books about dev ops 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 I was, 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, right. 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, it was interesting, not only did we build a great foundation of information, knowledge, shared vocabulary, that we could talk about the problems.

00:09:05

Uh, we learned a bunch of skills that we didn't previously have five whys, lean coffee, these kinds of things. Um, but it was a signal to my team. You can't just keep being the same and they received it. You know, it was with it being one day a week. It spread it out just a little bit. Uh, 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 crowdsourced through the team. What are we going to call ourselves? And we ended up with software leadership in Texas technical excellence or slate. You know, we spent a lot of time talking about what should our vision be?

00:09:54

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, uh, early on was this tagline. It was kind of geeky, uh, pseudo code while not perfect improve. And that's, what's really stuck with us, the idea of constantly improving ourselves. Uh, 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. Um, 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.

00:10:58

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 of what, 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 and any kind of graphic like this, there needs to be Latin. So this is while not perfect improve in Latin. Um, 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 it, it, we needed a way to connect the daily behaviors back to the values that we, we were trying to promote.

00:11:59

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. Right. 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 you know, their cognitive load is so high that they just can't think their default is this right. 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.

00:12:54

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, right? We want everyone to have a similar vocabulary and understanding and nobody read it. Right. Like my staff read it because I kept asking them, um, that even took like six months. Uh, and so we said, okay, that didn't work. So let's give presentations, we'll talk about the three ways of dev ops. We'll talk about all of these things. And we'll, we'll talk about dev ops in action. We'll give all these presentations and yeah, nobody really did dev ops after that. Um, 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 dev ops handbook.

00:13:53

And we said to each team, can you just put zero? If you're not doing it one, if you're 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, you know, 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. Right. It gave them a more, a better foundation to add, you do an agile approach to this change. And then they started to read the book as well. Um, so this is the wall near my office by our communal bookshelf. And so one day, uh, Brent Coran, one of our senior scrum masters made this.

00:14:50

And so it's the 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, uh, 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.

00:15:28

And so one of the books we read early on in our transformation was accelerate by Nicole Forsgren, Jess humble and gene Kim. And, um, 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 dev ops 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, um, architecture, particularly bad. Right? 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 we actually, it feels like we're making that progress.

00:16:31

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, right? I mean, raw emotion comes out in those things. Um, one of the questions, or one of the things we put in there was an optional field where you can put your name. And, uh, that created a lot of consternation. People were very concerned about putting their name in the response. And so we talked a lot about it and it just highlighted, there was a lack of trust. And so, um, now after doing it for, we actually have now completed the sixth quarter of it. Um, we get 76% of people are actually putting their name with their response, which I think is actually improvement. I don't know if we'll ever get hired in that because people are still grumpy.

00:17:24

You know, 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, right? This is where you it's usually going to be like this it's often like this. Right. Um, 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 we've 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.

00:18:22

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 and turn the ship around. Um, 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 have fixed immediately, but they never told me right, because they thought, oh, it's their problem now. Right? And so we actually tried to more enforced the . I intend to pattern the David Marquet talks about so that the leaders at the lower level could communicate.

00:19:12

These are the things that are going on without it losing the responsibility to make the decision, but letting me know what's actually going on and also trying to improve that trust and, uh, uh, the relationship. And so this has been, uh, been, been helpful for us. Um, another problem that we faced is when you talk about change, sometimes it just becomes another program. Another thing on the list, and, you know, 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're, that we've been working on. You know, for example, you know, you, 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.

00:20:17

And you try very hard to avoid any big bang kinds of transformations, because that just drives up your whip 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 changes and adaptive challenge, right? 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, right? If you're trying to drive a group of people to change, and you are not authentically leading, meaning that you are not, uh, 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 and 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 kind of frontline working with the people, trying to understand learning and changing your behavior, they won't change.

00:21:39

And so only after you have kind of 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. We're releases are up, you know, lead times are down, errors are down, but there's a lot more that we want to do. You know, slate is a small part of a very large machine. And even within slate, we're not perfect. And, you know, we're seeing in our leadership chain, a lot of interest and we communicate, we 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. Um, but we're not done.

00:22:36

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. Uh, our teams are very much aligned today with platforms and very few people are actually streamlined 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 streamlined, 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. Um, and, but one thing's for sure we're not perfect, but luckily we know what the next thing to do is right. And that's to improve. And so that's what we're going to continue doing. And I want to bring Steve back up, um, and also thanks Steve for helping us out and getting started in this, this journey

00:23:52

That was so much better than me talking about transformational leadership. Again, wasn't it to actually see it live and, and breathing and, and, and, and being implemented by an organization as they go through the process of figuring out not only how do we deal with it, with the blocking and tackling of, of changing our, our CICD pipelines and doing all the things that we've learned about in these conferences that, that element of, of the, 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, we always are asked to do by Jean, 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.

00:24:39

We were, 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, that Joe's organization has and help provide them some, some, some tools, um, some interactions with their teams to help grow this competency within the organization. And that experiment I think, is, was successful in its scope of what it was intended to do. And it's an ongoing, and now we are, we're on a journey to, uh, improve that even further work with even more organizations and refine this, learn ourselves and improve ourselves as an organization that, that, uh, is out there trying to help other other organizations learn and grow as well. So if you have any interest in, in also being part of future experiments, we're still experimenting. We're going to do a lot more, uh, next year, then please contact me, come see me afterwards. And we'll be, we'll be happy to chat with you about that. So we got a little bit of time left and with that, I, if there are any questions, we'd love to be able to answer those for you now. Wow. That was a 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.

00:26:01

At first I kind of interpreted slavery as something like a leadership practice. I saw it as an organization.

00:26:08

That's right. So, yeah, slate is actually the name of my software development team. And so it's, uh, we're about 300 developers responsible for video software. And so it's a, not a leadership thing only, but it's a big software organization. And so the work that we did was primarily with the line leaders of that organization.

00:26:29

Yeah. It's the experience you had there radiating outward where others are saying, Hey,

00:26:40

Absolutely. Uh, and we've been very active in trying to kind of proselytize and it is starting to take on, um, 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.

00:27:01

In fact, in the, in the six weeks that, that Joe mentioned by probably the middle week, uh, in, in that sequence, uh, there were other people starting to show up in the sessions that we didn't, I didn't recognize as they're 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,

00:27:34

Okay. Okay.

00:27:36

Any questions? Another one,

00:27:40

See when way in the back,

00:27:42

Just a quick one. Great, great session this morning. I really loved that, um, at a high level, uh, 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.

00:28:02

The first things that we did is we, uh, reorganize 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, uh, companies, and we put them all together into what we called functional pods. Um, it's interesting that what that did is actually drove simplification of our architecture, but it also produced a, you know, 17 monoliths, which isn't actually optimal, uh, which is why we're looking at how do we, uh, continue to improve our architecture? Because it, it, there's no question that it was a huge improvement in that it reduced the sheer number of components that could fail on 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?

00:28:52

How about reporting relationships?

00:28:57

So, um, we did recently get a reorg reorg under the product organization, um, which is interesting we're yet to understand exactly what that, uh, will mean for us, but it seems to be driving us in the right direction as a broader transformation of the company. Um, we were hoping for that and, uh, are happy to see that it's

00:29:19

Occurred. Cool. Thank you

00:29:22

One more.

00:29:23

I think that's it for time, but if you guys can take questions, we're going to break for lunch.

00:29:27

Thanks. Thanks for coming everybody. Appreciate it. Have a great conference.