Personality Factors That Influence Core Build and Release Management Practices


In her Personality Matters series, Leslie Sachs examines the personalities and people issues that are found in technology groups from cross-functional, high-performance teams to dysfunctional matrix organizations.

Leslie Sachs discusses the key people skills essential to appreciating how and which personality factors most impact one's ability to successfully implement core build and release management practices.

Building code would seem to be a very straightforward technical task that would be done best by your favorite computer geek. There isn't much that would seem to be dependent upon personality and psychology in the workplace. However, the workplace is populated with human beings who use different communication styles and are filled with emotion and often quite fragile (and needy) in many ways. Implementing repeatable build processes touches many of these key personality points as you interact with the developers who wrote the code and may have strong feelings about how their creations should be handled. Misstep and you might find yourself not getting much cooperation from key stakeholders who can significantly impact your personal success or failure. Read on if you want to learn more about some key people skills essential to appreciating how and which personality factors most impact one's ability to successfully implement core build and release management practices.

Separation Anxiety
Psychologists tell us that it is normal for children to feel some level of anxiety when saying goodbye to a parent, sibling or other individual. This becomes known as a separation disorder when the anxiety is so severe that it results in consistent symptoms which significantly disrupt the child's ability to function. I will resist the urge to go into more detail on this psychological problem other than to point out that some developers actually exhibit a mild form of this anxiety when being asked to part with their computer code so that it can be built by an independent team as is required by compliance regulations. Many developers feel far more secure when they can build and deploy their code to QA, UAT and Production themselves - all from the convenience (and safety) of their own desktop. Trying to retrain these developers to prepare their code to be built by an independent third party can result in many interesting behaviors ranging from the mild passive-aggressive obstruction to outright hostility. The first step in managing a build function is to realize that this behavior is often just a manifestation of anxiety, which can sometimes be remediated with good communication, and even better, collaboration.

Loose Cannons
In the book Configuration Management Best Practices: Practical Methods that Work in the Real World that I coauthored with Bob Aiello, I discussed the “loose cannons” who don't want to conform and follow the rules. Similarly, we discussed the “risk takers” who thrive on taking their chances – often with fantastic success. Technology professionals who refuse to follow the rules are often called cowboys with their development organization being described as the “Wild Wild West.” Aside from the glamour of lving in the Old West, cowboys may not make very good technology professionals. For example, developers who resist following the necessary controls to support the independent build process, may very well present significant challenges. They aren't the only ones. Some strong “process types” may exhibit their own challenges.

Highly Organized Personality Types
There are also very organized personality types who prefer their own internally created systems to those suggested by others (CMBP, page 156). Obviously these colleagues can prove very difficult to deal with when trying to get them to follow build procedures. It is not uncommon to find people in the workforce struggling with OCD (obsessive-compulsive disorder) or Asperger's syndrome (a high functioning form of autism) who may be very rigid in wanting to follow only their own internally developed “standards.” You may find these people to be very difficult to work with.  In fact, people with a high need for “sameness” are frequently drawn to the IT field because of it's focus on order and concrete parameters. While you not are expected to diagnose these disorders, lots of people are actually very open and willing to discuss these challenges which can be compared to disabilities not much different than someone who is dealing with getting around in a wheelchair or on crutches. The lesson learned here is that when you suddenly notice that someone seems extremely difficult to work with, there may be very valid and rational reasons for their behavior, reasons which can be ameliorated with open discussion and minimal adjustment.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.