Latest / Inside Strategic Relations / Three Powerful Skills Every Leader Must Master

Transcript

Three Powerful Skills Every Leader Must Master · Inside Strategic Relations

• 0:01
  Do you want to maximize influence over yourself and the people around you? Do
• 0:06
  you want to have a clear path of career acceleration where you constantly get offered
• 0:10
  new opportunities, new growth and the best positions available out there. Well,
• 0:15
  you're in the right place. I'm justin hit with inside Strategic relations. If
• 0:19
  you're tired of being passed over for raises, promotions, and other new opportunities,
• 0:23
  then listen carefully. There are three things that you must do in order
• 0:28
  to position yourself. In fact, these are skills that help you position yourself
• 0:33
  in a leadership position. So rather than being an individual contributor, you get
• 0:38
  to grow teams, lead teams, grow your opportunity. You'll stop getting passed
• 0:43
  over because people recognize these skills as influential to their own success. And when
• 0:49
  you implement them in the right way, you gain control, access power.
• 0:55
  Now, what are these three things. I'm going to cover these three things,
• 0:58
  and then you want to look at these as skills and we're going to
• 1:00
  talk about them individually. I'm just and hit with inside Strategic relations. Let's
• 1:04
  start with number one, your ability to organize people. It is so important
• 1:11
  that you're able to organize individuals around solutions, around specific results, around certain
• 1:19
  outcomes. So I was working for a Fortune one hundred bank and we had
• 1:23
  about forty thousand servers, and the group I was working with was responsible for
• 1:27
  defect management. So there's hundreds of thousands of defects. They're rated critical to
• 1:33
  low, and these defects come from operating system failures, problems in the environment,
• 1:38
  software code, application issues, a wide range of things. There were
• 1:44
  two about forty thousand servers, and there are two groups of servers, so
• 1:48
  there's Unix servers and Windows servers. Now, originally leadership wanted me to get
• 1:53
  together all of these people. There's about twenty five in each group that were
• 1:57
  leads, and each of those individuals had about fifteen to twenty people working for
• 2:00
  them, and leadership wanted everybody on the phone to go over this defect list
• 2:06
  and to start rashing these out. And what I mean by rashing it rationing
• 2:09
  out these defects for resolution. And that would have been hundreds of people on
• 2:15
  a call. So when I talk about the ability to organize people, it's
• 2:20
  not about how many people you can get together, about how many followers you
• 2:23
  have, about how many leads you have. If you're a service business,
• 2:25
  or how many friends you have. It's about being able to look at a
• 2:30
  group of people and logically organize these people to resolve the issue at hand.
• 2:35
  So our goal was to eliminate all critical defects in the environment. Our goal
• 2:40
  was to reduce the amount of time it took to solve these problems because they're
• 2:44
  time critical. So for example, if today a bug came out, the
• 2:47
  organization has to resolve that bug in a certain amount of days, otherwise it's
• 2:52
  vulnerable to hackers. And so we also want to organize people in a logical
• 2:55
  way. If you threw all the Unix leads and all the Windows leads on
• 3:00
  the phone at the same time and they were talking about problems in their environment,
• 3:06
  if you had an equal number of people from both groups, then you
• 3:08
  can guarantee that for every idea or every discussion you have that at least half
• 3:14
  the people on the call have no interest in it. Because the Unix operating
• 3:19
  system and the Windows operating systems are different. The Unix operating system is a
• 3:22
  different set of applications. The Windows environment has different set of applications. A
• 3:27
  lot of the Windows environment tended to be more infrastructure related, and then the
• 3:31
  Unix environment more application related, so it's even the application of the services were
• 3:38
  not relevant to each other. And so in a business environment, if you're
• 3:42
  going to hold a meeting, you don't want half the people on the call
• 3:46
  to feel the meeting is useless. And so if we organize the meeting,
• 3:51
  we would just you know, we would rotate from topic to topic, and
• 3:53
  so maybe people would stay interested in the call, but we'd have hour long,
