In my first article of this series on Support in the 21st Century, I laid out my thoughts about the baseline expectations for the corporate support model and structure established at most companies. This is where I first brought up technology silos and presented the correlation between the number of technology silos and the size of the infrastructure.
In my second article of this series, I presented the thought that as the number of silos increases—silo sprawl, if you will—companies segregate the support staff, with collaboration and cooperation happening in the form of requests, incidents, and changes. Any efficiency and agility achieved is lost with the bureaucracy that comes with it.
In my humble opinion, the support teams that are large enough to have a few established silos are the teams that are small and agile enough, with the teams interacting with each other day in and day out. Unfortunately, the reality for these larger infrastructures is that the silos are a necessary evil for grouping the technology skill sets together. They make the team segmented enough to be able to efficiently manage as they grow in size and scope. The growth will require the team members to be hyperfocused and skilled in their chosen technological field.
Let’s use, as an example, a support team that is responsible for an infrastructure that is made up of around ten thousand servers. I mentioned that the support team members are hyperfocused in their area, and you would have to be to support something that size. Something that I and my peers have come to understand is that there is no way to support that many servers when you are performing your support and operational tasks by clicking boxes in the graphical user interface, or GUI. Automation has always been the key to consistent reproducible success. So, if automation has, for the most part, always been in place in one form or another, why hasn’t the efficiency and agility in the environment increased with the amount of automation? That is what I would consider the million-dollar question. Let me lay out arguments as to why.
Efficiency and agility actually have always been present when automation has been deployed or is present. What really matters is where and how you measure the efficiency and agility. If you get your metrics and measurements from inside the silo itself, you could easily ascertain how the automation has brought about the expected efficiency and agility results. However, from what I have seen, the positive results usually stop at the boundaries of the silo. One reason is that the automation is usually developed to automate a specific task that is requested repeatedly. I would like to add to that to say that not only would the automation be silo specific, but in most cases the source code, content library, and automation engine could very well be silo specific as well. This helps cement the separation and decreases the efficiency of the team overall. This, in my humble opinion, is first wall that needs to be brought down.
As I mentioned earlier, the silos, which can be considered to be good, bad, or indifferent, are here to stay. However, to bring the agility of the different silos together, these silos need to break down the wall and work together, or at least give the appearance of working together. How does that happen? The easiest first step forward is to designate a project manager (PM) or other lead who can look at all the steps and tasks needed to complete a request or change from start to finish. This is the person who will break down the walls and guide the silos into working together, even if inside the silos this cooperation does not appear to exist. The PM gets each team to automate its tasks and helps define how the handoff from silo to silo will happen. Look at it this way: a change request gets created, and following the different steps to completion, each silo could automate its specific task and create the task for the next silo to complete. Automation would pick up the new task and start that silo’s automation and new task creation until the change is complete.
You can see where I am going. Silos and separation will be needed, but there also should be be a team that does not work inside those boundaries. It should establish a centralized content library or workspace for all teams to contribute to and work from. SharePoint is a good example of how companies are organizing and presenting information under one roof for all. What makes this different from what would normally be expected from a PM is that usually the PM just guides the different groups. Now, the PM must become the centralized hub for the different groups and help bring all the groups together in some form or another. Doors or connection points need to be created in the silos. I would like to propose that instead of using the project manager, as is standard, a better way to go would be to create a team of representatives from the different silos to manage the cooperation. Could this not be considered the establishment of a kind of DevOps mentality? DevOps means different things to different people, but what makes it work is breaking down the silos into a single group that can take advantage of the expertise of each of the silos.
I truly believe these are the changes necessary to bring about the efficiency and agility that are wanted and needed to help define support in the 21st century.