The Importance of Human Dynamics in Software Development

Have you ever been on a team of aces – the best of the best – and failed?  Have you ever been on a team that consisted of average people, found your rhythm and exceeded expectations again and again?  What is behind this?

Here’s the story: There is a frequently self-fulfilled stereotype among technical professionals in our field that we are no good at personal skills and that this is a trait of someone’s personality, and consequently un-learnable.  Many of us also feel uncomfortable with the topic so we tend to underplay its importance, which is evidenced by our naming such skills as “touchy-feely”; we focus on our work – the real work – of writing code, coming up and maintaining designs, and architecture.  The touchy feely things are unimportant and frequently get in the way.

Here’s the (hidden) truth: We are wrong.  The fundamental human dynamics skill-set is learnable and it is extremely important.  It is the difference between a failed team, a team that gets by, and a hyper-productive team.  In this article I will give you a high level view of the most important human dynamics that affect our work and start to explore the first of these.

Why are Human Dynamics Important to Development, Design, and Architecture?

Software development is a team sport; we either all win together by producing great software, or we all lose together by not achieving our goals no matter how well we execute individually.  In building software, there is no such thing as “it is not my problem” just as it is invalid for people on a plane to say “it is not my wing on fire” because not delivering the software to the users invalidates any well written and designed component of the system.

There are several fundamental, learnable skills that deeply affect our effectiveness as highly technical professionals in a team environment:

• Sincerity, or lack thereof, comes through no matter what we say or how we say it.  People communicate at a deeper level than mere words.  If we are insincere in our actions, we foster that in others, which undermines effective teamwork.
• Ownership behavior is absolutely necessary for productive teamwork.  Taking individual responsibility for the whole project - not just your assigned piece – is the key to solving the really hard problems.  The really hard problems are the ‘in-between’ problems that are not clearly my responsibility or yours.
• Trust is a state, which allows us to rely on each other and build things together.  Lack of trust is a killer for any effective collaboration.  Trust is built by successfully making and keeping ALL agreements; missing one agreement undermines trust much more than making that agreement builds it.
• Confronting issues is the only way to solve problems.  If you let problems be, the best you can expect is that they will linger and many times they will fester and grow.  Add to that the fact that many of us are extremely uncomfortable with confrontation and are unskilled in doing so in a calm manner.
• Environment.  One of the most provocative ways to make this point is the following quote: “you already have what you want, the question is: why do you want what you already have?”   This question is valid for the individual as well as for the entire organization.  The environments we create around us have created our lives today.  To affect change, we need to see that we have created our environments that, in turn, are causing our current upsets.  Only then can we change for the better.

There are many more such learnable skills and nuances concerning different techniques to build and maintain these skills.  But these are the ones we will focus on initially.

So, how do human dynamics affect our ability to create a great design or to code effectively?  Consider the following scenario as an illustration:

I am a developer on a team who gets the architecture and/or design handed down from above.  I just got out of the meeting with our architect as he explained the reasons behind why things were set the way they were.  He was very polite and said all the right words; but I did not feel listened to.  

I brought up what seemed like important issues that make the proposed architecture infeasible given the current libraries we use. I was unsatisfied with the architect’s answer.  He explained the issues away without brushing them aside.  On the surface I can’t really argue, but I feel frustrated because his ‘words’ are right but I still have a sinking suspicion that things are not right.  I also am annoyed that my architect didn’t take me seriously and have started thinking of him as disconnected and a white tower architect.  This has several effects on our productivity:

1. I may not do my best at solving the problem his way and will be glad if it fails and say ‘I told you so’. 
2. I may ignore the architect, because of my new perception of him, and that will cause an inconsistency in the code.  If I am right, people coming to work on the code after me will have a harder time understanding it in a larger perspective.  If I am wrong, then I’m wasting my time on a solution that will not work and impact the architect’s perception of me and this, in turn, will make me more resentful.
3. I work much more effectively when I’m bought-in and excited.  When I’m doing things out of obligation I do what’s necessary to get by.  It is also more difficult/stressful on me, which directly affects my productivity.
4. The architect will not trust me no matter what choice I make.  If I do what he says slowly (because I’m coming from obligation) he’ll think I’m slow.  If I don’t do what he says he won’t trust me at best and will consider me an opponent at worst.

The scenario shows how sincerity (the architect’s and later mine) affects ownership (I abdicated ownership in the scenario where I did work out of obligation) and also affects trust (my perception of the architects insincerity reduced my trust in him, and my actions will reduce his trust in me).  All of this happened because I perceived a problem (the architect not taking me seriously) and did nothing to confront the issue and correct it.  All of this also happened in an environment that has ‘architects’ handing down the law to ‘developers’ that leaders in the organization have created and maintained.  My part in it, even if I am a lowly developer, is that I have chosen to join such and organization; and as the quote goes “if you don’t like it then change your company or change your company”.

These skills are discrete and learnable

All of the points in the introduction are valid, but can we all learn them?  Or is it true that you are either born with ‘it’ or without ‘it’?  I have found that these skills are learnable and you can get immediate results.  These skills affect much more than our ability to perform our profession productively and many of them are life-long pursuits of excellence.

Sincerity and it’s affect on our technical day-to-day

In the book, The Anatomy of Peace: Resolving the Heart of Conflict, the authors introduce what I believe is a fundamental truth in human nature and how we relate to each other.  Simply put, we communicate and relate to each other on a level much deeper than words – our ‘way of being’.  If I say something to you, no matter what words I use or how I say it, my deeper feelings towards you come through.  Two people can say the exact same things, perform the exact same actions, and they can be perceived in completely different ways.  In the example above, the real reason I was upset was that I felt that the architect didn’t respect me and didn’t really listen to me.  He could have said the exact same things and if I had perceived them differently, I would have left happy, excited, and passionate about the work and had a completely different result.

This brings up another point, oftentimes our insincerity towards each other causes us to go into vicious cycles.  In the example above, I went away with less respect for the architect and it will cause me to act differently which will lead him to respect me less and so on.  It frequently grows more insidious than this as I talk to my peers and tell them how unfairly I was treated and how little this guy really knows.  It is a disease that spreads quickly if not caught and dealt with early.

So back to coding and other technical work:  Our lack of sincerity undermines our teamwork, our communication, and even our individual effectiveness as we work less effectively when we are doing things out of obligation.  This affects the quality of our designs and coding because we work in a different state of mind and emotion, and we also fail to learn.  In the scenario above there is obviously a chance to learn – either for me to learn why the architect is right or for him to catch a mistake early.  Unfortunately the architect’s insincerity and my reaction to it kept us from getting there.  This problem will persist and bite us in the near future.

How do we get out of this vicious cycle?  Simply put, we have to find a way out of seeing others as less than equals.   In the next installment of this series I’ll outline specific ways that you can catch yourself in this vicious cycle and how to get out of it as well as introduce the next human dynamic in more detail.