• 3:58
  three hour long calls and it would just be complete waste of time.
• 4:00
  But if you organize the people and you have one call for the Unix people
• 4:04
  and one call for the Windows people, you now can focus at least from
• 4:10
  a subject matter interest that everybody on the call will receive the majority of their
• 4:15
  time to be perceived as valuable. And so again the ability to organize people.
• 4:20
  Not only did I split the groups into Unix versus Windows, I also
• 4:26
  focused on the subject matter experts and the leads for these groups. Because I
• 4:31
  understood the organization of people, I could better manipulate that organization to get better
• 4:36
  results. So rather than having individual contributors on the call, we had the
• 4:41
  people who divide out the work within the Unix environment on the call, and
• 4:46
  so that when I brought defects that were UNIX specific, they can now assign
• 4:51
  them appropriately to the application. Now, the leadership of the organization wanted us
• 4:57
  to get these calls together and that was going to be the only way we
• 4:59
  interact. But I could easily see that sometimes there was a specific application that
• 5:04
  had problems and the other people on the call had no problems in their environment
• 5:10
  or their applications. So again, why do we want to have people on
• 5:14
  a call who are not directly benefiting from the call. So instead of having
• 5:17
  hundreds of people on the call, instead of even having twenty five people on
• 5:20
  the call, sometimes I would have individual calls with a specific group who I
• 5:26
  can tell by the defect reports are having a little bit of problems. Now
• 5:30
  let's talk about the social engineering because number two of the skill that you need
• 5:33
  is the ability to maximize individual productivity. So I'm maximizing productivity by not wasting
• 5:39
  people's time, but by meeting with people individually. We can talk specifically to
• 5:44
  their problem without concern of embarrassment, without concern of peer pressure. We could
• 5:48
  just bring in the subject matter experts that they need. And we're focusing on
• 5:51
  maybe five or ten people on a call coming up with an issue. So
• 5:56
  we used an issue management methodology where we come up with the issue, define
• 5:59
  the root cause, develop corrective actions, and then it's focused. So there's
• 6:03
  nobody else on that call except for the people who want to be on the
• 6:08
  call, who benefit from being on the call, and then who's through the
• 6:11
  productivity of that call have a direct advantage. However, there's a social engineering
• 6:16
  element that I added. It was beyond what we're doing here now. I
• 6:19
  did get criticized for having too many meetings because me, as an individual,
• 6:23
  had meetings every hour of the day with different groups, and then there was
• 6:28
  paperwork I had to do to figure out what we're going to focus on.
• 6:30
  But again, the productivity talks for itself, and we'll talk about that shortly.
• 6:33
  But I would take the success stories from individual groups, and then I
• 6:39
  also cultivated leaders among the entire population, and so we would have specialized tactical
• 6:46
  groups that would go after kind of these universal defects that impacted both the UNIX
• 6:51
  and the Windows environment. And we would have the decision makers there and the
• 6:55
  subject matter experts there in a small work group focusing on one problem, and
• 7:00
  then I would take the success stories from all these small meetings, and then
• 7:02
  we'd have a larger meeting that had just the leads on it. Of course,
• 7:06
  we'd have a genda written in advance, so the individuals could decide whether
• 7:11
  or not they're going to be there, but we would then praise the successes
• 7:15
  of individuals as they're performing things. And even more importantly, we started documenting
• 7:20
  best practices, so individuals could pull from the library of best practices that were
• 7:26
  developed by their peers and ultimately implement many of these solutions so that they never
• 7:30
  came up on a call talking about the problems. Now, the complexity of
• 7:34
  what I set up is a little bit more than we can cover in a
• 7:36
  podcast, and I can show you specific application if you're in an environment where
• 7:42
  you're resolving defects. But again, it didn't matter whether there are hundreds of
• 7:45
  thousands of defects, or there are forty thousand servers, or there were a
• 7:49
  hunt of fifty leads and thousands of individual contributors. We narrowed focus down to
• 7:56
  those people who can maximize the benefit, and then we amplify and promoted the
