IT is the code

When I first started to work in the digital sector anything that was remotely “tech” was subsumed under the eponymous word “IT”. Information Technology or IT for short is a concept in Germany that encompasses everything from fixing computers to coding. Even in companies, we were guilty of using it. 

Naturally, I had been aware of the distinctions. And yet, it took years to deeply know about the various categories and processes. I am glad that I undertook this journey of learning more about something that pertained to more than just “IT”. 

Definition of DevOps

Much of what “IT” was used for was, in fact, DevOpsWikipedia defines DevOps as

“a set of software development practices that combine software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.”

In the State of DevOPs Report, Puppet and Splunk report that nowadays even special DevOPs teams exist. No matter the definition or execution of DevOps, the approach means to make teams faster and more successful. In the literature on the subject, I find an abundance of reflections on tech teams and processes. 

Making organizations better – in writing

At the same time, there is an excess of writings on how organizations as a whole can become better – addressing specifically how tech teams need to be incorporated in the new way. Getting them on board, so to speak, tips the scale in favor of the whole entity.

This made me wonder… Why is there such an all-encompassing approach on the one hand and such a compact one on the other? Several reasons come to mind.

  • I have not yet found all sources on the matter.
  • Tech teams often lead the way in process innovation and focus on internal processes first.
  • It is not tech’s task to fix matters for the whole organization.
  • HR or project management take a more holistic route and tend to occupy themselves more with all-involving concepts.

Tech teams as separate entities?

However, I am not convinced that one or several of these reasons lie at the heart of the matter. Wherever I worked, tech teams had been seen as distinct entities, sometimes with different rules. From a financial and recruiting point of view that is more than relatable. CEOs want developers to be as happy as they can be so that staff turnover remains low. The costs for hiring and onboarding alone eat up a significant amount of resources.

But again, something is rotten in the state of Denmark when we look at teams in isolation. EVERYTHING is influenced and designed by tech in digital companies. And even in traditional businesses, the tide is turning toward more involvement by engineers in every single process. 

If engineers are purposely kept in the dark so as to “focus better on their own work” (direct quote) how are they supposed to understand the very problems they are meant to solve? Innovation starts and ends with the information flow in an organization.

Making each other better

It has been argued that DevOPs as an approach is most of all introduced to reduce complexities. Spreading out tech resources on anything other than lean processes appears counterintuitive. Some also argue that engineers, essentially, are executors of previously defined innovations.

What I have observed, however, is that the best results ALWAYS came out of close exchange between tech and non-tech colleagues. A DevOpsCom ecosystem, if you will. I am admittedly biased by the “comms” point of view. Comms here refers to a loose collection of communication, community management, marketing and editorial representatives. 

Some management boards actively encouraged this meeting of minds. Others artificially separated colleagues and went as far as to berate employees for seeking knowledge beyond their current skill state. 

An example: the often-feared bug

Maybe it is best demonstrated by the horror vision of digital teams: mysterious bugs. In a high proportion of cases, it was community management which rang the bell if something was going on. One analysis showed that we had reported 60% of all bugs, already excluding incidents which did not turn out to be bugs. 

Why is that? Since there is so much communication between community and CMs, strange happenings are mentioned. After a while, patterns emerge. It is in the CMs’ area of responsibility to test and verify bugs, and if necessary, to describe them accurately and report them. Sometimes, one message is sufficient to get a hunch because it calls to mind something that happened before.

It is one thing if we find something and pass it on. It is another when there could be something coming and we are uninformed. Preparation is key – on both sides.

Introducing DevOpsCom

So what makes a DevOpsCom approach so successful? Early information systems maintain tech and non-tech teams alert, translate user feedback for coders, keep CMs abreast of news and updates and enable everyone to react swiftly and with the right toolset.

In the case of bugs, it is often not enough to simply fix them. Users are curious about what caused them, how they can contribute to avoiding them and what was done to fix them. This transcends to stakeholders in general. I had questions from partners, customers, even investors! The more I know (what exactly to communicate) the better I can represent the company to the outside. We were once jokingly called the “mouthpiece of tech”. For me, that is not derogatory. It is a representation of facts.

Dev  Development  Ops Operations Com Communications

DevOpsCom at its core

Communication and information is essential, in all aspects. So what would DevOpsCom entail? In the strictest sense, it is a practice the extends the communication of DevOps principles to neighboring non-tech, and primarily stakeholder-facing teams at that. In a way, it is the very simple extensions of well-established knowledge to a wider user circle relying on non-tech mechanisms.

The core points:

  • involving stakeholder-facing representatives in monitoring 
  • early consultation on bugs and product design with them
  • teaching selected colleagues about small fixes (manually or technologically) 
  • schooling colleagues about processes and technologies
  • supporting colleagues from non-tech teams in transitioning into technical roles
  • explaining why features are not implementable and/or what is behind a solution 
  • pairing colleagues from tech and non-tech work on projects, e. g. in a hackathon

There are various benefits to this approach:

  • early bug & problem solving
  • better harmony between teams / bonding
  • a clearer understanding of continuous education needs
  • lower turnover of staff (comms are not as expendable as is currently the impression!)
  • quicker onboarding
  • more enlightened and satisfied customers
  • better communication flow during processes
  • more realistic expectations overall
  • more and better ideas

The way to go forward

Complaining is easy. Providing solutions is hard. Within the frame of this short article, I can but sketch an approach. I hope that I will inspire a few and fortify those who have already taken this path. A lot of engineering managers I have spoken to in the last few months confirmed these ideas and my reasoning for the article. This adds to my own experiences of implementing them in projects I was involved in. 

By applying these principles in the workplace we can contribute to aligning tech and non-tech teams and providing a better user experience overall.

Share this
Categories: Collaboration


Owner of this blog. People and tech. Coaching and community.