Let's continue the series detailing my experience from 2010 to 2015, where I played the role of transformer for a stagnant IT organization. You can read the backstory in My Real Life Story of Digital Transformation.

When you read the backstory, you will see that I was initially targeted to come into an organization to solve a tactical application issue. This individual issue was a symptom of a much larger set of problems. I spent the next 5 years working inside the organization to make considerable transformation to the way we did business.

In this post, I am going to discuss a process that was invaluable in our organizational transformation where I identified the players and haters that would affect our transformation progress.

Before we get going, I want to call out that these terms are not the most politically correct. However, I want to remain true to the story as they are the terms we used.

I also realize that when you are reading this, you are reading with your internal voice which may not be the same as my internal voice. Therefore I thought I would put an image representation to lighten the content of this article.

Those that are either already on board with your vision or those that you have a strong relationship with.

Those that vividly resist change, those that you have sour relationships with, or those that say no when they either do not understand something or feel excluded from the decision.

Haters are not bad. They are almost always people doing their best to live up to the responsibility they have taken on. Change can make doing that difficult. Especially when the one forcing the change does not have a collaborative and empathetic mindset. Sometimes hatin' is actually necessary to force outside of the box thinking or to prioritize a specific requirement. On with the story.

Technology Alone Accomplishes Nothing

In 2013, I convinced my leadership to send me to Amazon re:Invent. I only had a slight idea how valuable public cloud service could be. The story I wrapped around it was convincing enough that my leadership thought it was worth investigation.

During the conference, my mind was absolutely blown. The problems being solved by public cloud technology seemed almost unreal. There were no other people attending from my campus, but there were a few teams from other campuses that were utilizing public cloud services. I met a few of them, but did not get much time to spend learning from them. When I left the conference my head was spinning. I was ecstatic about all the possibilities I saw that could solve some of our most notorious problems.

I spent the next year focused completely on the technology itself. I was able to convince my company to allow me to setup a test account.

That was literally as far as I got.

I built a few simple demos and showed those off. I received very little feedback.

Time to Change Focus

I returned to re:Invent in 2014. This time I had a mission. I wanted to spend time with the leadership of a team from a campus on the west coast. They were far and away leading the entire agency in adopting transformative technologies and were seeing great success. There was a tremendous amount I could learn from them about legality, procurement, governance, use cases, etc.

When I sat down with their chief engineer, I explained how little progress I had made in a year. He said "You are going about this all wrong! You focused on the technology first. You need to focus on the people. Find the players and the haters. You cannot make progress if you do not have supporters. You cannot overcome the objectors if you do not know who they are and why they are objecting."

I returned home with a clear concept of what I needed to do. On the first day back in the office, I locked myself in a conference room with my closest team member and a massive white board. I drew one circle in the middle and filled it with one word, Me.

Make a Players and Haters Map

I started simple with me in the center. I put myself in the center because I was the transformer. I will have another article that describes the characteristics that make a transformer unique.

I then drew lines up to two other names, my Program Manager and the contract Contracting Officer's Representative (COR). These two positions were absolutely critical for accomplishing any sort of transformation with success. Luckily for me, both of these could be marked as players.

Another interesting twist and advantage in my situation, my COR was also the campus IT Asset Manager (ITAM). This meant that all procurement and technology acquisition decisions went through her.

I drew another line out from my Program Manager to our contract Business Manager. I had a decent relationship with her, and she was very much in the camp of improving our services for our customer in a professional and legally compliant manner. She got marked as a player.

I drew lines out to the Functional Area Managers. There were four functional areas, Application Development (AppDev), Research and Development (R&D), IT Operations for the CIO and IT Operations for Operations Directorate (OD). AppDev and IT Operations for OD were both players. They did not necessarily have the same vision I did, but they were onboard with making significant change to improve the services we provided to our end customer.

The Functional Area Manager for IT Operations for the CIO on the other hand was a wildcard. He was tremendously loyal to the government leaders that he reported to. I had a cordial relationship with him, but I knew making any adjustments to his part of our organization would be challenging. I marked him as a hater.

This is very important because if I wanted to bring in a new way to consume and manage infrastructure, for example public cloud, I would have to have him, his leadership and his team on board.

