Conflict and Team Development
We have looked at how to write code that is easy for our development team to pick up and use (and in so doing fueling efficiency, and better teamwork), then we looked at communication between team members, and some of the tools we can use to help facilitate effective team communication.
In part 3 of this series we are going to look at dealing with conflict in a development team environment. This is something that is unavoidable, but very rarely discussed. My goal for this article is to look at conflict within the development team setting (no doubt I am sure it applies to any design/dev work environment), see the source and suggest ways that we can deal with and or prevent it.
As I have mentioned in the previous two articles, development teams can be made up of many different people who represent the different departments involved in the execution of a given project/product. It is not just departments that are represented in the team, more importantly it is NEEDS that are being represented. Each member of a development team represents a certain need and or requirement that has to be met to insure the teams success. So it is key for us to look past differences, attitudes, and opinions (when necessary) and keep focused on the bigger picture… the success of the project.
With different personality types, job responsibilities, and work ethics, there is no avoiding disagreements, and the occasional whiteboard war of ideas. A balanced approach to team needs, input, and authority is crucial. This was most recently seen in Douglas Bowman’s departure from Google, granted everything happens for a reason, and I am sure that he has great things ahead (he is one talented guy), but it is unfortunate that it had to end the way it did.
The key is not to avoid these situations but instead to handle them, but how?
It may sound redundant but again the key here is communication, not just expressing our needs, ideas, and opinions, but listening to the insights, needs and opinions of other team members, and understanding them. This doesn’t mean that we have to agree with them on everything, but compromise is reached much easier when we set aside our agendas listen and collaborate for a fair resolution that benefits the good of the project.
2) React / Respond
Once we have heard someone else’s opinion, concern, or plan we now have a choice. We can A) completely disregard it knowing that we were right all along, and proceed to hop on twitter and inform everyone of exactly how lame this person is, or B) take what they have said, process it and make a decision to find a resolution, that works for everyone, or if needed bring in a third party to help the process. It will help us greatly in these situations to remember the the project’s success is the highest priority. Again just because we find a common ground (the project’s success) it doesn’t mean that we are pushovers, we can have difference of opinions, we can have differing theories on work flow, and process, but as long as our differences are not slowing down the progress and or interfering with the success of the project.
We have listened, we have responded with intent to move forward, now comes the part where we actually have to act on it, this can be the hardest part! When we do put things in motion resolving issues that arise and getting our projects heading in the right direction the rewards are very gratifying. Development team success can happen when we understand that it benefits us most when the team succeeds.
Having talent is valuable asset, but being someone who makes everyone around them better is something that we can all posses regardless of our abilities
There is definitely no “I” in team, and no “U” in win, the key is not to focus on ourselves, and even more so not to focus on the faults of others, this is easier said than done, but if I have learned anything working in a team environment it is that is setting aside my pride(which is still a work in progress), and putting the product/project first has led to successful projects, and the earned respect of managers. This has opened the door for more responsibility, as well as given validity the input I offer on projects. Does it always work this way? No, but just like everything else it is a process, and the more we are willing to learn, and hungrier we are for growth, it will happen, and the rewards will be great!