How to manage the basic architecture and development teams

Sometimes it seems to be split into two hostile camps. One side is the stability-oriented infrastructure engineers who want to protect their own environments. On the other side, developers often try to find unique and better methods to achieve their goals. The struggle between the two camps was so fierce that even the busiest managers began to notice this.

A failed project

The first major project I attended was to help a school move a basic financial information system from one platform to another. I am a problem solving expert and configuration expert in the infrastructure team. This application is outdated, and the development team is still facing challenges to upgrade it to meet the current and future needs of the school.

The process starts normally. We set up our own servers, configure routers, and have fun building IP subnetworks. When the infrastructure team is busy with stability tests, developers move back to their dusty rooms and dark corners. They work late at night.

One month later, the two teams did not speak unless we had a weekly meeting. After two months, these weekly meetings began to become more appealing. The infrastructure team made the final configuration and completed the basic stability test. The development team comes to us every week to bring about new changes, patches and programs they want to put on the server.

Both parties started to get angry. From our perspective, we do not understand why developers cannot accept all the great things we test for them. For them, these developers cannot understand why we are so stubborn. They just want to help customers.

One afternoon, Things grew to the top. A developer walked into the test lab, put a software on the desk, and announced that we would install and test the software on that day. I told him we were going to do it at another time-maybe some time next month, I had my approach. He is not happy. From that time on, some of the tasks were out of control. We stood face to face and shouted at each other.

Our customer facilitator happened to walk into the room when the two of us twisted together. He closed the door and went out. Two hours later, the developer and I were both kicked out of the project. However, after we leave, there was no improvement in the situation between the two teams in that project. As a matter of fact, the situation is getting worse and worse, and finally the entire project fails.

What happened?

In addition to my own unprofessional behaviors, this project is also plagued by a fundamental problem. The relationship between the infrastructure and the developer team creates a lot of tension. My shouting and the developer's out of state are just representations, not the essence of the problem. Identifying and understanding this problem has become the focus of my attention while waiting for the next new project.

After reviewing our work type, I realized that infrastructure and development have conflicting views on the world. Such conflicts inevitably lead to a war between two teams.

The infrastructure team focuses on capability and risk management. Their goals usually include "quick configuration", "installation without any trouble", and "quick problem solutions. Managers measure the infrastructure by checking on-premise time and problem solving methods. To achieve these goals, talented infrastructure engineers strive to create a stable, low-risk, and highly manageable environment. When changes make it difficult for them to reach their goals, they will resist risks.

Programmers have completely different cultures. Their goals include solving business problems, transforming existing programs to solve new problems, and considering the feasibility of new technologies. The measure is their ability and desire to successfully take risks. The more risks they have, the more problems they can solve, the more likely they will be able to score.

This dislike/dislike of risks explains the comments I hear from the infrastructure and development team every day. Infrastructure teams usually regard programmers as arrogant cowboy. Programmers treat their infrastructure teams as vulgar people and complain that they are always worried all day long. The contradiction between the two is obvious, so this question is not how we can stop the war between the two, but how we can use it and obtain the greatest benefit from it.

Utilization shortage

From a practical perspective, we cannot change the tension between the two teams. The adventurer and those opposed to the risk will always conflict. However, it is still possible to use these different ideas and enable them to work in a rational environment.

The simplest way is to designate the most extroverted and sociable people in two teams as "contacts" for the same team ". Contact persons participate in meetings of the other party's team to learn what the other party wants and how the other Party handles the problem. This creates a mutual understanding between the two teams. It also ensures informal communication between them.

A more complex method is to establish basic change management. Set up an acceptable method and time for the two teams to sit and discuss the changes. In addition to this meeting, we established informal brainstorming meetings to allow key people on both sides to express their opinions. In addition to the dull atmosphere of the formal meeting, informal exchanges enable the two teams to build a common goal.

Fast forward

A few years later, I discovered that I once again participated in a project that also included a large development and infrastructure team. At the beginning of the formation of a hostile camp, I used my identity as a senior infrastructure administrator to establish a change management process. At the first meeting, developers laughed at and attacked infrastructure engineers. After the meeting, I had a corridor meeting with a similar person from the software team. We agree to be the contact person of another team. Although it took me a lot of time to do this, the pre-warning and information I obtained from attending the development meeting allowed the change management process to proceed smoothly. This system also helps developers realize that not all members of the infrastructure team only want to impede their work. The developer playing the contact role also told them the risks that the infrastructure team needs to handle and why we are so disgusted with sudden changes.

In our meetings, we established a change method (the number of changes, the scope of changes, and the duration of the changes) that helps us clearly communicate the changes necessary for the environment. Over time, we established a set of common languages and expressed gratitude for each other's methods that ultimately help customers save time and money. In the first project, we were not able to understand the fundamental differences between the two teams. In the second project, we used formal and informal methods to take advantage of this difference to produce more innovative and effective solutions.