Join my daily Newsletter

Subscribe to get my latest content by email.

    I respect your privacy. Unsubscribe at any time.

    preloader

    Diving into the connectedness of DevOps

    • Wednesday, Apr 22, 2020
    blog-image

    [Reading time: 2 minutes 1 second]

    A few days ago, I wrote to you about how everything is connected in DevOps.

    Remember this picture?

    +--------------+            +--------------+
    |              |            |              |
    |    Culture   | <--------> |  Technology  |
    |              |            |              |
    +-------------++            ++-------------+
                  ^              ^
           ^      |              |      ^
           |      +--------------+      |
           v      |              |      v
                  v              v
    +-------------++            ++-------------+
    |              |            |              |
    |  Practices   | <--------> |     Goals    |
    |              |            |              |
    +--------------+            +--------------+
    

    Let’s take a look at one of its juicier aspects today: Culture vs Technology.

    It feels like they lie on opposite ends of a spectrum:

    Culture is very subjective, human-centered and squishy.

    Technology, on the other hand, is (supposedly) objective, not-human, and concrete.

    Yet… they have tremendous influence on one another.

    The culture in your organisation dictates how technology is used, how the results of its use are evaluated.

    What good is a dashboarding solution if you have a company culture centered on secrecy and guarding “your” possessions?

    What good is a continuous delivery pipeline, if your organisation is so fragmented that the delivered artifacts languish for weeks anyway before they can be put to use?

    And technology will leave its mark on culture: if, say, you’ve introduced ways to instantly stand up new environments for experiments – then it’ll be very apparent if those experiments fail to appear: maybe because there’s a stifling atmosphere, or perhaps because the situation doesn’t allow time for experiments.

    I’m sure you can tell that therein lies a grave danger of course: culture may stifle an otherwise quite beneficial technological initiative. Or technology will bend culture in unfortunate ways (issue trackers are particularly good at this).

    At the same time, there’s an opportunity there of course: a lever to attach your DevOps Ratchet, and use culture to drive a technology change (or, more frequently, the other way around – use technology to lay the groundwork for cultural changes).

    But this means that all such changes, all introductions of new things, must be made very deliberately, with a clear view as to what you’re aiming to achieve not just in the quadrant you’re ostensibly changing, but how the other three will react to that change.