• 8:01
  benefit to supervisors. So here's the last part of what I did, and
• 8:05
  this is a problem solving skill, which is number three, the problem solving
• 8:09
  skill. What we noticed is that some of these problems could be easily resolved
• 8:16
  in a short time period. So the meantime between discovery of the problem and
• 8:20
  the solution of the problem was short for some, but others it could take
• 8:24
  months. Because we have applications. Is a very complex environment. And so
• 8:30
  when leadership wanted to measure the meantime between failures, which is how often do
• 8:35
  certain types of environments fail, and then the time to resolution, which is
• 8:41
  how quickly can we resolve the problem that we do find, we had numbers
• 8:46
  all over the place. So, for example, the Unix environment tended to
• 8:50
  have a long period of discovery and solving the problem, but they could roll
• 8:56
  out the solution very quickly. There's a lot of scripting and a lot of
• 9:00
  server images and different things, where the Windows environment tend to have very short
• 9:03
  troubleshooting because there were only a few things that would go wrong, and then
• 9:07
  ultimately a very long implementation because those applications had a greater impact to the larger
• 9:15
  environment, and sometimes it was vice versa. And so by saying okay,
• 9:20
  it takes a typical thirty days to resolve the problem. It ignores the fact
• 9:24
  that in some environments you could have ninety days. And if those environments are
• 9:31
  going to get punished for taking ninety days when it's typical for their environment,
• 9:35
  we're not moving forward with the resources we need. So the resources was the
• 9:41
  problem. The business would say, Oh, well, those Unix machines are
• 9:45
  taking too long to solve problems, and so we're going to just replace them
• 9:48
  with Windows machines because Windows is solving problems so quickly. We had to not
• 9:52
  only be able to present our reports in a logical fashion, but we had
• 9:56
  to present the data sets that got us the resources to properly or appropriate to
• 10:01
  solve the right problems so that we could eliminate all the critical defects in the
• 10:05
  environment. So I talked about best practices. I talked about highlighting successes so
• 10:09
  people feel motivated to have wins. I talked about organizing people so we have
• 10:15
  the right people on the calls. Now, what I added to this was
• 10:18
  a senior executive meeting where we went over success stories. So a couple leads
• 10:22
  come in, talk about their success stories, talk about how they overcame things,
• 10:28
  and then we help contextualize the metrics for those individuals. Okay, this
• 10:35
  is very important. We were helping the leadership understand that we have to measure
• 10:39
  performance based on so I wasn't telling them that their measures were wrong. I
• 10:45
  was saying, we have to measure performance on categorization and application because of the
• 10:50
  complexity was in the application, not in the operating system. Because once we
• 10:54
  determined a best practice to solve a defect, that solution could be applied to
• 10:58
  any server, doesn't matter the application, but the time to implement inside the
• 11:03
  application depends on what that application is going through in its life cycle. Again,
• 11:09
  very complex, but it sees three skills of organizing people, having the
• 11:15
  right people in the right place, having the right skills, and it's a
• 11:18
  lot of cataloging, it's a lot of individual interviews, it's a lot of
• 11:22
  or and by the way, I had a direct line reporting to these individuals,
• 11:28
  primarily through a reporting system that automatically scanned every night to see if these
• 11:31
  problems still existed. Okay, so we're in an operational risk management position.
• 11:37
  There's scanning software to see if these risks still exist in the environment. And
• 11:41
  so there's a lot of automated pressure. We had to organize people around that.
• 11:46
  We had to increase individual productivity because every day the big bosses were getting
• 11:50
  a report that said, you still have these defects, and so how do
• 11:54
  we prevent those distractions? So I did run a lot of interference, and
• 11:58
  again, organizing the executives into a briefing meeting where the leads came in and
• 12:03
  talked about successes and talked about what these numbers mean helped a lot. Organizing
• 12:07
  the individual groups so that they had maximum value in the calls helps a lot.
• 12:11
  I think we got down to an hour meeting with each of the twenty
