I believe one of the best things to ever come out of DevOps movement that no one seems to be describing is essentially an explosion of critical thinking and reasoning skills, The maturing of IT if you will. Some people prescribe different views or distill it into different methods such as C.A.M.S (Culture, Automation, Measure, Share), some people say it’s the destruction of silos, some say it’s just a cool cultural shift and an awakening of sorts. I’d like to take you on a short journey and focus on two things for this topic – the concept of critical thinking and silos.

I found this blog post by Ben Kepes VERY interesting, where he discusses the odd effect of DevOps teams becoming silo teams in and of themselves and how that could appear to be negative or wrong. While I think it is an interesting point to bring up, I think its made without looking at the “WHY” it happens and more of a conceptual view of “WHY” it shouldn’t happen. So lets put on our critical thinking caps and “think here for a minute” about the whys of silos 🙂

From my perspective, the biggest reasons we see silos aren’t vanishing (and quite possibly are being replaced by new silos) is that the silos are the result of real differences of domain. By this I mean, the domain knowledge of your operations, development, analysts, QA, DBA’s, sysadmins, engineers or any group are essentially domains of expertise. When it comes to cultural changes, the best change we can do isn’t to squish these silos down and pretend they don’t exist, but to align them better and give them strategic significance. If a silo really is a moving target, lets align them so they’re all moving in the same direction!

It seems to me, we’re more focused on prescribing ideas rather than deriving solutions. We see improvements because we aligned developers and ops into a team and we think “wow, getting rid of those silos worked” but maybe the silos weren’t the problem to begin with, maybe it was a failure of alignment, workflow, poor cooperation and poor business decisions. By aligning people and connecting them to not only costs of doing business but the revenue of doing business the entire “WIP” chain can see the impact of their work as a whole, as a unit, and as a team (Something to Measure!). Much like the comparisons of WIP from an IT shop to WIP of a manufacturing floor as described in Gene Kim’s excellent book “The Phoenix Project” we have to remind ourselves that even though the mfr floor looks like its running on its own and well oiled and doing small and simple tasks – those small and simple tasks are not just the experience of repetition, but silos of domain knowledge and experience that you don’t NEED to squish and quite frankly, do better when left to be developed and fostered.

I had my first real world experience of this in the early 2000s when I worked at a manufacturing plant. I was a technical lead for implementing an upgraded ERP/MRP system and one day, the manufacturing union went on strike and we full-time employees were led out into the floor to run the plant to finish delivery of critical items. I never thought much about it other than how interesting of an experience it was to go through a labor strike and realize how specialized some of the manufacturing jobs are and how they can appear simple but be rather complex in the end.. I realized I couldn’t assemble tubes like they did, my ceramic painting skills were terrible and the output/workflow of my experience was disastrous at best. Again, after reading “The Phoenix Project” I had a few epiphanies and differing views of the “flattening of silos” that I just couldn’t figure out how to express for a while and it’s just barely coming out here. It dawned on me that the people working this assembly line have a domain knowledge of their own. The people fixing the assembly line have a domain knowledge of their own. When the line breaks, no one expects the line workers to come in during their off hours and fix it because they need to be bothered to learn something about what broke, The line maintenance and facilities crews do their thing. Both domain experts of workers and repairers also have their pipeline, their WIP, their process improvement and they coordinate and match these skills, not distill them and flatten them. So why have such an expectation in IT?

So long story short, I believe we need to do better at understanding the “silos” we complain about. Again, the existence of silos in and of themselves doesn’t mean that they’re all silos of control, silos of despair & silos of differences and if they are these described silos, well, there lies your problem. You can fix the flows, you can align the groups and you can integrate teams and get them working together without artificially ignoring domain knowledge the same way you can prevent domain knowledge creating artificial silos.

The “Why” of Silos isn’t necessarily a bad thing by itself. Have you ever put your critical thinking cap on and thought about YOUR personal “silos”? Are you able to be “culturally adept” but still hold on to personal prejudices against all things commercial or all things not invented here? Do you let your hatred of specific vendors / ideas / practices tunnel vision your beliefs? Are you using silos as a big stick to ignore domain knowledge and experience? Are we really being critical thinkers?

Think critically about your organization. Understand how important your role in IT is to the business and its bottom line. You’re all on the same team, and there may be many silos, but as long as all the silos are on the same “farm”, they really shouldn’t be a problem. In fact, you may soon realize that when your silos are there exactly when and where you need them and this may be more strategic and important than tearing them down and having everything scattered across the field.. metaphorically speaking 🙂

We evolve into silos of domain expertise as a natural progression of our careers, aspirations and experiences. These silos can be very powerful if used wisely and correctly recognized and aligned by your organization. Perhaps DevOps is its own silo, especially if you imply DevOps with specific ideas, tools, solutions and services and that’s why I think silos are less important than we realize and the real concept we should be focusing on is “critical thinking” because it’s that skill that really matters. It’s critical thinking that will give you the gut feeling of what works and what doesn’t and where you need to align yourself and your peers within your organization.

Hope to write down more thoughts on this later.. what do you think?