Devops – It’s about critical thinking & the evolutionary “WHY” of Silos.

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?

About these ads
Tagged , , , , ,

14 thoughts on “Devops – It’s about critical thinking & the evolutionary “WHY” of Silos.

  1. Hi Byron,

    Interesting read.

    I completely agree with the DevOps mindset that there is generally too much silo-thinking in IT these days but I don’t think that putting everyone in the same big silo is necessarily the best solution to this problem.

    I believe everyone should have a high-level knowledge of the world outside his own specialty, but the farther away the less deep his knowledge has to be: a dev should know the ops world to a good degree of detail, but should know less about finance and even less about cleaning the toilets. And there should be adequate integration/overlap between the teams, again depending of how intricate their worlds are entangled with one another. And not to forget of course there should be shared goals, cooperation should be rewarded etc.

    But expecting that you know everything about everything doesn’t seem to scale well outside of the top 1% of intelligent and passionate people.

    I guess the division of labour has allowed us to become a highly advanced civilization so I don’t think all is to be thrown away here. Same with applying OO to a complex code base.

    Niek.

    • byronm says:

      Niek,

      Thanks for your feedback, high level knowledge of your organization is of the utmost importance in being able to work with your peers and across your organization. That is the first step in developing a positive workplace and positive culture for sure.

  2. I think I’m inclined to disagree with you on this point. You’re right that it’s reasonable to ask why it happens, but what is being addressed in the referenced blog post isn’t a natural outgrowth of domain knowledge, but rather attempting to mirror the success of devops without understanding it by just creating a “devops team”. To try to achieve it with technology and nomenclature.

    Further – I don’t know that I’ve ever seen it argued that domain knowledge should be squashed and distributed. Rather, this approach would say that having a single team where all of this knowledge is institutionalized creates a scenario where communication is stunted, responsibility is disconnected and vague, and work doesn’t flow well. Breaking down the silo doesn’t change that the knowledge is limited to an identifiable set of individuals, it just means they work collaboratively on an individual basis with people who have other skill sets in cross functional teams instead of throwing work over the proverbial walls.

    To use your analogy, the problem isn’t whether or not line-workers come in and do domain-specific repairs. But rather that if the teams weren’t in silos, maybe the line-worker would’ve checked if it was okay before putting a chocolate bar in the shredding machine or whatever. And further, having at least basic capability to react to things they do actively to break things would be good. Copy machine repair is domain specific knowledge, but most people should be able to clear the average paper jam themselves, and there’s no reason to bar them from it.

    Far from squashing domain-specific knowledge, it’s spreading the basics so that more advanced and more specific knowledge can be attained and focused on.

    • byronm says:

      Mark,

      Thanks for your reply! I don’t dispute the merits of doing what brings success to your organization, but what I hope to do is to get people to objectively think about what really brings that success.

      In many ways, what you describe isn’t the destruction of silos of independent domain expertise but the realization that your new DevOps team (silo) is merely the new domain of expertise that you have defined as a need. If your position requires specific tools, patterns, services and support to fill a role – then that is a domain by which your organization has a role to fill. This isn’t inherently wrong or evil and in fact, is natural in the course of business.

      I don’t think a single team changes anything other than an org chart. If you can overcome those proverbial walls by calling it a single team, what really kept you from doing that before? That’s what you need to quantify, measure and treat. If you do create single team, there is nothing wrong with that silo as long as you know that single team can’t build a new proverbial wall. (or else the whole cultural alignment is moot)

      Most importantly, the basic capability to react to things that break, isn’t impacted nor changed by an org chart. In fact, recognizing your domain expertise means that you have the right people at the right time fixing the problems. That should be part of your measuring and sharing cultural movements, align your teams and make sure they’re working on the right problems at the right time. The “easy stuff” should be automated, the hard stuff is where you don’t want proverbial walls and most certainly when you want domain expertise.

      Thanks again for your comment though!

      • I’m trying to wrap my head around your reply here, because it sounds almost like you’re agreeing with me when I read it. I don’t disagree with the idea of measuring, I’m very much a proponent of a ‘predict, try, check, improve’ cycle.

        I also think having “domains” and “roles” are not the same things as having silos. This is where I think the nomenclature is the problem – that perhaps we’re not using the same terms the same way. A silo is when you put people with similar function together in a group and then have other teams interact with the “group” as an entity, where each of those silos are mostly (or even totally) incapable of healthy two-way interaction with other related teams. In fact, the organizational culture may even make it detrimental to interact with those other teams.

        This is why the silo *itself* is bad. The focus is on org charts and other manufactured nonsense rather than on the goal of actually getting a great product that customers want out the door. The focus is on process and procedure and plans and not on the goal.

        The fact that there’s no silo doesn’t mean there is not an identifiable group that has specific domain knowledge and responsibilities. Rather it means that they don’t think of themselves as a group with a territory to own and protect. Instead, they’re a part of the whole, with responsibilities to the whole. So every member of your team is able to work closely with the members of other teams, and the concept of ownership changes drastically.

        This is where I feel like either our terms are incongruous or one of us is really confused. I absolutely agree with most of the last part of the above comment. Your teams should absolutely be aligned to have the right people in the right places at the right times. I think it’s foolish to assume that can be done with an org-chart. The org-chart defines domains and divisions. The right knowledge in many cases crosses those boundaries, and that’s why not having silos is critically important. So that when the “right people” include people from three different realms of domain expertise they can immediately form the temporary cross-functional team they need to be in the right place and the right time.

        But then you say there’s nothing wrong with creating a single dev/ops team that’s a silo as long as they don’t build a wall. Except that’s definitial to a silo. If you don’t have the proverbial walls, you don’t have a silo. And even if that *team* isn’t a silo, if the rest of your organization is, they’re not going to be able to accomplish anything – because they’re still *surrounded* by walls.

  3. Arguing against silos isn’t the same thing as arguing against specialization. Rather, it is arguing against *organizing* along the lines of specialization.

    • byronm says:

      What supports that argument? I think when you look at things objectively you can see what to objectively change. It’s fairly easy to squash a team that is already fairly flat, but what next? How do you scale those changes to the entirety of IT when the silos and organizations are so vastly domain specific and somewhat independent?

      I believe you have to quantify the changes within so you can export them beyond and know what to fix and address without squashing teams flatter. Find something quantitative, test it, try it, measure it, rinse and repeat. Next years thing may not be flat orgs but it will be something someone found to work and make it work because they are quantifying and measuring and being dynamic as an org too.

      Thanks for the comment!

      • Advances in methods of software development have never waited for the results of controlled experiments with objective quantitative measures. As in the case of Agile vs. Waterfall or continuous integration or pair programming, people sense something wrong with the status quo, try something different and if it works they stick with it.

        And I don’t think anyone is arguing for dissolving all functional departments – only those like dev, test, UX, deploy etc where org boundaries come in the way of continuous collaboration, product innovation and time to market.

      • byronm says:

        I guess I’m curious how you measure what works to “stick with it” if your not measuring goals and and tracking data / metrics.

        Is Devops in your mind the idealistic way to get stuff done? Or is it something you adapt, build upon and refine for your own organization?

      • >I guess I’m curious how you measure what works to “stick with it” if your not measuring goals and and tracking data / metrics.

        I think this comes down to being part of the experiment versus conducting an experiment at a distance. When we are a part of it, we can sense a reduction in pain (or not) before and after we introduce a change.

  4. Curtis Yanko says:

    In my own work I very carefully position my DevOps ‘team’ as enablers and facilitators. Our success criteria is to enable stakeholder self-service. We’ll partner with any group to solve a problem and we’ll share any problem we’ve solved with any group.

  5. […] Uh oh, controversy! Siloed Dev and Ops teams are bad. Yup. So what about siloed DevOps teams? […]

  6. One of the many things that stuck with me from reading Mike Rother’s _Toyota Kata_ was this:

    “Many companies have tried unsuccessfully to reorganize in the hope of finding organizational structures that will stimulate continuous improvement and adaptiveness; for example by bringing departmental functions into value-stream-oriented organizational structures. As tempting as it sometimes seems, you cannot reorganize your way to continuous improvement and adaptiveness. What is decisive is not the form of the organization, but how people act and react.” (p236).

    However, if you _do_ have the right mindset, reorganization along value stream lines can achieve other goals. Search for “Big Mandate” in Steve Yegge’s platform rant: https://plus.google.com/+RipRowan/posts/eVeouesvaVX

    • byronm says:

      Jez, Thanks for your feedback! I actually just got a copy of that book to start reading through and hope to digest some of it this weekend. Hopefully when I finish it up, I can get in touch with you again to toss some ideas and thoughts around!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 511 other followers

%d bloggers like this: