Project Management

Managing infrastructure and development egos in the same project

Infrastructure engineers and developers can be like a project's Hatfields and McCoys unless you rein them in and deal with their communication problems.

Sometimes it seems that the world of IT falls into two warring camps. On one side stand the infrastructure engineers dedicated to the stability and protection of their environment. On the other side stand the developers, constantly striving to find unique and better ways to accomplish their goals. The battles between these two factions become so fierce at times that even the densest manager has to notice them.

A case in point
One of my first big projects involved moving a basic financial information system for a school district from one platform to another. I worked as a troubleshooter and deployment specialist for the infrastructure team. Because the application bordered on archaic, the development team also took on the challenge of upgrading it to meet the district's current and projected future needs.

Things started out reasonably well. We built our servers, configured routers, and had a fun time playing with IP subnetting. As the infrastructure team ran through its stability testing, the developers retreated into their dusty rooms and dark corners. They worked late into the night.

About a month into the project, the two teams stopped talking outside of our regular weekly meetings. Two months into the project, those weekly meetings started to take on a sour note. The infrastructure team moved toward our finalized configurations and performed fundamental stability testing. The development team came to us every week with new changes, patches, and programs they wanted to put onto the servers.

Tempers began to flare on both sides. For our part, we didn’t understand why the developers couldn’t just live with all of the great things we already tested for them. For their part, the developers didn’t understand why we were being so obstinate. They just wanted to help the client.

Things finally came to a head one afternoon. A developer strolled into the testing lab, dropped another piece of software on the table, and declared that we would install and test it that day. I told him it would get worked in when it got worked in—probably sometime next month, if I had my way. He wasn’t pleased. Things got a bit out of hand after that. We stood inches from each other, screaming loudly.

Our client sponsor walked in just as we were winding down. He shut the door behind him. Two hours later, the developer and I both resigned from the project. Nothing improved between our teams after we left, however. In fact, the situation continued to degenerate, eventually leading to outright project failure.

What happened?
Beyond my own unprofessional behavior, the project suffered from a fundamental flaw. The degenerating relationship between the infrastructure and development teams created an unbearable amount of tension that had to express itself. My yelling and my counterpart's swearing were a symptom, not the problem itself. Identifying and understanding that problem became my focus while I was waiting for a new project assignment.

After reviewing the kinds of work we do, I realized that infrastructure and development hold contradictory views of the world. This contradiction leads to inevitable fights between the two groups.

Infrastructure teams focus on capacity and risk management. Their goals typically include things like “rapid deployment,” “trouble-free installation,” and “rapid problem resolution.” Managers measure infrastructure by reviewing downtime and issue-resolution metrics. In order to meet these goals and metrics, talented infrastructure people strive to create consistent, low-risk, highly manageable environments. They become somewhat risk-averse, as change forces them into a situation where they may not be able to meet their goals.

Programmers have a very different culture. Their goals include solving business problems, adapting existing programs to new issues, and imagining the possibilities of new technology. They are measured by their ability and willingness to successfully take on risks. The bigger the risks, the bigger the problems they solve and the higher their marks.

This risk-aversion/risk-taking split in the ranks explains the comments I hear every day from infrastructure and programming professionals. Infrastructure people generally regard programmers as cowboys who would have trouble blowing their own noses. Programmers call infrastructure teammates stodgy or stiff and complain about how they worry all the time. The contradiction between the two is obvious, so the question then becomes not how do we stop the fighting, but how do we manage it to the greater good?

Harnessing the tension
From a practical point of view, we can’t change the tension between the two groups. Risk takers and the risk-averse will always clash. However, it is possible to harness these differing viewpoints and to make them work together in reasonable harmony.

The simplest way is to appoint the most extroverted member of each team as a “liaison” with the other side. The liaison sits in on the other team's meetings, learning about what they want and how they approach issues. This creates a modicum of understanding between the two groups, as well as ensures that informal communications remain open between them.

A more complex method masquerades as basic change management. Establish an accepted format and time for the teams to discuss changes as a group. Outside of that meeting, establish a handful of informal brainstorming sessions to get key players on both sides talking. Underneath the steady plodding of the formal structure, the informal communication allows the two teams to move with a common purpose.

Fast forward
A few years later, I found myself once again working on a project with a large development and infrastructure component. As the warring camps started to form, I used my position as senior infrastructure architect to institute a change management procedure. After the first meeting in which the developers chaffed and struggled, I held a hallway meeting with my software counterpart. We agreed to act as liaisons for each other's teams. Although it ate considerably into my time, the forewarning and input I gained from attending the development meetings smoothed out the formal change management procedures. This system also helped the developers see that not all infrastructure people existed simply to stop them. My counterpart was able to talk to his own people more coherently about the risks the infrastructure team dealt with and why we resisted sudden changes so much.

During our meetings, we established change metrics (number of changes, scope of changes, and duration of change) that helped us to communicate clearly about the needed alterations to the environment. Over time, we built a common language and an appreciation for each other's approaches that ultimately saved our client time and money.

In the first case, we failed to understand that a fundamental difference exists between the two functions. In the second, we used formal and informal methods to harness that difference to produce more creative and effective solutions.

Editor's Picks