Mindsets impacting Deliveries

As a DevOps engineer, I encounter a lot of questions on my book of work. A common perception of DevOps is an automation team, a team with super access or environment stability team. It is seen with a different perception in different industries or different departments in the same industry. In some industries, the DevOps is collaborating with marketing and sales team while in others they are deploying developer’s code to the environment where they don't have access.

People fail to understand that it is not about tools but culture. For DevOps to provide value to your organization, we need to address team structure and collaboration gaps. We cannot align communication ways with our business needs, then no DevOps change will help your goals. I observed different systems and processes in real-life scenarios, but couldn’t connect them all. This law from Melvin Conway in his connected all the dots.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”

Software development is like snakes and ladders. We start with the requirements but most of the time you hit the snake and end up back to the bottom. But right structuring of these ladders can make sure that you fail fast.

Organisational design is something which we tend to ignore while considering smooth delivery. If we consider each node as a sub-team and communication channel as a chord, then each chord signifies a delay. It is observed that time taken to solve a problem which involves contacting an external team is 10 times that internal communication takes. We moved towards the idea of smaller teams for faster deliveries and collaborative work but never thought of how we are going to address external issues.

We observe that our code ends up more closely meshed with the teammates we talk to the most. Any problem can be addressed quickly as there are no communication barriers. But dealing with external teams is always a mess. We don't even make 10 minutes change until a higher escalation comes. I am not against the communication channels but how these channels work worries me.

Here are the problems we see with the organisational designs:

Unwanted complex processes

Working on the efficiency of something which shouldn't be done is the most useless thing.

So for smooth deliveries, we need to remove something which is not required. People try to defend their processes on the name of compliance, security or regulation. In reality, they are resistant to change. Here growth mindset comes into the picture. We can always keep on reviewing our processes.

Departmentation:

The process of departmentalizing an enterprise for gaining efficiency and coordination: the grouping of tasks into departments and subdepartments and delegating of authority for the accomplishment of the tasks

Above are the organisational structures of big giants and their products end up looking like that. None of the structure is superior or inferior, its just alignment of communication channels with their business needs. We tend to fight with Conway's law rather we should be working with it.

Some of the largest problems affecting software development revolve around departmentation:

• The right work being done by the wrong person (E.G. your front end engineer maintaining AWS)
• The right person in the wrong role (E.G. A brilliant DevOps engineer running your automation team.)
• The right functionality being maintained by the wrong team (E.G. QA Documenting your API)
• The right information is known by the wrong people. (E.G. The cardinal sin of having only a single person that understands your whole system)

Responding to change:

We are now moving towards microservices from the monolith approach. Imagine if a large team was working on a monolithic application. Now in scenario of microservices, the same big team cannot work. Initially, in the transition phase, it may seem like compromising with speed. If changes are not made then it would fail eventually.

Idea is to have small agile teams. These small agile teams start working with each other through strong agreements. These agreements can be APIs, requirement documentation or software interface. They can make changes to their codebase as long as they are adhering to those contracts that are strong boundaries. So Melvin Conway also tells:

Ways must be found out to reward design managers for keeping their organisations lean and flexible. There needs to be a philosophy of system design which is not based on the assumption that adding manpower simply needs to productivity.

Not every organisation has a luxury to completely change from monolith to microservice-based architecture. There are other priorities too. So we can start with the concept of tiger/Hero teams where one team acts an example and tries to isolate. But this completely depends on the culture of your organisation.

We need to keep in mind that is not for promotions or a new team is the good or old team was worse. But there is a sense of shared journey and growth of the entire organisation. We make sure that we have a culture of sharing, failing publically and benefitting others from your mistakes. This is all about pioneering.

I will be discussing the case studies of Conway's law in my upcoming blogs and how inverse Conway's law helps. This is not a scientific law. But this was something I realised in 2 years working for fintech. Just imagine your self as a data stream and see how traffic, housing society, workplace and other systems treating you. Conway's law would connect the dots.

To solve technical problems, you often have to go outside the technical domain.

-pola7