At this time, I had not made significant relationships with our IT Security leadership. I knew they were going to be a major hurdle for anything we did. I had two contractors on that team that I had decent relationships with. However, I knew this team was a significant weakness. I marked the entire team as haters. I called out the two contractors as immediate targets for entryway.

When I agreed to come on board full time in 2010, I was given a small development role on one of the R&D projects where we were responsible for adding unmanned aircraft models to existing traffic simulation software. The nice thing about this was that I was introduced to and able to make a good impression on several of the research developers and administrators. I was also able to establish a budding relationship with the Functional Area Manager for R&D. I marked him as a player and noted several of their developers and administrators as possible candidates to assist.

I also drew a line out to my team. I did not have an official charter for a transformation team. I just knew I needed to build one. I had a few developers from our application development team that were progressive and wanting to learn new technologies. I had two system administrators on the IT Operations for the CIO team that I had decent relationship. I knew they also wanted to learn new technologies and get more visibility with leadership.

Another interesting list I put along side my team was a list of unknowns. This contract was 180 people in size and was a long running operation. This meant we had some people that had been on this same contract for more than 30 years. This also meant that there was a list of individuals that no one knew what they actually accomplished on a daily basis or had a reputation for doing nothing.

I had a friend in college that is one of the most capable system architects I know. He barely graduated college with a degree. He appeared to never do any work. However, getting to know him and his abilities, I quickly realized that he automated absolutely everything he was responsible for. You could call him lazy. Particularly if viewed from the outside. Truth was, he never wanted to repeat anything and was relentless at making this reality.

So with this hint of knowledge that people like this exist and that it was possible there were some like him on our contract, I marked down the list of unknowns. I did not mark them players or haters. I made a point to get a single meeting with them and have them run me through what they do. Doing this simple exercise exposed three other team members that others had written off. The truth was they were exactly like my friend. They automated everything in their job. They were simply bored and under challenged. During the initial meeting, if I felt they fit this profile, I would tell them a bit about what I was planning and ask if they were interested. The players almost all knew exactly where I was going and were super excited. The haters got a little unnerved and wanted to make sure they would still be collecting a paycheck.

As for the government customer leadership, I listed out the following:

  • CIO - player
  • CTO - player
  • Datacenter Lead - hater
  • Big Data Lead - player
  • Operations Directorate Branch Head - player
  • All CISOs - haters

The Data Center Lead was a guy who had convinced the campus leadership to allow him to work remotely from the west coast before the internet even existed. Good on him, bad for everyone else. He is one of those people that is very difficult to work with. This is compounded when you only ever speak to him on the phone. He was in charge of all infrastructure and IT services for the campus out of the CIO office. He was a hater.

On our campus, we had many CISOs. I have no idea why, but there were a lot of them. They always said no. Always. They were all haters.

The CIO was important because he controlled decisions about funding and would ultimately sign Authorizations to Operate (ATO). The interesting thing about him was that he managed up very well. This was his number one focus. He in turn trusted his direct reports to take care of the organization. So while I did not need to focus directly on him, I would need to focus on his direct reports. He got marked a player.

The last thing I did was to go through all of the project owners across our contract. I marked each of these owners as players or haters. This was a crucial step because I needed to know which players would sponsor our initial work in this transformation. We would not be able to make any headway without forward looking project owners and their funding.

A Map and A Plan

When I finished, there was a whiteboard that looked like a mind map. It was a mind map of our organization of players and haters. This white board had nothing to do with technology beyond the name of the roles.

The next step was to build a plan of attack to strengthen relationships with the players and figure out a strategic approach for the haters.

You have to approach haters in a dramatically different way. You have to understand what they own, what their influence is across the organization, who their players are, and their objections. If you do not understand these things about the hater, you need to find a way to.

Some haters can be disregarded or gone around. Some you must go through. Some you must convert. These last two are critical to your success.

With this new map, I now had a clear picture of my organization and identified immediate places of action for myself and my small team.

If anyone is counting the years in my story thus far, you may have noticed that we are in 2013 and 2014 in this post, but I started this journey in 2010. I will continue to weave stories throughout these five years. It is important to note that if I had done this players and haters exercise earlier, focusing on the people, I would have made progress in our transformation much faster. Our momentum grew exponentially after completing this player and hater map.

Header Image Source:
"Transformers Autobots VS. Decepticons Decoy Miniatures Recasts"by Boynton Art Studio is licensed under CC BY 2.0