• 12:15
  five leads by operating system, which is two hours of meetings for me,
• 12:18
  probably two hours of prep for each meeting, and then basically they left with
• 12:24
  homework, assignments or success stories. And then we had one executive meeting twice
• 12:31
  a month, which was about an hour each required about four hours of prep,
• 12:35
  and then of course custom reporting. But again three we're solving problems and
• 12:41
  executive sits down to a meeting and they say, okay, I understand why
• 12:43
  it takes so damn long to solve this category of problem, and so what
• 12:48
  we're going to do is one of my supervisors described as proactive preventative measures in
• 12:54
  order to not have the problem exist in the future. So we actually shift
• 12:58
  the metrics from how often do things break or what's the time it takes to
• 13:03
  fix something that breaks, to does it stay fixed, which in hindsight is
• 13:09
  very logical, but it was not the initial drive from executives. Executives wanted
• 13:16
  to have all the problems solved with no determination by priority. Where we ended
• 13:22
  up with that when an auditor shows up, they will not find a critical
• 13:26
  issue because all the critical and high issues were resolved, and then the other
• 13:30
  issues were fixed in the configuration of the platform rather than the maintenance of the
• 13:35
  platform. So as we rolled out new servers, those new servers didn't have
• 13:39
  any of the problems that we were finding in previous servers, and that was
• 13:43
  considered a success rather than how quickly can we fix things that are broken?
• 13:48
  And so again, when we're using these three skills and we're building the relationships
• 13:52
  necessary to organize people and to help individuals be productive and to solve problems,
• 13:58
  we now shift the thinking to things shouldn't break. The natural state of our
• 14:05
  environment is not to have defects and so once we resolved the defects, we
• 14:09
  eliminated the need for half of these meetings because there were no defects. Now,
• 14:16
  there were no high or critical defects. There were still configuration defects and
• 14:20
  such and such, And I did run a model to identify which groups had
• 14:22
  repeat defects, and we resolved those groups, which types of processes had repeat
• 14:28
  defects. And that was of course on my end. But when it came
• 14:31
  to those engineers who were launching new systems, who were configuring new environments,
• 14:35
  who were also replacing environments over a year or so, they were able to
• 14:41
  make better server images, better configuration plans, and ultimately better implementation of their
• 14:48
  work. Now, was that what I was supposed to be solving for,
• 14:52
  of course, not I was supposed to be monitoring a defect report and encouraging
• 14:56
  these people to resolve the defects. Instead, I engineered an environment where defects
• 15:01
  were not normal, and that normal was a compliance system that fit both security
• 15:07
  operating system and other types of policy that we had in the organization by design,
• 15:15
  so it wasn't an afterthought. It was the first thing we did,
• 15:18
  and then we went in and adapted policy for best practices and then made sure
• 15:22
  that our environment was cookie cutter. In fact, in some environments, here's
• 15:26
  how we ended up resolving the defects. We would end up having some servers
• 15:31
  with defects. They tended to be older servers, and so instead of fixing
• 15:35
  the defects, we just replaced the server because we had a virtual environment,
• 15:39
  so we didn't need a physical server anymore. We could basically come in with
• 15:43
  a virtual image that was the best version of that old server, and it
• 15:48
  had better hardware, and it had better disc access, and it had better
• 15:52
  speed, and we would just decommission the old server. And so one of
• 15:56
  the times the executive came by, I said, why you decommission so many
• 16:00
  servers? And it turns out that we were decommissioning servers that had leases associated
• 16:04
  with them, that had physical hardware in the data center associated with it,
• 16:08
  that had higher than average costs, And so they were upset why we were
• 16:11
  decommissioning so many servers. But when we showed them the cost savings that were
• 16:18
  far beyond the cost to repair, then they understood why some of those servers
• 16:22
  were had the defect for one hundred and twenty days. We actually accepted the
• 16:26
  risk, resolved what we knew best practices for accepted the risk, but in
• 16:30
  parallel had a migration plan to get those servers out of the network. So
