Conflict in Engineering Organizations

My best days at work are the ones full conflict. My worst days at work are the ones full of conflict. I am not a schizophrenic but am referring to two completely distinct types of conflict. On the good side, I love cognitive conflict. It challenges me to wrestle with new ideas and think through different perspectives. Brainstorming, white-boarding and out-of-the-box problem solving are all examples of cognitive conflict thought processes. It is the type of conflict known to drive innovation. It is what we should strive for at work. 

I hate affective conflict. When the team’s energy turns from solving a problem to “solving a person” we have affective conflict. At work this type of conflict can be driven by situations of ambiguity in roles and responsibilities. It can also be driven by individuals who believe the corporate economy is a zero-sum game and look to consolidate power in strong-armed or manipulative fashions. Mental energy is no longer focused on the mission. We now have ‘Game of Thrones’ style corporate politics.

To break out of the cycle we should start with role clarity; knowing that it drives employee morale. There is nothing more important for productivity than employee morale. Most companies that are known for great employee morale and culture also have incredibly productive employees. Keep a casual tally of interesting open source projects or great technology blogs you read. Where do the authors work? Notice any patterns?

Furthermore, what fascinates me is how corporate culture impacts technology choices. The obvious example is Conway’s Law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.” In my experience working with engineering organizations, simple and elegant systems are produced by teams who care more about the mission (cognitive conflict) and less about job security and pet projects (affective conflict). An engineer who solves a problem in a way that is “stupid simple” cares about the mission as demonstrated by an easy to integrate system design. While, building complex solutions is a great way to stake out corporate real estate because few others will understand the Frankenstein system. 

Morale and culture are force multipliers. Done right and we have energized employees who innovate. Systems are produced that are elegant and simple. Their architecture is easily communicated to other teams and become leveraged in other projects. Done wrong and we have a cycle of protective technology decisions or ones done with little input from other teams. These systems produce technical debt and are a burden to the organization. Therefore, maximize cognitive conflict at work and minimize affective conflict. Strive for clarity in roles and manage morale. Nothing is more important for engineering teams to succeed.