There is a natural tension between development and operations. When this relationship is in balance, each side helps the other. But when there is imbalance, bad things can happen. Leslie Sachs details the pitfalls that can sabotage a DevOps team, as well as the checks and balances that will help the team achieve productivity and quality.
DevOps helps improve communication and collaboration between development and operations, leading to smoother and more reliable deployments without the drama often associated with large-scale system outages. The DevOps transformation often uncovers a level of imbalance that exists between organizational structures—sometimes creating a little disruption on the way to process improvement.
In my consulting practice, I often see organizational dynamics that adversely impact the team’s ability to achieve success. Too often, this dysfunctional behavior is experienced in terms of a mismatch in organizational power between existing organizational silos. There is a natural tension between development and operations. When this relationship is in balance, each side helps the other. But when there is imbalance, bad things can happen.
Some operations groups have very strong positional power and can actually shut down new approaches, essentially stifling organizational agility. When this happens, operations becomes a bottleneck in the development process, resulting in a loss of productivity and quality. Some operations groups hide behind their existing rules and insist that any deviation will result in significant risk to the firm. By shunning innovation, operations is sometimes responsible for slowing down the deployment process, which itself can result in significant risk to the firm. However, operations is not the only potential bad player.
Development can also yield an excessive amount of power within an organization, often because they are in the best position to know the latest tools and technologies. Unfortunately, they sometimes keep operations in the dark until the very last moment. I have seen development teams use their superior technical knowledge to run rings around the operations team and exhibit significant power to bypass existing IT controls, often with the excuse that operations lacks the technical expertise to support the application themselves. DevOps is supposed to help address these issues, but I am also seeing some folks using DevOps as a rationale to have developers essentially usurp the role of operations by deploying their own code to production. When this happens, some developers are actually motivated to keep operations in the dark even more so that the developers can maintain free rein in production.
Personality plays a key role in these situations because individuals tend to fall back on the behaviors that they find most comfortable and familiar. Some technology professionals have a strong need to maintain absolute control and will orchestrate the balance of power to ensure that they can maintain their own positional influence. I observe developers who actually try to bypass their operations colleagues in order to maintain their position of being the only smart person in the room. Likewise, I see operations folks who know that they could be a little more flexible, but they distrust the developers, so they stick with adhering to the letter of the law.
Turf wars and power grabs are common among some technology practitioners who are obviously not going to fit into a high-performance DevOps cross-functional team. Distrust and fear—which are often significant motivators driving individuals to try to maintain their positional power—can sabotage the goals of the team.
Positive psychology teaches us that the best way to combat these dysfunctional behaviors is to model and empower strong leadership and good teamwork. When I see these problems in a group, I start by trying to help the leadership understand their role in creating a collaborative and positive environment. With top-down support, we can then move on to the professionals engaged in the day-to-day work.
DevOps cross-functional teams are the organizational structures that help groups find the right level of balance by creating a structure where everyone has a shared goal as well as common responsibilities. The DevOps team focuses on sharing knowledge and building trust through a mutual experience. Unfortunately, some team members prefer to remain on their own and actually may not be able to adjust to the demands of a cross-functional team. While these individual contributors still may be able to provide value to the organization, it is important to ensure that they do not adversely impact the DevOps transformation.
The balance of power between highly skilled development and operational professionals provides a valuable set of checks and balances that helps the team achieve agility along with exceptional productivity and quality. Strong leaders ensure that their teams maintain this balance along with the teamwork needed to reach excellence. If you can maintain an appropriate balance, then your organization has a much greater chance of achieving success along with meeting and exceeding your customers’ expectations.
User Comments
Great article. Finally - it takes a psychologist to point out that self organization often needs management intervention to ensure that collaboration is effective.
Indeed, I have seen all the things described here.
Many government agencies today, and many groups within companies, deploy to clouds in order to avoid the rules imposed by the organization's data center. Today's data centers are often bureaucratic and too slow, so people are now going around them. But if one goes around the data center, one needs to be sure that one has the required security, ownership of one's data, disaster recovery, backup (by an independent provider), etc.
I have also seen "devops teams" consist of technical gurus who create a mass of unmaintainable infrastructure code that only they understand. That is a real danger today: All the vagrant and chef scripts that are being created are almost certain to be legacy in only a few years. Organizations need to think this through and avoid guru-driven devops groups. Think about maintainability, and about reliability: just because something is scripted does not mean that it is reliable - it can, in fact, be very fragile.