As I have seen various organizations embrace a DevOps model, there are several goals that they hope to accomplish. One is the idea that by automating the process of building, deploying, and monitoring software, they can make a system that is robust and well-documented. What is the primary benefit of this? It takes that arcane and specialized knowledge that is locked inside of the brains of a single or small group of specialists and makes it available for everyone. This is in contrast to the idea that knowledge, skills, and expertise are isolated within a single person or a small group. This process of isolation is called “siloing” or placing that knowledge into a “silo.” For those not familiar with the word, silo comes from the Greek word “siros” and means “grain pit.” They are typically large structures, and their purpose is to store an item separate from other items. Common examples are wheat, dry cement powder, and other things that are beneficial to keep separate until they are needed.
Silos are useful in an agricultural or materials sense but they are less useful in a company culture sense. Yes, company cultures create their own silos. As a company grows, it requires that individuals take on specialty roles and responsibilities. Not everyone in the organization is capable of knowing everything that is happening or how things are done. Having specialists is not the issue––it’s when those specialists are so heavily relied upon that no one else knows what is happening. In short, these individuals or teams, unintentionally––but sometimes deliberately––wall themselves off from others to protect their expertise. As organizations determine that they want to avoid or at least minimize the tendency of silos developing or proliferating, it makes sense that they would then aim to try to break down those silos. DevOps is a model that aims to make the process of software development and delivery less focused on key individuals and open to more people.
This is an admirable goal, but often what I’ve ended up seeing is that the DevOps team becomes a new silo, and much of the arcane arts of administration and monitoring are not eradicated, they are merely shuffled around. I’ve been on the receiving end of this where I’ve had to try to interpret what others did in the past, document the details so that others can use and understand it, only to realize that I have become the so-called “expert” and that it is my problem now. How did I get here? Surely I’m not the only one experiencing this?
Rebuilding the Silos We Hoped to Take Down
While I can’t say that there is a deliberate effort to keep silos in place in organizations, it can be seen as a natural reaction. People subconsciously want to “protect their turf.” If everyone can do something and it is easy to do, what benefit do I bring to the team? Aren’t I easily replaceable? We can comment all we want to about that being a ridiculous notion, but in my personal experiences, this is a real sentiment and this is often exactly what happens.
Someone has expertise in an area (perhaps it is the underlying configuration of the Jenkins scripts that make up my organization’s pipeline). Much of these details may be new work I am doing or they can be large chunks of code that I have inherited from other team members. It is a natural reaction to think, “if I am needed, I am valuable.” To a certain extent, that is true––but it can also be a curse.
As explained earlier, I’ve often considered the idea of a silo being a way to store something so that it is not contaminated. The flip side is that our silo can also become our prison. What ultimately happens is that we end up “owning this area of expertise” to our detriment. We don’t get to try out new things because we have to maintain and keep running this silo of our creation, where the goal should be to share out the knowledge so that others can work on it and free ourselves for new endeavors.
How can leaders cultivate a new approach to communicating that sets a new tone of openness and passion for cross-department or cross-team collaboration as a software development community? How do they facilitate and empower cross-pollination across silos of expertise while not disrupting project release cycle timelines and constraints?
I believe it starts at the top with open and honest communication, where company leaders take responsibility and openly talk about what has happened, how their management approach has contributed to the problem at hand, and take the lead in demonstrating a new culture by breaking barriers between peer Managers of departments or teams they oversee and facilitate new peer team member Scrum team/workgroup pairing, for example, CloudOps and R&D (Software Developers and DevOps Engineers). They also need to put an end to the finger-pointing and stop playing the blame game. Maybe they even go so far as promoting the creation of joint working groups and shared tasks with shared targets within each iteration, or maybe even as far as reorganizing teams with both developers and DevOps engineers on the same teams instead of in different departments with different managers.
Like I said above, we want to ensure that we don’t just reshuffle these pre-existing silos that we’re trying to take down. To actively remove silos, you need to disperse the specialists across the project teams to become part of the same tight knit communities that develop when people work closely together for a common goal.
A False Sense of “Competition”
Often, it’s hard for individuals on a team to keep that common goal in mind when they’re hyper-focused on their individual contributions towards that shared goal. Many of us can recognize this situation: We have a project that needs to be completed and someone on the team is tasked with figuring it out. It’s possible that there is an infrastructure to leverage, on-site or in the cloud, and there are tools that can be used to make that system work––or at least get it up and running. With a combination of compressed timelines, limited resources, and the need to get something up that works, it is easy to find ourselves “locked in” to a project (or a specific role within a project) and then we hold the ball from that point on.
In the best case scenario, this is a temporary situation and can be remedied by encouraging cross-training and having multiple people understand the ins-and-outs of the system. The trick is to make this decision earlier rather than later. What often happens is that this behavior and situation is not focused on early, and then siloed groups or individuals become hostile to the idea of others coming in and “taking over their territory.” The problem is not the expertise––it’s the unintended consequence of having individuals or groups work separately towards accomplishing their goals and that becoming an antagonistic relationship.
Silos often develop because teams or organizations do not collaborate early to help set the ground rules for how information is stored or shared. Sometimes, it is the result of acquisitions and merging 2 or more teams together: Each team has their own way of doing things, their own evolution of their processes, and then when 2 organizations or teams need to collaborate, there are natural barriers to allowing that to happen, such as different CRMs being used, different back-end database technologies, different hosting arrangements, and different programming languages. Even without these more specific and well-understood reasons for these silos to exist, they can grow even within small organizations––especially if responsibilities are overlapping between different groups.
Championing Shared Responsibility From The Start
If the goal is to have engineering and operations teams focus on a unified DevOps approach, the direction and mandates for accomplishing these goals needs to come from the top down. In my experience, expecting individual teams to just “figure it out” and then be surprised when silos develop––and have individuals and groups defend them––is naive. It is also unlikely that an unsiloing initiative will be successful if it is limited to just one group.
For this example we are looking at DevOps and the goal of opening up the process so that it is less dependent on a single person or group––but it needs to go further than that. If we merely focus on the tooling, sure, we may be able to make a new system that is more efficient and that allows for better building and monitoring of the code as it is deployed. What do we do after that? How do we ensure that the group tasked with this change doesn’t merely circle the wagons once again and become that team that does everything that no one else understands?
For information to flow freely, there needs to be a top-down decision and everyone needs to be on board with it. It’s not enough to just build a DevOps team or model and say “Okay, that’s it, we’re done here.” There needs to be a focus on sharing information and breaking down the barriers to that communication. It may be easier with a smaller organization in that there may be policy changes, training, and a way to make sure everyone knows where to get the information needed to be effective in the methods they have put in place. For larger organizations, there may need to be more difficult decisions, such as doing a literal conversion from one technology stack to another or creating middle-ware that allows multiple heterogeneous systems to work together.
Assure Key Members They Are Valued
One of the biggest barriers to de-siloing is convincing key members to give up their “keys to the kingdom.” For some, this can be a demoralizing process, especially if the idea of unintended “competition” had been championed before. If the organizational culture has rewarded individual performers in the past, then it is important to encourage and communicate a new goal: The success of the organization as a whole.
A common tactic in sales teams is to create competition and reward the individuals that do the best. This same behavior often creeps into the engineering and administrative culture as well. If someone is doing well, then by definition they must be outcompeting someone else on the team. If this mentality and attitude exists in the organization, it may be beneficial to shift the focus towards entire organization goals. Rather than reward the mavericks who outcompete everyone else, instead reward those who are capable of sharing the most information and “leveling up” the rest of the team.
It is entirely possible that there may be individuals on the team who will not want to change. They may be too ingrained in their competitive mentality. They may have built their career being the “loner mad scientist.” Ask yourself: What would happen to your organization if that individual were incapacitated for an extended period of time? In this current era of COVID-19, what would happen to your organization if your key Engineer or Programmer were to need to be hospitalized for an extended period? Could you continue operating effectively? What would you do if this actually happened?
I would argue that every company should have this conversation with every member of their team. Emphasize that the success of the organization as a whole will be counted as individual success.
Conclusion
Much of what I am suggesting here has less to do with implementing technology or with creating a DevOps model as it does with creating a workplace that values individuals working together and encouraging them to do so––the things I’m suggesting more so align with the company culture. DevOps is an approach––and it can be a good one––but it is just as prone to falling into the traps of information hoarding and guarding as any other group within a company. Encourage collaboration, help to break down the natural barriers to sharing that information, champion training and cross-team communication, check-in with your team members regularly, and, dare I say it, consider cutting loose even those most valuable people if they are not able or willing to open up their expertise to others. Rather than jealously guarding a small estate, you may be able to expand your reach considerably further by sharing your skills and talents so everyone can succeed.
Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.