Developer personality dynamics

A while back, the members of my team participated in an Insights Discovery process session. Insights Discovery consists of a personality questionnaire completed by each team member followed by an analysis and group session to discuss the meaning of the results to facilitate improved communication and synergy between team members.

We found the results very enlightening and I've noticed improvements in team interactions since we went through the process. I'd like to do it again to include team members who have joined us since.

Insights Discovery assigns each personality type to a place on a color wheel. We found that most team members had mostly blue personalities, which are common amongst developers (introspective thinkers), although we had a couple of greens (supporters) and one red (directors).

Blue vs. red can be a challenging dynamic and one recent interaction I witnessed brought me back to our analysis. Here's how it played out (with ficitious names):

Blue Ben was pulled into a data warehousing project after it had become late and over budget. Although Ben had some ideas for improvement, he was met with resistance since those already on the project were already personally heavily invested in the current design. Ben continued to work on the project which, while continuing to come closer to completion, continued to go later and further over budget.

Eventually, Red Rudy was brought in to help complete the project. After just a day or so of orienting himself to the current solution, Rudy approached Ben, saying, "Hey, there are a lot of things with this that really suck." While Ben knew Rudy was overreacting, he also knew some of what Rudy was saying was true. However, Ben suddenly felt defensive; his work was seemingly being called into question. But most of it wasn't even his decisions! He was now in a position where he felt compelled to defend work that wasn't even his!

By the next week, Rudy had largely redesigned the solution. Well, it wasn't really redesigned all that much, but since it was Rudy's work, he could now distance himself from the previous solution. Unfortunately, this further alienated Ben, who now felt "stuck" with "his" inferior solution (that he didn't really even want in the first place) while Rudy ran off with the new, improved goods.

A week later, close to the end of the project, Green Gary came in to help with some final tasks. He took a look at Ben's solution and then approached him, saying, "Hey, I noticed a few things that might be worth looking at for improvement. Maybe you already figured them out, but how would you feel about discussing them?" Ben was more than willing. He finally felt like he could share some of his frustrations; Gary helped Ben confirm his own ideas while enabling them both to feel more ownership over the project rather than defensive about it.

Soon, a new phase of the project began, and Rudy's solution was used as the starting point. Ben had a lot to offer but struggled to feel any connection to the project--this no longer felt like the thing he had invested so much in.

What this scenario helped illustrate is that the outcomes, at least in terms of the attitudes and happiness of the developers, can be affected greatly by how the developers are approached. Beware of forcing developers to defend things they don't want to defend!