DevOps officer’s (b)log, stardate 202105.13
It has been truly challenging. Many months have passed since my last blog post Devops 101 – pt. 1: Journey to enlightenment. Writing the (b)log entry has proven to be much more challenging than expected, and this is the third time I write this almost from scratch. My current project has also taken most of my time, so writing this down had to be delayed again and again.
What could I say about silos without sinking into the bottomless swamp? I could state it shortly and just mention, that it is all about communication and transparency, or really go into the details and possibly bore my readers. Where is the neutral zone?
Looking at the past years, what I have seen, heard, and read, and thinking about what creates silos, there are multiple reasons. It might be a business decision. If the project is a multi-vendor project, each of them producing one component or maybe working as part of the team, business decisions may lead to knowledge being held back from the external members. On some level, this is natural in the world of corporations, but at the same time, it actively reduces transparency and can cause trust issues. “If we are holding back information X from the team Y, what are they hiding from us?”, one may think. I can understand withholding information on some level as a business decision, but at the same time, it does not help keep up the sense of trust to others.
The physical manifestation of a silo (though this one might be for wheat)
Behind hiding, knowledge can be fear of losing status, job, money, power, or having to be responsible for something. It may be abuse as well. If business partners hide relevant information and work behind each other’s backs, they may be abusing the relation to gain something from the other by not telling everything. If this kind of thing comes up someday to the other party, it can be very damaging to the relationship. “If you used our relationship and goodwill for your benefit while hiding information from us, why should we trust you?” The answer often is, “It is just business”, but it never is “just” business. It is never two faceless corporations cooperating, it is the employees, whether ordinary Joes or business managers, but it is always human beings working together and for them, trust is important. But more on trust some other time.
Something, something, something, separation of concerns. Something, something, something, devops.
While I fully support the idea of separation of concerns in software development, and in fact, it is my prime directive, implementing it over-zealously everywhere can lead to silos as well. If the team structure or organization structure is based completely on it, it may lead to having a separate team take care of security, releases, operation, development and so on. Code is just passed from one to another and there is very little communication and transparency between them. Concerns indeed have been then separated, but now there are silos.
Wisdom is to know how to use knowledge. It is a good thing to have leads for different subject matters since no one can know everything, but the work must be made visible between team members and different teams, there must be transparency so others are informed what is happening, what blockers there may be and what new features are being designed and implemented. That allows efficient cooperation early on when specialists can give feedback each other and possibly help remove the blockers.
There are other reasons as well for silos, and sadly, sometimes getting fully rid of at least some of them might not be possible. One of these situations is laws and regulations, which might require certain type of process or separation of responsibilities. While I do not have personal experience on these matters, they are something that might pop up when dealing with things like national security, military and finances. A dear colleague of mine also shared a story that budgeting could create silos, when different teams are not allowed to help each other because of budget reasons, even briefly.
The Silo Crusades
But even though silos are something to get rid of usually, hunting them down religiously can also lead to trouble. It is easy to see spies and enemies everywhere when one really tries to look for them. I have seen it resulting in attempts to force people out of their comfort zones, thinking that those zones are silos, but there is a key difference between being in a silo and being in a comfort zone, and that is the walls.
If there is a strict wall between people, then it is a silo, but if there is transparency, openness, a constant stream of information, and the possibility to move from one place to another, then it is a comfort zone. We all have them, some might be more specialized in back-end development, some are purely front-end developers, and so on. But if it is allowed and made possible for us to step outside of those roles, and participate in doing other things as well (and of course knowledge is spread by communicating), can we really talk about creating silos? From my point of view, no.
The Man, The Myth, The Legend, The Lord of Darkness
How could I then as a devops officer help the crew remove the silos? I already have mentioned communication and transparency as key features to this but there are so many moving parts. Size of the teams, amount of the teams, how people communicate and work, how people phrase things, cultures (e.g., organizational, team, national), the level of psychological safety, tools – oh, there are so many factors involved in this and there are things that cannot be forced on people.
I cannot force others to change their culture, but I can encourage them to communicate more and ask when they do not know something. I can organize demo sessions where everyone can voluntarily demonstrate what they have done so far and how something works. I can drive for faster and much more open communication methods such as Slack channels instead of email discussions.
Having one source of truth is not something to forget either. Multiple wikis or places for documentation just leads to confusion and increases memory load. Phrasing also matters. It can be very discouraging if the other side in a conversation uses sarcasm, or weaponized form of advocatus diaboli argument. Devil’s advocate is easy to weaponize into something that does not really feel like something intended to drive the discussion further. It may be intentional or unintentional, making it dangerous to use and in my books an anti-pattern to be avoided.
The Devil, (Public domain)
If we consider the following discussion:
*Developer has suggested improvements in the architecture and payback of technical debt to make the development work more fluent and safer in terms of deployment*
Manager/PO/TPO: “If I play devil’s advocate for a while, and take the role of the end-customer. Why should I as the end-customer care if the development work is easier or more ‘fun’ to the developers, what do I get out of it? What is the return-on-investment?”, says the product owner.
This argument feels confrontational, doesn’t it? There is the difference of power, one being in a decision-making role and the other being an “ordinary worker”. The argument dismisses the initial reasoning done by the developer and instead suggests that only the return-on-investment matters, which can be difficult or even impossible to calculate or estimate in certain cases. It may well be a valid point, that to someone the ROI is the only thing that matters, but this does show that the arguer (in this case the product owner) does not have the skill or will to cooperate and help combine the initial argument to what is needed to convince the other parties that ultimately pay the bills, moving all the responsibility to the developer. This corrodes the sense of psychological safety, the feeling that developers matter, reduces conversation, and instead increases frustration leading to cynicism. All of this increases other risks such as burnout and losing the employee to some other company that cares about people’s wellbeing making it anti-devops.
So, in the end, the enemies of silos are constructive discussions, a good amount of quality communication, and transparency. With the help of them, we can create better quality software and faster, without burning out ourselves. Of course, there are other factors that must be taken into account, but at least now we have a good basis to build upon.
Computer, end devops officer’s (b)log and save.