• 16:36
  in fact, we were eliminating defects by eliminating defective environments. Again, that's
• 16:42
  not what I was hired to do, but that is the beneficial result that
• 16:48
  makes you indispensable. So if you've got a problem in your business and it
• 16:52
  seems simple, there are ways of looking at it, by organizing the right
• 16:56
  people, by maximizing individual productivity, by solving the problems that need to get
• 17:02
  solved, not the problems that they identified. But we're using again the issue
• 17:06
  management methodology to develop a problem statement, identify root cause, and then identify
• 17:11
  corrective actions so that we can say do we even need to solve this problem?
• 17:17
  You know, some of the executives, and this is critical to understand,
• 17:21
  and I know you're facing this in your environments, but some of the
• 17:23
  executives wanted us to have like zero day fixes or to have like ten day
• 17:29
  fixes. When we told them that we weren't going to fix certain problems.
• 17:33
  We're just going to replace the servers because the new version of that server doesn't
• 17:37
  have any of these problems. They thought we were spending money. We were,
• 17:41
  in fact eliminating hundreds of hours of work by just kicking off a new
• 17:47
  image, an image that had been tested, an image that had no defects,
• 17:52
  an image that didn't require downtime in the application, an image that we
• 17:56
  could roll into a service pool rather than having to take something and shut it
• 18:00
  down and bring it back up. When you implement these three methodologies, people
• 18:07
  are going to look at you like you're crazy. Now, those in the
• 18:10
  know, those who are being praised for their successes, those who are helping
• 18:12
  you develop the implementation, they will know that this is powerful. Executives may
• 18:18
  not until you work out the communications. So ultimately, what we're doing here
• 18:23
  is we're applying a methodology that is making you a powerful leader in your area.
• 18:32
  It's not necessarily making it easy for others to understand what you do.
• 18:34
  So we have to and this is the last point, we have to build
• 18:37
  the association with the successes as you as the organizer. So these successes happen
• 18:47
  when you're in charge. Therefore, we need to make you in charge of
• 18:51
  more things. Now, I will admit it's a lot of hard work on
• 18:53
  my part, to organize meetings, to prep for the meetings, to write
• 18:57
  custom reports, have to be familiar with the technology to make it easier,
• 19:02
  and so in this particular environment, I had to do a lot of things
• 19:06
  that necessarily weren't necessarily in my work scope. But if I could pull up
• 19:10
  a report, and I could let my leaders in the field doing the work
• 19:15
  pull up a report, and I made it easy for them to find out
• 19:18
  what needs to be done and for them to have successes, they by de
• 19:22
  facto turned to me for advice, turn to me for solutions. I then
• 19:27
  can go to the other people in the group, document their best practices,
• 19:33
  and now share the best practices. Overall, we get better successes. People
• 19:38
  who were interacting with me and this environment got promoted. It built relationships for
• 19:44
  me to find new opportunities. It built relationships with leadership for them to know
• 19:48
  that I can get the work done. And ultimately it was three powerful skills
• 19:55
  that every leader must master. It's the ability to organize people, the ability
• 20:00
  to maximize individual productivity, especially those who are working with you, and then
• 20:06
  solve meaningful problems. The problem solving skills. I'm justin hit with inside strategic
• 20:11
  relations If you want certain access and leverage in an organization, if you want
• 20:15
  to be not only seen as the person who can get things done, but
• 20:19
  you can actually get things done, then you're in the right place. Come
• 20:22
  join us at www dot inside strategic relations dot com. We've got a newsletter
• 20:29
  that shares these insights and tips. We've got a paid membership program where we
• 20:33
  talk more in detail about your specific needs and we apply the concept of strategic
• 20:40
  relations We are transforming business relationships into profits. I know it's a difficult topic
• 20:45
  to understand, but we break it down into these bite sized chunks so that
• 20:48
  you can implement. Start today, how are you organizing people? How are
• 20:52
  you helping others be more productive? And then how are you solving real and
• 20:56
  meaningful problems. Thanks for listening and I'll see you in the next podcast.